Only allow specific users to use sliding sync

[swilkicki]

Requesting a way to lock down sliding sync to only a subset of users. In my case I just want to try sliding sync on my homeserver without allowing everyone to use it to prevent using more database storage & resources.

Currently the one workaround I can think of would be to use nginx allow/deny rules on the endpoints.

[anoadragon453]

Currently the one workaround I can think of would be to use nginx allow/deny rules on the endpoints.

This was what I had in mind as I was reading your feature request. Any reason that isn't a suitable solution?

Note that based on internal testing, a client pulling data via sliding sync uses far less resources than one using legacy sync.

[swilkicki]

@anoadragon453

This was what I had in mind as I was reading your feature request. Any reason that isn't a suitable solution?

My main concern would be still allowing users to login as normal without potentially allowing a "Sliding sync login" and triggering synapse to start making a sliding sync session for someone. Like even if I don't advertise sliding sync support couldn't a user still try and force logging in that way?

Note that based on internal testing, a client pulling data via sliding sync uses far less resources than one using legacy sync.

Network-wise this makes sense. My main concern was around database storage and CPU. My understanding is that synapse basically maintains a session for each sliding sync user, only serving the data needed for the client; using more storage and CPU in the process.

[anoadragon453]

My main concern would be still allowing users to login as normal without potentially allowing a "Sliding sync login" and triggering synapse to start making a sliding sync session for someone. Like even if I don't advertise sliding sync support couldn't a user still try and force logging in that way?

Login is entirely separate from sliding sync. Both forms use the same login endpoints and code. After login and retrieving an access token, the client then decides whether it wants to pull data down using sliding sync or legacy sync. If you want to block access to sliding sync, ensure that the following paths aren't routed to your homeserver:

• /_matrix/client/unstable/org.matrix.msc3575/sync
• /_matrix/client/v4/sync

Network-wise this makes sense. My main concern was around database storage and CPU. My understanding is that synapse basically maintains a session for each sliding sync user, only serving the data needed for the client; using more storage and CPU in the process.

Internal load testing data has shown that native sliding sync uses far less CPU than legacy sync. It uses slightly more database space as it pre-caches data before sending it to the client. But the amount it does so is negligible compared to the large amount of space taken up by other tables for event content and state event tracking.

[swilkicki]

Thank you for the insight as well as the endpoints. I have gone with using nginx rules and this seems to be working.