MSC4186: Simplified Sliding Sync by erikjohnston · Pull Request #4186 · matrix-org/matrix-spec-proposals

erikjohnston · 2024-08-30T08:31:04Z

Rendered

SCT Stuff:

FCP tickyboxes

MSC checklist

proposals/4186-simplified-sliding-sync.md

turt2live · 2024-08-30T15:11:54Z

proposals/4186-simplified-sliding-sync.md

Implementation requirements:

Client (ideally multiple)

Server

Current implementations to my knowledge:

Client implementation: matrix-rust-sdk (PR)

Server implementation: has been implemented in Synapse across 10s of PRs. (Perhaps @MadLittleMods, the implementer, can give better link(s) here.)

Synapse server implementation

Maybe it's easiest to point to the main directories where the code lives:

element-hq/synapse -> synapse/rest/client/sync.py#L782

element-hq/synapse -> synapse/handlers/sliding_sync/

element-hq/synapse -> tests/rest/client/sliding_sync/

The PRs between @MadLittleMods and @erikjohnston with the ~A-Sync label are also a pretty good encapsulation:

https://github.com/element-hq/synapse/pulls?q=+is%3Apr+author%3AMadLittleMods+label%3AA-Sync

https://github.com/element-hq/synapse/pulls?q=+is%3Apr+author%3Aerikjohnston+label%3AA-Sync

conduwuit has implemented simplified sliding sync in x86pup/conduwuit#666

proposals/4186-simplified-sliding-sync.md

MadLittleMods · 2024-09-05T18:05:17Z

proposals/4186-simplified-sliding-sync.md

+      // The "heroes" for the room, if there is no room name. Only sent initially and when it changes.
+      "heroes": [
+        {"user_id":"@alice:example.com","displayname":"Alice","avatar_url":"mxc://..."},
+      ],


Do the heroes membership state events need to be included in required_state response when requesting required_state: ["m.room.member", "$LAZY"] (lazy-loading room members)?

Sync v2 says this:

When lazy-loading room members is enabled, the membership events for the heroes MUST be included in the state, unless they are redundant. When the list of users changes, the server notifies the client by sending a fresh list of heroes. If there are no changes since the last sync, this field may be omitted.

But I think that's because m.heroes in Sync v2 is only a list of user ID's. Whereas, in the sliding sync response here, we already have all of the info necessary in these stripped events.

One alternative is to match Sync v2 and only list the user ID's in heroes and include the membership events in required_state.

proposals/4186-simplified-sliding-sync.md

MadLittleMods · 2024-09-05T18:31:27Z

proposals/4186-simplified-sliding-sync.md

+      "heroes": [
+        {"user_id":"@alice:example.com","displayname":"Alice","avatar_url":"mxc://..."},
+      ],


One weird corner with the current spec: If the room doesn't have a name set and the user is invited/knock to the room, we don't have any heroes to provide here. This is because heroes membership isn't included in the stripped state that the server receives when they are invited/knocked over federation.

Related to matrix-org/matrix-spec#380

This was solved for partial-joins via MSC3943

Not necessarily a blocker but just calling out something that won't work completely until that spec issue is solved.

Cross-link #4319 (comment)

@kfiven

# Synapse 1.114.0 (2024-09-02) This release enables support for [MSC4186](matrix-org/matrix-spec-proposals#4186) — Simplified Sliding Sync. This allows using the upcoming releases of the Element X mobile apps without having to run a Sliding Sync Proxy. ### Features - Enable native sliding sync support ([MSC3575](matrix-org/matrix-spec-proposals#3575) and [MSC4186](matrix-org/matrix-spec-proposals#4186)) by default. ([\#17648](element-hq/synapse#17648)) # Synapse 1.114.0rc3 (2024-08-30) ### Bugfixes - Fix regression in v1.114.0rc2 that caused workers to fail to start. ([\#17626](element-hq/synapse#17626)) # Synapse 1.114.0rc2 (2024-08-30) ### Features - Improve cross-signing upload when using [MSC3861](matrix-org/matrix-spec-proposals#3861) to use a custom UIA flow stage, with web fallback support. ([\#17509](element-hq/synapse#17509)) - Make `hash_password` script accept password input from stdin. ([\#17608](element-hq/synapse#17608)) ### Bugfixes - Fix hierarchy returning 403 when room is accessible through federation. Contributed by Krishan (@kfiven). ([\#17194](element-hq/synapse#17194)) - Fix content-length on federation `/thumbnail` responses. ([\#17532](element-hq/synapse#17532)) - Fix authenticated media responses using a wrong limit when following redirects over federation. ([\#17543](element-hq/synapse#17543)) ### Internal Changes - MSC3861: load the issuer and account management URLs from OIDC discovery. ([\#17407](element-hq/synapse#17407)) - Refactor sliding sync class into multiple files. ([\#17595](element-hq/synapse#17595)) - Store sliding sync per-connection state in the database. ([\#17599](element-hq/synapse#17599)) - Make the sliding sync `PerConnectionState` class immutable. ([\#17600](element-hq/synapse#17600)) - Add support to `@tag_args` for standalone functions. ([\#17604](element-hq/synapse#17604)) - Speed up incremental syncs in sliding sync by adding some more caching. ([\#17606](element-hq/synapse#17606)) - Always return the user's own read receipts in sliding sync. ([\#17617](element-hq/synapse#17617)) - Replace `isort` and `black` with `ruff`. ([\#17620](element-hq/synapse#17620)) - Refactor sliding sync code to move room list logic out into a separate class. ([\#17622](element-hq/synapse#17622)) ### Updates to locked dependencies * Bump attrs from 23.2.0 to 24.2.0. ([\#17609](element-hq/synapse#17609)) * Bump cryptography from 42.0.8 to 43.0.0. ([\#17584](element-hq/synapse#17584)) * Bump phonenumbers from 8.13.43 to 8.13.44. ([\#17610](element-hq/synapse#17610)) * Bump pygithub from 2.3.0 to 2.4.0. ([\#17612](element-hq/synapse#17612)) * Bump pyyaml from 6.0.1 to 6.0.2. ([\#17611](element-hq/synapse#17611)) * Bump sentry-sdk from 2.12.0 to 2.13.0. ([\#17585](element-hq/synapse#17585)) * Bump serde from 1.0.206 to 1.0.208. ([\#17581](element-hq/synapse#17581)) * Bump serde from 1.0.208 to 1.0.209. ([\#17613](element-hq/synapse#17613)) * Bump serde_json from 1.0.124 to 1.0.125. ([\#17582](element-hq/synapse#17582)) * Bump serde_json from 1.0.125 to 1.0.127. ([\#17614](element-hq/synapse#17614)) * Bump types-jsonschema from 4.23.0.20240712 to 4.23.0.20240813. ([\#17583](element-hq/synapse#17583)) * Bump types-setuptools from 71.1.0.20240726 to 71.1.0.20240818. ([\#17586](element-hq/synapse#17586)) # Synapse 1.114.0rc1 (2024-08-20) ### Features - Add a flag to `/versions`, `org.matrix.simplified_msc3575`, to indicate whether experimental sliding sync support has been enabled. ([\#17571](element-hq/synapse#17571)) - Handle changes in `timeline_limit` in experimental sliding sync. ([\#17579](element-hq/synapse#17579)) - Correctly track read receipts that should be sent down in experimental sliding sync. ([\#17575](element-hq/synapse#17575), [\#17589](element-hq/synapse#17589), [\#17592](element-hq/synapse#17592)) ### Bugfixes - Start handlers for new media endpoints when media resource configured. ([\#17483](element-hq/synapse#17483)) - Fix timeline ordering (using `stream_ordering` instead of topological ordering) in experimental [MSC3575](matrix-org/matrix-spec-proposals#3575) Sliding Sync `/sync` endpoint. ([\#17510](element-hq/synapse#17510)) - Fix experimental sliding sync implementation to remember any updates in rooms that were not sent down immediately. ([\#17535](element-hq/synapse#17535)) - Better exclude partially stated rooms if we must await full state in experimental [MSC3575](matrix-org/matrix-spec-proposals#3575) Sliding Sync `/sync` endpoint. ([\#17538](element-hq/synapse#17538)) - Handle lower-case http headers in `_Mulitpart_Parser_Protocol`. ([\#17545](element-hq/synapse#17545)) - Fix fetching federation signing keys from servers that omit `old_verify_keys`. Contributed by @tulir @ Beeper. ([\#17568](element-hq/synapse#17568)) - Fix bug where we would respond with an error when a remote server asked for media that had a length of 0, using the new multipart federation media endpoint. ([\#17570](element-hq/synapse#17570)) ### Improved Documentation - Clarify default behaviour of the [`auto_accept_invites.worker_to_run_on`](https://element-hq.github.io/synapse/develop/usage/configuration/config_documentation.html#auto-accept-invites) option. ([\#17515](element-hq/synapse#17515)) - Improve docstrings for profile methods. ([\#17559](element-hq/synapse#17559)) ### Internal Changes - Add more tracing to experimental [MSC3575](matrix-org/matrix-spec-proposals#3575) Sliding Sync `/sync` endpoint. ([\#17514](element-hq/synapse#17514)) - Fixup comment in sliding sync implementation. ([\#17531](element-hq/synapse#17531)) - Replace override of deprecated method `HTTPAdapter.get_connection` with `get_connection_with_tls_context`. ([\#17536](element-hq/synapse#17536)) - Fix performance of device lists in `/key/changes` and sliding sync. ([\#17537](element-hq/synapse#17537), [\#17548](element-hq/synapse#17548)) - Bump setuptools from 67.6.0 to 72.1.0. ([\#17542](element-hq/synapse#17542)) - Add a utility function for generating random event IDs. ([\#17557](element-hq/synapse#17557)) - Speed up responding to media requests. ([\#17558](element-hq/synapse#17558), [\#17561](element-hq/synapse#17561), [\#17564](element-hq/synapse#17564), [\#17566](element-hq/synapse#17566), [\#17567](element-hq/synapse#17567), [\#17569](element-hq/synapse#17569)) - Test github token before running release script steps. ([\#17562](element-hq/synapse#17562)) - Reduce log spam of multipart files. ([\#17563](element-hq/synapse#17563)) - Refactor per-connection state in experimental sliding sync handler. ([\#17574](element-hq/synapse#17574)) - Add histogram metrics for sliding sync processing time. ([\#17593](element-hq/synapse#17593)) ### Updates to locked dependencies * Bump bytes from 1.6.1 to 1.7.1. ([\#17526](element-hq/synapse#17526)) * Bump lxml from 5.2.2 to 5.3.0. ([\#17550](element-hq/synapse#17550)) * Bump phonenumbers from 8.13.42 to 8.13.43. ([\#17551](element-hq/synapse#17551)) * Bump regex from 1.10.5 to 1.10.6. ([\#17527](element-hq/synapse#17527)) * Bump sentry-sdk from 2.10.0 to 2.12.0. ([\#17553](element-hq/synapse#17553)) * Bump serde from 1.0.204 to 1.0.206. ([\#17556](element-hq/synapse#17556)) * Bump serde_json from 1.0.122 to 1.0.124. ([\#17555](element-hq/synapse#17555)) * Bump sigstore/cosign-installer from 3.5.0 to 3.6.0. ([\#17549](element-hq/synapse#17549)) * Bump types-pyyaml from 6.0.12.20240311 to 6.0.12.20240808. ([\#17552](element-hq/synapse#17552)) * Bump types-requests from 2.31.0.20240406 to 2.32.0.20240712. ([\#17524](element-hq/synapse#17524)) # Synapse 1.113.0 (2024-08-13) No significant changes since 1.113.0rc1. # Synapse 1.113.0rc1 (2024-08-06) ### Features - Track which rooms have been sent to clients in the experimental [MSC3575](matrix-org/matrix-spec-proposals#3575) Sliding Sync `/sync` endpoint. ([\#17447](element-hq/synapse#17447)) - Add Account Data extension support to experimental [MSC3575](matrix-org/matrix-spec-proposals#3575) Sliding Sync `/sync` endpoint. ([\#17477](element-hq/synapse#17477)) - Add receipts extension support to experimental [MSC3575](matrix-org/matrix-spec-proposals#3575) Sliding Sync `/sync` endpoint. ([\#17489](element-hq/synapse#17489)) - Add typing notification extension support to experimental [MSC3575](matrix-org/matrix-spec-proposals#3575) Sliding Sync `/sync` endpoint. ([\#17505](element-hq/synapse#17505)) ### Bugfixes - Update experimental [MSC3575](matrix-org/matrix-spec-proposals#3575) Sliding Sync `/sync` endpoint to handle invite/knock rooms when filtering. ([\#17450](element-hq/synapse#17450)) - Fix a bug introduced in v1.110.0 which caused `/keys/query` to return incomplete results, leading to high network activity and CPU usage on Matrix clients. ([\#17499](element-hq/synapse#17499)) ### Improved Documentation - Update the [`allowed_local_3pids`](https://element-hq.github.io/synapse/v1.112/usage/configuration/config_documentation.html#allowed_local_3pids) config option's msisdn address to a working example. ([\#17476](element-hq/synapse#17476)) ### Internal Changes - Change sliding sync to use their own token format in preparation for storing per-connection state. ([\#17452](element-hq/synapse#17452)) - Ensure we don't send down negative `bump_stamp` in experimental sliding sync endpoint. ([\#17478](element-hq/synapse#17478)) - Do not send down empty room entries down experimental sliding sync endpoint. ([\#17479](element-hq/synapse#17479)) - Refactor Sliding Sync tests to better utilize the `SlidingSyncBase`. ([\#17481](element-hq/synapse#17481), [\#17482](element-hq/synapse#17482)) - Add some opentracing tags and logging to the experimental sliding sync implementation. ([\#17501](element-hq/synapse#17501)) - Split and move Sliding Sync tests so we have some more sane test file sizes. ([\#17504](element-hq/synapse#17504)) - Update the `limited` field description in the Sliding Sync response to accurately describe what it actually represents. ([\#17507](element-hq/synapse#17507)) - Easier to understand `timeline` assertions in Sliding Sync tests. ([\#17511](element-hq/synapse#17511)) - Reset the sliding sync connection if we don't recognize the per-connection state position. ([\#17529](element-hq/synapse#17529)) ### Updates to locked dependencies * Bump bcrypt from 4.1.3 to 4.2.0. ([\#17495](element-hq/synapse#17495)) * Bump black from 24.4.2 to 24.8.0. ([\#17522](element-hq/synapse#17522)) * Bump phonenumbers from 8.13.39 to 8.13.42. ([\#17521](element-hq/synapse#17521)) * Bump ruff from 0.5.4 to 0.5.5. ([\#17494](element-hq/synapse#17494)) * Bump serde_json from 1.0.120 to 1.0.121. ([\#17493](element-hq/synapse#17493)) * Bump serde_json from 1.0.121 to 1.0.122. ([\#17525](element-hq/synapse#17525)) * Bump towncrier from 23.11.0 to 24.7.1. ([\#17523](element-hq/synapse#17523)) * Bump types-pyopenssl from 24.1.0.20240425 to 24.1.0.20240722. ([\#17496](element-hq/synapse#17496)) * Bump types-setuptools from 70.1.0.20240627 to 71.1.0.20240726. ([\#17497](element-hq/synapse#17497))

proposals/4186-simplified-sliding-sync.md

richvdh

A few more comments, nothing terribly dramatic

proposals/4186-simplified-sliding-sync.md

richvdh · 2025-12-03T09:24:45Z

proposals/4186-simplified-sliding-sync.md

+> [!Note]
+> Synapse always returns 0 for `notification_count` and `highlight_count`


Hrm. In that case, it feels like we should leave it out of the spec, and only spec it once we know it can be implemented.

[I see this is listed as one of the "Open questions".]

Given this seems to be needed for EW support and there is an open PR, I'm minded to keep it unless we decide that EW should instead calculate all notifications client side. Otherwise we block EW support on doing another MSC

richvdh · 2025-12-03T09:26:34Z

proposals/4186-simplified-sliding-sync.md

+> Knock support hasn't been implemented in Synapse.
+
+
+### `StrippedHero` type


why is this a StrippedHero rather than just a Hero, ooi?

Ermh, not sure there is any reason thinking about it. I guess it comes from the fact that it isn't an actual member event maybe?

proposals/4186-simplified-sliding-sync.md

richvdh · 2025-12-03T09:31:47Z

proposals/4186-simplified-sliding-sync.md

+1. Duplication between room response `heroes` and `required_state` when specifying `lazy_members`, e.g. should we drop
+   `heroes` if we are returning membership events?
+1. <del>Should the room response include the user's current membership? The client can always request it via
+   `required_state`, but that may be wasted if the client doesn't need any other information from the member event.</del>
+1. Should we remove the `highlight_count` and `notification_count` fields, given clients increasingly must calculate
+   this themselves, and Synapse currently doesn't implement it nor does Element X use it.
+1. Should we support subscribing to rooms the user is not a member of, i.e. peeking for world readable rooms.
+1. Should we support timeline filtering?
+1. <del>Should we move `pos`, and other URL params, into the request body? This would allow web clients to cache the CORS
+   requests, rather than having to pre-flight each request.</del>
+1. How do we make it so that the clients don't have to send up the same body each time?


With the exception of "should we remove highlight_count and notification_count", I feel like the anser to most of these is just "let's just spec what we have".

proposals/4186-simplified-sliding-sync.md

richvdh · 2025-12-03T09:34:47Z

There are still lots of open threads on this MSC.

MadLittleMods · 2025-12-03T20:32:04Z

proposals/4186-simplified-sliding-sync.md

+| - | - | - | - |
+| `name` | `string` | No | Room name or calculated room name. |
+| `avatar` | `string` | No | Room avatar |
+| `heroes` | `[StrippedHero]` | No | A truncated list of users in the room that can be used to calculate the room name. Will first include joined users, then invited users, and then finally left users. The same as the `m.heroes` section in the `/v3/sync` [specification](https://spec.matrix.org/v1.16/client-server-api/#get_matrixclientv3sync_response-200_roomsummary) |


It might be nice to delegate heroes to an extension so we can evolve this logic as we wish.

While "heroes" and calculating a room display name are pretty established part of the spec, it's a very specific/narrow way to do things.

Just as an example of something up for interpretation that's mentioned in the spec:

Clients SHOULD use minimum 5 heroes to calculate room names where possible, but may use more or less to fit better with their user experience.

And as an example of evolving things, a future MSC could expand the hero extension to have an option to specify the number of heroes. Currently, Synapse will only ever return up to 5.

Or a client might not care about heroes at all, in which case, they don't need to enable the hero extension at all.

I'm not a fan of punting this to an extension, given that it is very fundamental to how one actually displays the room in the room list. Different clients really all should be showing the same name for a given room, otherwise it will cause a lot of confusion.

Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>

@SpiritCroc

# Synapse 1.139.0 (2025-09-30) ## Features - Add experimental support for [MSC4308: Thread Subscriptions extension to Sliding Sync](matrix-org/matrix-spec-proposals#4308) when [MSC4306: Thread Subscriptions](matrix-org/matrix-spec-proposals#4306) and [MSC4186: Simplified Sliding Sync](matrix-org/matrix-spec-proposals#4186) are enabled. ([\#18695](element-hq/synapse#18695)) - Update push rules for experimental [MSC4306: Thread Subscriptions](matrix-org/matrix-spec-proposals#4306) to follow a newer draft. ([\#18846](element-hq/synapse#18846)) - Add `get_media_upload_limits_for_user` and `on_media_upload_limit_exceeded` module API callbacks to the media repository. ([\#18848](element-hq/synapse#18848)) - Support [MSC4169](matrix-org/matrix-spec-proposals#4169) for backwards-compatible redaction sending using the `/send` endpoint. Contributed by @SpiritCroc @ Beeper. ([\#18898](element-hq/synapse#18898)) - Add an in-memory cache to `_get_e2e_cross_signing_signatures_for_devices` to reduce DB load. ([\#18899](element-hq/synapse#18899)) - Update [MSC4190](matrix-org/matrix-spec-proposals#4190) support to return correct errors and allow appservices to reset cross-signing keys without user-interactive authentication. Contributed by @tulir @ Beeper. ([\#18946](element-hq/synapse#18946)) ## Deprecations and Removals - Remove obsolete and experimental `/sync/e2ee` endpoint. ([\#18583](element-hq/synapse#18583)) # Synapse 1.138.0 (2025-09-09) ## Features - Support for the stable endpoint and scopes of [MSC3861](matrix-org/matrix-spec-proposals#3861) & co. ([\#18549](element-hq/synapse#18549))

proposals/4186-simplified-sliding-sync.md

…f the room name is not set

reivilibre · 2026-02-26T16:44:05Z

proposals/4186-simplified-sliding-sync.md

+| - | - | - | - |
+| `name` | `[string \| null]` | No | Room name or calculated room name. `null` if room name has been removed c.f. https://spec.matrix.org/v1.17/client-server-api/#mroomname |
+| `avatar` | `string` | No | Room avatar |
+| `heroes` | `[StrippedHero]` | No | A truncated list of users in the room that can be used to calculate the room name. Will first include joined users, then invited users, and then finally left users: the same users as the `m.heroes` section in the [`/v3/sync` specification](https://spec.matrix.org/v1.16/client-server-api/#get_matrixclientv3sync_response-200_roomsummary). <br/><br/> Heroes are only included if the room name is not set. |


Are we happy with this condition being 'if the room name is not set'
and not 'if both the room name and canonical alias are not set'

This question was also on MSC3575 at #3575 (comment)

and rightfully raised again in https://github.com/element-hq/synapse/pull/19468/changes#diff-c0aad0e609657962388a061f32f125ce5a28e8fa5b43be3b6aca679b68a1e76cR907

gingershaped

A few clarifying questions.

gingershaped · 2026-03-05T18:39:53Z

proposals/4186-simplified-sliding-sync.md

+for the client to start from scratch (e.g. because there are many updates to send down). This is done by responding with
+a 400 HTTP status and an error code of `M_UNKNOWN_POS`.
+
+A `pos` token can be used in `/messages` and `/relations` APIs.


The prev_batch is described further down for use with /messages. Is pos supposed to supplement prev_batch? Is prev_batch supposed to work with /relations as well?

Previous discussion, #4186 (comment)

gingershaped · 2026-03-05T18:41:01Z

proposals/4186-simplified-sliding-sync.md

+| - | - | - | - |
+| `conn_id` | `string` | No | An optional string to identify this connection to the server. Only one sliding sync connection is allowed per given `conn_id` (empty or not). |
+| `pos` | string | No | Omitted if this is the first request of a connection (initial sync). Otherwise, the `pos` token from the previous call to `/sync` |
+| `timeout` | int | No | How long to wait for new events in milliseconds. If omitted the response is always returned immediately, even if there are no changes. Ignored when no `pos` is set. |


Is the behavior of timeout=0 the same as not specifying timeout?

gingershaped · 2026-03-05T18:45:45Z

proposals/4186-simplified-sliding-sync.md

+Rooms that the user has been in but left are only included if the room was previously sent to the client in that
+connection. Rooms the user has been kicked or banned from will always be included. We do not include rooms the user has
+left themselves to save bandwidth and general efficiency (as the user knows they've left), but we still include kicked
+and banned rooms as a) this should be uncommon, and b) the user may not have seen that they've been kicked/banned from


If a user is banned or kicked from a room, does this mean that the room will be repeatedly synchronized until activity in other rooms pushes it out of the range window?

gingershaped · 2026-03-05T18:46:20Z

proposals/4186-simplified-sliding-sync.md

+and banned rooms as a) this should be uncommon, and b) the user may not have seen that they've been kicked/banned from
+the room otherwise.
+
+A "list" is then a set of filters (e.g. only match invites, or DM rooms, etc) plus a "range" that indexes into the


