Slow joins lead to poor UX

[Half-Shot]

This issue hopes to sum up a general bad feeling about joining rooms for the first time on a smaller homeserver, which is particularly relevant to people who have their own server (either through a paid or self hosted offering). This issue is categorically not about room joins being slow, but rather that slow room joins are handed in a unfriendly way.

Matrix has evolved to the point now that there are several large communities running their own homeservers, each with their own set of users who will be joining rooms from the first time from that server. For example, it's expected that a user from kde.org may want to join #matrix:matrix.org, or that a user from gnome.org may want to join #linuxgaming:half-shot.uk. These rooms may be rather large, or the homeservers may be rather busy which causes room joins to take a long time to complete.

As a result, it's not uncommon to see a "Joining room..." dialog box that will sit there for minutes at a time while a join takes place. There are several problems with this dialog though.

1. It doesn't communicate that joining a room is an asynchronous operation in Matrix. There is no option to dismiss the join to take place in the background, and certainly a number of users fear clicking away from the join window to another room will prevent them from joining. The ideal solution here would be an effective way to tell the user that a join is asynchronous. Slack does this by adding the room immediately to the sidebar of the user's client, and then showing a limited preview in the timeline until the join has completed.

2. The join doesn't appear to progress. While work is going on in the background, it's not clear to the user that there has been any change. This is harder to solve as Matrix offers no present solution to determine how far a join has progressed, but nonetheless it's not clear to the user how far their request has gotten.

3. Another problem which is more down to the backend but is unfortunately presents a problem in Element is that should a join take a very long time to complete, it may time out the HTTP request before the join has finished, presenting an error to the user rather than telling them the truth: the join is still going but may take longer. Again, there isn't much we can do for this in Matrix but is another pain point.

I believe 1 is the most solvable, insofar that we could create the illusion of progress by showing a ghost representation of a room with a title and avatar, while the join is still going on. It's also something that I expect a lot of folks will have opinions on :). This is element-hq/element-web#15451

Related issues:

• Joining large rooms takes forever (and never suceeds) element-web#6619 (joining large rooms takes forever)
• riot spins forever when joining a room if /directory fails element-web#6554 (alias joins don't show an error if they fail)
• Loading state when joining a room alias is confusing element-web#9610 (loading state when joining a room is confusing)

[ara4n]

Other related issues:

• When joining a room, it should be in the room list element-web#15451 (show the room in the roomlist while you're joining it)
• MSC2775 - lazy loading state over federation as a long-term solution to slow joins.

[emorrp1]

Oh yes please, especially useful for low-end homeservers. Wouldn't peeking MSC2753 also mitigate this by letting you inspect a room before deciding whether to join it, or does that also depend on lazy loading?

[Half-Shot]

Peeking would mitigate the UX nastiness a bit, insofar that you could see a preview of the room you are joining. I don't think that interacts with lazy-loading -- the federated server would send you a snapshot.

[kittykat]

I'm bumping severity on this some rooms take so long to load that users give up. This issue came up during the last community testing session.

[novocaine]

I think the right way to handle this (until join performance improves) is to make room join display asynchronously rather than blocking.

[novocaine]

Downgrading to O-Occasional as this is specific to small home servers

[waclaw66]

I took me nearly 3 minutes to join #synapse:matrix.org. Join failed many times before I realized that it's because of Apache reverse proxy timeout, it could help other homeserver owners. Nevertheless the join experience is terrible at this time.

[davidak]

I also have the issue that i can't join one room: https://matrix.to/#/#wearefairphone:matrix.org

The strange thing is that it sais i already joined and i'm also in the rooms users list.

I have sent a debug log and linked this issue.

Update: When i opened the webapp again now i am joined. So it only took 18 hours to join.

[ewtoombs]

It took me a whole day for my self-hosted user to join libera.chat##politics through the matrix bridge. Which is fine, but yeah that room joining UI was super unhelpful. I had to tail my synapse logs to figure out what the hell was going on.

[paboum]

I noticed a significant difference in performance on Cinny. It should be easy enough to benchmark one room/homeserver/account on both clients compare the profiling data. I'm not a frontend dev so please someone let's provide the data, then the dev team can see which API calls take longer, etc.