Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MSC2755: Lazy load rooms #2755

Open
wants to merge 5 commits into
base: old_master
Choose a base branch
from

Conversation

deepbluev7
Copy link
Contributor

@deepbluev7 deepbluev7 commented Aug 31, 2020

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

Signed-off-by: Nicolas Werner <nicolas.werner@hotmail.de>
@deepbluev7 deepbluev7 changed the title MSC0000: Lazy load rooms MSC2755: Lazy load rooms Aug 31, 2020
@turt2live turt2live added kind:maintenance MSC which clarifies/updates existing spec proposal A matrix spec change proposal proposal-in-review labels Sep 1, 2020
proposals/2755-lazy-load-rooms.md Outdated Show resolved Hide resolved
@@ -0,0 +1,118 @@
# MSC2755: Template for new MSCs

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@@ -0,0 +1,118 @@
# MSC2755: Lazy load rooms

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@turt2live turt2live added the needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. label Jun 8, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind:maintenance MSC which clarifies/updates existing spec needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. proposal A matrix spec change proposal
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants