MSC3575: Sliding Sync (aka Sync v3) #3575
Conversation
turt2live
added
needs-implementation
Co-authored-by: Matthew Hodgson <matthew@matrix.org>
Co-authored-by: Benjamin Bouvier <public@benj.me>
This allows concurrent connections to a SS server.
| ```json5 | ||
| { | ||
| "unsubscribe_rooms": [ "!sub1:bar" ] | ||
| } |
There was a problem hiding this comment.
I'm a bit concerned that this API will make it easy for clients to "forget" to unsubscribe from rooms, and you'd end up with clients slowly racking up lots of room subscriptions. Personally, I'd be tempted to change this such that every request you need to specify which rooms the client wants to remain subscribed to 🤷
|
|
|
Is the returned |
|
The end. It is the current state. |
turt2live
changed the title
| There are three main reasons why a client may want to have >1 connection to the server open concurrently: | ||
| - The client is a **browser**, and it should be possible to open the same client in multiple tabs without causing problems. Without concurrent connections, each tab would reset the other tabs connection due to different `?pos=` values being sent. The number of concurrent connections is technically unbounded. | ||
| - The client is a **mobile application**, and it should be possible to have a "push process" connection in addition to the "app connection". Without concurrent connections, it isn't possible to obtain to-device messages in the push process, whilst also obtaining them in the main app. The number of concurrent connections is fixed e.g 2. | ||
| - The client wants to do a **one-shot request** for some data, without incurring latency/bandwidth penalties with all the activity on the user's account. Without concurrent connections, it isn't possible to get the response without also potentially getting large amounts of extraneous data. The number of concurrent connections is N+1, where N is the number of active concurrent connections. |
There was a problem hiding this comment.
The number of concurrent connections is N+1, where N is the number of active concurrent connections.
What is this trying to convey (can someone re-word)? I'm reading this as "a dog is a dog"
| // If the child room has a m.room.tombstone event, then the search should recursively navigate | ||
| // the room ID in that event to find the latest room and use that room ID instead of the initial | ||
| // room ID in the m.space.child event. |
There was a problem hiding this comment.
Why do we want to recursively find the latest room? What benefit for this extra work?
It seems like the new room would also be part of the space. If the user has already joined the replacement room, then the old one doesn't even show up (depending on include_old_rooms). If the user hasn't joined the replacement room, they can accept their invite or visit the old room and see the pointer to the new place to join. (see Tombstones section)
There was a problem hiding this comment.
It seems like the new room would also be part of the space.
Only if the user upgrading had permissions to manage the space (and was on a client e.g. EW/ED which had this logic) - quite a lot of spaces are soft-broken where they only know about old versions of rooms.
There was a problem hiding this comment.
Seems like if the spaces still know about the old rooms, people will visit the old room, be pointed to the new one and can ask the admin to fix space/room relationship.
There was a problem hiding this comment.
@MadLittleMods sure, except the space admin might not even be in the room for them to as ask. So they'll likely end up asking the wrong admin.
| Whilst this in MSC review the HTTP path will be `/_matrix/client/unstable/org.matrix.msc3575/sync` | ||
| with the intention of this eventually becoming (confusingly) `/_matrix/client/v4/sync`. As this is a | ||
| brand new endpoint, no other keys or fields need prefixing. |
There was a problem hiding this comment.
Currently there is no good way for a client to detect presence of a server's support for this MSC unless they are supporting it via proxy (detected via well-known).
If a client tries to make a request via POST to the above sync endpoint and the environment is actually running a proxy on the same subdomain then you end up losing to_device messages as the proxy starts a new legacy sync stream against the same access token.
Can we please add an entry to https://spec.matrix.org/v1.10/client-server-api/#get_matrixclientversions unstable_features to enable the server to express that it has native support.
Workarounds I tried:
OPTIONS request: 200 from the proxy, 204 from Synapse itself
HEAD request: 405 from the proxy, 404 from Synapse itself
There was a problem hiding this comment.
In lieu of the MSC suggesting something itself, I am assuming org.matrix.msc3575 will be used.
Based on: - MSC3575: Sliding Sync (aka Sync v3): matrix-org/matrix-spec-proposals#3575 - MSC3885: Sliding Sync Extension: To-Device messages: matrix-org/matrix-spec-proposals#3885 - MSC3884: Sliding Sync Extension: E2EE: matrix-org/matrix-spec-proposals#3884
Rendered
Impl
Preview: https://pr3575--matrix-org-previews.netlify.app