Already pushed messages are not seen in the client since the "Element" rebranding, sync takes seconds

[jacotec]

I have lots of complaints since the version which was rebranded to "Element" and I'd dare to say the acceptance of users dropped by 80%.

All messages which are pushed to the iDevices and which can be seen in the notifications pulldown are not available in the app after start. After starting the app not even the unread message counters are up to date and it always takes several seconds even on fast internet or local WiFi connections before the message counters and the chat contents are updated.

Even touching on a message in the notification center, which can be read at least in parts here, will launch the chat in the Element app, where the message then is just not there and takes seconds to appear.

Users are not accepting this anymore. This should be fixed with high priority.

[manuroe]

Thanks for this feedback.

The technical reason of this is that we cannot sync with the homeserver in background anymore on iOS. Now, we get the message content to display in a notification using directly the /event API on the event. This is much more quicker that doing an incremental /sync with the server. The battery appreciates. But, when the user taps on a notification, the app opens and needs to do this /sync to have consistent data in its local storage (we need all messages in a room before this notification).

On a quick homeserver, that should be fine. On m.org, this is definetely visible.

One thing we could do from a UX perpective is to keep showing the app loading animation while the app is doing its sync and only open the room when all messages are fetched. This will not improve the time for doing all of this but it may be better perceived.

[jacotec]

Hi Manu,

but for displaying the notifications I guess the app must decrypt the messages before so the content can be shown in the notification, wouldn't it be possible to directly sort that incoming message into the room storage in the app? A full sync would be fine, but putting incoming messages into the assigned room when they are pushed in would do the same job (and might save battery compared to a full sync on each incoming push). I'm really using Element/Riot a lot over the day and it never had a big impact on battery usage.

Just delaying the app start until it's synced is even worse than waiting for the messages to appear in the room in my opinion.

And speed wise ... on a homeserver with 15 users on reasonable hardware (4 vCPU, 4GB RAM on a Dell R720, so not running on a RasPi ;-) ) the sync takes 4-5 seconds even being in the same WiFi as the server. That's a much decreased "Schwuppzidität" compared to before where users opened the app or tapped on the notification and all was immediately there.

Finally, what do you argue to a user who tells you "Your solution is bad; WhatsApp, FB messenger, Telegram, Signal ... they all show me the chat content immediately". Game lost ...

However, "the others" seem to have a solution on IOS here to avoid this behavior ... I think we should have one as well.

[IslandUsurper]

Anecdotally, my wife is deleting the app from her phone because of this exact issue. We're on a two-user homeserver, though my account is in some large federated rooms.

[jacotec]

Same here. The Matrix/Element team should hire more women for daily use ;-). The WAF was the first thing which got fully lost.

I'm - ah, was - running two servers, one for the wider family use, one for my sports club (Non Profit Organization). The core family is 100% on IOS devices, that's where acceptance went fully downhill - started with my wife. But even I'm fully fed with waiting seconds each time I want to read or write something.

In my sports club people were moving back to Whatsapp :-( more and more even before, now IOS guys are fully gone, Android seems not as bad.

So I'm pulling the ripcord right now and I'm moving all to Rocket Chat. What a relief in daily use! Apart from this disaster of that issue here, which alone is a show-stopper, there are more:

• Nearly every day an IOS device can't read anything in some encrypted chats. "Could not get the keys from the sender". Happens randomly on all iPhones and iPads, never saw this on Element Web. Showstopper when you're on the road with just your iPhone.

• Link Previews! Promised since years, fixed promised for last summer (!!!!). Nothing.

• Voice messages. Also a huge demand, long time on the roadmap. Nothing.

I was a happy Matrix supporter the last 3 years, but unfortunately it got unusable. What a pity, I was a fan! I was happy each time Matrix announced they got some pretty good $ from investors, I thought that would boost development. Maybe in a decade ... no idea what's wrong.

Time to cancel my Paetron and move ... Enjoying instant messaging when opening the app, link previews, Voice messages and a pretty decent administration panel with proper account handling and permissions.

[IslandUsurper]

@jacotec, it looks like #3680 should fix our problem here.

[manuroe]

3680 will fix the room that is not updated after tapping on a notification. In this ticket, we also want to improve the fetching time.

@jacotec, I am really sorry to hear that. We know that you have been a very good support over the years. I am sorry and I also understand your point of view. Such a pity that, as a company, we still need to jungle with priorities. I could say that the boost in the iOS team is coming. Voice messages are coming as a sponsored feature with a due date. We are still talking about web preview as the top 3 request.

[manuroe]

One way to improve the timing, and also to avoid to fetch event data twice, can be to make the notification extension run /sync requests.

With this proposition, it will run its own but simple /sync stream starting from the last token known by the app. It will cache all this data. When opened, the app will use this cache data instead of doing /sync requests.

PROS

• This is almost the background sync behavior we have before iOS13 except that we will not load all data from the store
• Data will be available when the app is opened
• We will get missing encryption keys for free

CONS

• It will use more battery because the request will be bigger. I think before, most of the battery was used by loading data
• Notification display will be a bit slower to display because of bigger requests
• More code complexity:
  • PSE has to run its own /sync stream.
  • PSE has to manage its own storage
  • Data sync between PSE and app
  • App/SDK must use this data instead of making a request.
  • More race conditions risks

[jacotec]

@jacotec, I am really sorry to hear that. We know that you have been a very good support over the years. I am sorry and I also understand your point of view. Such a pity that, as a company, we still need to jungle with priorities. I could say that the boost in the iOS team is coming. Voice messages are coming as a sponsored feature with a due date. We are still talking about web preview as the top 3 request.

@manuroe Believe me, I'm sorry as well. But I'll leave one home server running and monitor the route over the next months. I know that you need to feed your families and that there are priorities given by your sponsors ;-)

The lack of features (due to priorities) is one thing, but the serious degradation in usability, periodically lost E2E keys (seems to be a pure IOS issue) mostly made the users voting by not using the app and moving to platforms (which I hate) with a good usability (paying with their data and privacy).

Honestly it would also be great to have at least a well done user management. Might still be a big hurdle for newcomers who does not want to run a world open server.

On the other side also Rocket Chat is a company behind the open source product and you never know their route. In case they made a decision like OnlyOffice in the context with Nextcloud they might become unattractive at some point. Right now the decision to limit push notifications over their gateway to a monthly limit moves some users away, when they don't want to compile their own apps (which I actually did) to run the pushs directly to Apple and Google.

I'll stay in touch here 😉

[jacotec]

One way to improve the timing, and also to avoid to fetch event data twice, can be to make the notification extension run /sync requests.

With this proposition, it will run its own but simple /sync stream starting from the last token known by the app. It will cache all this data. When opened, the app will use this cache data instead of doing /sync requests.

Sounds like a good plan! Regarding battery use, that was never an issue, even with the good, old Riot version which did the sync in the background. And I easily did 100-200 messages per day ...

[neutralinsomniac]

As a data point, my server responds very quickly (100 milliseconds?) to /syncs, and I'm still seeing the issue. I have to go back to the main window and re-open the room to get new messages to come in after clicking on a notification