MSC2755: Lazy load rooms

[deepbluev7]

Rendered

This is an additional attempt to cut down initial sync size and time. Construct implemented something similar for a while, but it wasn't opt in and as such broke clients. I do think the general idea is good though and would help with initial syncs, which can take more than 30 minutes at the moment, even with lazy loading of room members enabled. Conduit also expressed interest in something like this, if I remember correctly, but don't quote me on that.

The key names are subject to bikeshedding and I am open for better suggestions.

Signed-off-by: Nicolas Werner nicolas.werner@hotmail.de

[auscompgeek]

I may have missed this whilst reading, but in the case of a room-lazy-loading initial sync, how should the server signify to the client that the initial sync has finished? Would that be rooms.limited becoming false/omitted (with the client having to remember it's performing an initial sync)?

[deepbluev7]

Yes, a client would have to check for rooms.limited. If rooms.limited is true, the current sync is incomplete. This applies to initial syncs as well as incremental syncs, i.e. an incremental sync could also become so big (because of member or other state changes, a server currently not allowed to leave out member changes even with LL members enabled), that the server limits the returned rooms. In all of those cases the client should immediately sync again until it is up to date in all rooms. Servers probably should not return twice the same room in such a limited response.

[timokoesters]

I don't remember saying anything about this. I'm not a big fan of this MSC. Maybe you can add this to potential alternatives: The initial sync sometimes takes long to finish, so clients can instead use /accountSummary (new endpoint) to get enough info about joined rooms etc to show an interface to the user while waiting for the initial /sync to finish.

[deepbluev7]

That does not help you, if the rooms include a lot of state. This is not only about making the /sync appear faster, but also to make it possible for small devices like the 3DS to sync accounts, when they only have a few tens of megabytes of RAM. For the record, uncompressed my initial sync is 200MB big, even with lazy loading of room members, because it includes a few hundred state events in a lot of rooms, a lot of them multiple kilobytes big and in the end the /sync response ends up being quite big. Some devices simply can't load that into RAM to decompress and parse it.

[timokoesters]

Can you run initial /sync with a filter that skips all state events and then fetch the state yourself using other endpoints?

[deepbluev7]

If you just include the room name and topic, that can still be quite large and potentially grow unbounded. It is much easier to limit how many rooms get returned, imo, especially for client developers. In the best case you limit rooms and state events returned in a segment of /sync.

[timokoesters]

What about a filter that removes all data from individual rooms, even title avatarurl etc? It is quite hard to implement lazy loading rooms in the server (at least for conduit), so I'm looking for alternatives.

[deepbluev7]

If you already have working sync tokens, adding room pagination in a dumb way should be easy, if you just add an extra segment to the sync token and define some kind of static ordering, like sorting by room id. The only issue you run into is probably new rooms appearing, but they shouldn't appear in the same /sync listing anyway. Maybe I am missing something and I am not a homeserver developer, but I don't think it is impossibly hard to implement.

[timokoesters]

I don't want to elaborate here, but I can tell you that it is hard to implement it in conduit (multiple users sometimes have the same sync token for example)

[deepbluev7]

Another alternative may be to decouple the room listing from syncing and explicitly listing the rooms to update client side. But then you possibly need to transfer a lot of data from client to server each time. And you need to be really careful that an incremental sync after a long /sync gap doesn't get too large either. If you suddenly have 20 messages in 500 rooms, that will OOM some clients as well. But you need to set the message limit higher than 0 for incremental /syncs and there is currently really no good way to limit the absolute amount of messages returned to something reasonable without running into a limited sync all the time.