Do filters apply to banned/kicked rooms?

gingershaped · 2026-03-05T18:49:24Z

proposals/4186-simplified-sliding-sync.md

+| - | - | - | - |
+| `timeline_limit` | `int` | Yes | The maximum number of timeline events to return per response. The server may cap this number. |
+| `required_state` | `RequiredStateRequest` | Yes | Required state for each room returned. |
+| `range` | `[int, int]` | No | Sliding window range. If this field is missing, no sliding window is used and all rooms are returned in this list. Integers are *inclusive*, and are 0-indexed. (This is a 2-tuple.) |


Does "all rooms" mean "all rooms where the syncing user has a membership event"? Also, presumably filters are still applied even if range isn't specified?

gingershaped · 2026-03-05T18:53:13Z

proposals/4186-simplified-sliding-sync.md

+| Name | Type | Required | Comment |
+| - | - | - | - |
+| `name` | `[string \| null]` | No | Room name or calculated room name. `null` if room name has been removed c.f. https://spec.matrix.org/v1.17/client-server-api/#mroomname |
+| `avatar` | `string` | No | Room avatar |


Does an empty string indicate that the avatar has been removed? If so, should this also accept null, as name does?

gingershaped · 2026-03-05T18:53:55Z

proposals/4186-simplified-sliding-sync.md

+| `name` | `[string \| null]` | No | Room name or calculated room name. `null` if room name has been removed c.f. https://spec.matrix.org/v1.17/client-server-api/#mroomname |
+| `avatar` | `string` | No | Room avatar |
+| `heroes` | `[StrippedHero]` | No | A truncated list of users in the room that can be used to calculate the room name. Will first include joined users, then invited users, and then finally left users: the same users as the `m.heroes` section in the [`/v3/sync` specification](https://spec.matrix.org/v1.16/client-server-api/#get_matrixclientv3sync_response-200_roomsummary). <br/><br/> Heroes are only included if the room name is not set. |
+| `is_dm` | `bool` | No | Flag to specify whether the room is a direct-message room (according to account data). If absent the room is not a DM room. |


Presumably this should be sent in non-initial syncs if the corresponding account data field changes?

gingershaped · 2026-03-05T18:56:33Z

proposals/4186-simplified-sliding-sync.md

+| - | - | - | - |
+| `stripped_state` | `[StrippedState]` | Yes  | Stripped state events (for rooms where the user is invited). Same as `rooms.invite.$room_id.invite_state` for invites in `/v3/sync`. |
+
+The reason the full fields from the previous section can't be included is because we don't have any of that information


Is including those fields explicitly forbidden? Presumably some of them (like is_dm for invites, possibly initial) should be included.

gingershaped · 2026-03-05T18:59:13Z

proposals/4186-simplified-sliding-sync.md

+See the API section below for exactly what is returned. A subset may be returned if the user does not have permission to
+view the room, e.g. if they are invited but not yet joined to the room.
+
+The server MUST NOT send any room information down that the user does not have permission to see. Specifically, the


This sounds equivalent to the user having a membership state event in the room. Is that correct?

gingershaped · 2026-03-05T20:13:13Z

proposals/4186-simplified-sliding-sync.md

+
+The fields are combined by taking the "superset", i.e.:
+- `timeline_limit` — take the maximum timeline limit across all room configs.
+- `required_state` — take the union of the required state fields, i.e. if a state event would be returned by any room


Presumably this means that include and exclude are merged together, and lazy_members is true if any of them are true?

Simplified sliding sync

8cc34df

erikjohnston force-pushed the erikj/sss branch from 806e455 to 8cc34df Compare August 30, 2024 09:25

erikjohnston added 2 commits August 30, 2024 10:52

Add example usage

456db3b

Add security and unstable prefix

6fe4ba7

erikjohnston marked this pull request as ready for review August 30, 2024 09:59

Gnuxie reviewed Aug 30, 2024

View reviewed changes

proposals/4186-simplified-sliding-sync.md Outdated Show resolved Hide resolved

anoadragon453 added feature Suggestion for a significant extension which needs considerable consideration proposal A matrix spec change proposal kind:core MSC which is critical to the protocol's success labels Aug 30, 2024

uhoreg added the client-server Client-Server API label Aug 30, 2024

turt2live added the needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. label Aug 30, 2024

turt2live reviewed Aug 30, 2024

View reviewed changes

Gnuxie reviewed Aug 30, 2024

View reviewed changes

proposals/4186-simplified-sliding-sync.md Outdated Show resolved Hide resolved

Gnuxie reviewed Aug 30, 2024

View reviewed changes

proposals/4186-simplified-sliding-sync.md Outdated Show resolved Hide resolved

erebion mentioned this pull request Sep 3, 2024

Sliding Sync does not seem to work element-hq/synapse#17651

Closed

Johennes reviewed Sep 3, 2024

View reviewed changes

proposals/4186-simplified-sliding-sync.md Outdated Show resolved Hide resolved

clokep reviewed Sep 3, 2024

View reviewed changes

MadLittleMods reviewed Sep 5, 2024

View reviewed changes

proposals/4186-simplified-sliding-sync.md Outdated Show resolved Hide resolved

MadLittleMods reviewed Sep 5, 2024

View reviewed changes

proposals/4186-simplified-sliding-sync.md Outdated Show resolved Hide resolved

MadLittleMods mentioned this pull request Sep 5, 2024

MSC3575: Sliding Sync (aka Sync v3) #3575

Closed

MadLittleMods reviewed Sep 5, 2024

View reviewed changes

proposals/4186-simplified-sliding-sync.md Outdated Show resolved Hide resolved

MadLittleMods reviewed Sep 5, 2024

View reviewed changes

This was referenced Sep 9, 2024

fix(sdk): Mark tracked users as dirty when the SS connection is reset. matrix-org/matrix-rust-sdk#3965

Merged

client-api: Implement MSC4186 ruma/ruma#1907

Merged

kfiven mentioned this pull request Sep 14, 2024

Sliding sync cinnyapp/cinny#1436

Open

deepbluev7 reviewed Sep 19, 2024

View reviewed changes

proposals/4186-simplified-sliding-sync.md Outdated Show resolved Hide resolved

MadLittleMods reviewed Sep 19, 2024

View reviewed changes

proposals/4186-simplified-sliding-sync.md Outdated Show resolved Hide resolved

MadLittleMods reviewed Sep 19, 2024

View reviewed changes

proposals/4186-simplified-sliding-sync.md Outdated Show resolved Hide resolved

Remove spurious receipts claim

564839a

richvdh requested changes Dec 3, 2025

View reviewed changes

MadLittleMods reviewed Dec 3, 2025

View reviewed changes

erikjohnston and others added 2 commits December 10, 2025 17:09

Apply suggestions from code review

93a1069

Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>

Rewrap lines

7d066fb

HarHarLinks mentioned this pull request Dec 16, 2025

add matrix.org homeserver experimental features policy matrix-org/matrix.org#3089

Draft

erikjohnston added 5 commits January 27, 2026 16:33

Clarify 'common fields' and 'membership'

2b969b0

Bump stamp can be omitted

ec5a540

List names should be 'opaque identifies'

d34d7d6

Explicitly call out changes of limited and membership caches

fea5bf8

Note that not filtering lazy members is an arbitrary decision

1fade2f

MadLittleMods mentioned this pull request Jan 28, 2026

Fix sliding sync performance slow down for long lived connections. element-hq/synapse#19206

Merged

erikjohnston added 6 commits February 4, 2026 14:14

Note that we do not support timeline filtering

68f16e8

Remove TODOs

9111f3d

Remove warning around lack of knock support

76fce76

Note that pos token should be usable in the other APIs

40855ba

Note difference with v3/sync for lazy loaded

8c9ae99

Note bump_stamp is non-unique

16b4852

frebib reviewed Feb 10, 2026

View reviewed changes

proposals/4186-simplified-sliding-sync.md Outdated Show resolved Hide resolved

cloudrac3r reviewed Feb 10, 2026

View reviewed changes

proposals/4186-simplified-sliding-sync.md Outdated Show resolved Hide resolved

MadLittleMods mentioned this pull request Feb 16, 2026

Member events for sender of events in sync timeline missing from state_after element-hq/synapse#19455

Closed

erikjohnston added 3 commits February 18, 2026 14:00

Note conn_id is scoped to used and device

1ce0bc1

Note that room name can be unset, and that heroes are only included i…

36bb63c

…f the room name is not set

Fix spelling

deb16f6

MadLittleMods mentioned this pull request Feb 25, 2026

SSS appears to burn huge amounts of bandwidth returning obsolete ops fields element-hq/synapse#18517

Open

reivilibre reviewed Feb 26, 2026

View reviewed changes

gingershaped reviewed Mar 5, 2026

View reviewed changes

turt2live assigned erikjohnston Mar 10, 2026

		> [!Note]
		> Synapse always returns 0 for `notification_count` and `highlight_count`

		> Knock support hasn't been implemented in Synapse.


		### `StrippedHero` type

Conversation

erikjohnston commented Aug 30, 2024 • edited by turt2live Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Synapse server implementation

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

MadLittleMods Sep 5, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

richvdh left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

richvdh commented Dec 3, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gingershaped left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

erikjohnston commented Aug 30, 2024 •

edited by turt2live

Loading

MadLittleMods Sep 5, 2024 •

edited

Loading