MSC4262: Sliding Sync Extension: Profile Updates by tcpipuk · Pull Request #4262 · matrix-org/matrix-spec-proposals

tcpipuk · 2025-02-03T13:16:06Z

Signed-off-by: Tom Foster tom@tcpip.uk

Known Implementations:

Clients:
Servers:

turt2live · 2025-02-14T17:27:29Z

Implementation requirements:

Client

Server

Implementation authors should be aware that their implementations (especially Synapse) may currently differ from the accepted underlying MSC4186: Simplified Sliding Sync document contents. See the bottom of that MSC for a list of implementation differences.

This MSC is written against the accepted version of MSC4186's definition of sliding sync.

pixlwave · 2026-05-28T14:53:17Z

+{
+    "users": {
+        "@alice:example.com": {
+            "displayname": "Alice",
+            "avatar_url": "mxc://example.com/abc123",
+            "org.example.language": "en-GB"
+        },
+        "@bob:example.com": {
+            "displayname": null  // Field removal
+        }
+    }
+}


I'm looking at implementing this for Element X but it isn't immediately clear to me where in the SSS response this is expected to be. Could you clarify if it is

as shown here and becomes a new top-level object.

nested within the extensions object (it seems slightly odd that the extension would be called profiles but the object returned is then called users).

adding the custom profile fields to an existing users e.g. if there is such a thing within rooms.

pixlwave · 2026-05-28T14:56:13Z

+   - If true, the server MAY include recent profile changes that occurred before the sync
+
+4. On an initial sync:
+   - Profile data MUST only be sent for rooms returned in the sliding sync response


How does this interact with the lazy_members flag? Presumably it should only return the profile data for members that have been included in the rooms response too, otherwise the initial sync could be massive if it includes e.g. matrix-hq?

We ended up doing this to avoid performance problems in the legacy sync variant of this MSC: https://github.com/matrix-org/matrix-spec-proposals/pull/4429/changes#diff-ff7b92bd96566832eba816741b724860e898458319a5e7aaf3bb4626b629fb07R175

pixlwave · 2026-05-28T15:13:53Z

+
+### Behaviour
+
+1. The extension only returns profile updates for users who are members of rooms that the client is


Out of interest, is it expected for the user's own profile to be included too? This would provide a nice way to subscribe to the user's global profile for changes from other devices which I don't think exists right now (and maybe it could be included, even if the user isn't part of any rooms). Either way, the MSC should presumably explicitly mention the expected behaviour here.

I had a similar question while reviewing MSC4186. There, a leave for a given room is only sent down to the client if the room that was left was previously sent to the client in that connection.

Seems this MSC could specify a similar rule when choosing which rooms to include profile updates for.

pixlwave · 2026-05-29T17:20:41Z

+}
+```
+
+If `enabled` is `true`, then the sliding sync response MAY include profile updates in the following format:


I've also been wondering how this extension would interact with the heroes portion of the sync response too. Would the idea be that the client keeps track of these global profiles and automatically merges the new fields (i.e. everything but avatar/name) with each room's heroes?

zecakeh · 2026-06-24T11:50:11Z

+   - Profile updates MUST be sent as the server receives them
+   - For rooms which initially appear (`initial: true`) due to direct subscriptions or rooms moving
+     into the sliding window, current profile states MUST be included
+   - A null value for a field indicates the field has been removed


This conflicts with the profile endpoints of the CS API where setting a value to null doesn't remove the profile field, and might be an acceptable value since extended profiles were merged into the spec.

From the definition of PUT /profile/{userId}/{keyName}:

Servers MAY reject null values. Servers that accept null values SHOULD store them rather than treating null as a deletion request. Clients that want to delete a field, including its key and value, SHOULD use the DELETE endpoint instead.

anoadragon453

@tcpipuk would you be opposed to myself taking over updating and maintaining this MSC? Element are currently looking to implement it as part of our work on MSC4426: User Status Profile Fields.

anoadragon453 · 2026-07-02T10:21:09Z

+This MSC is an extension to [MSC3575](https://github.com/matrix-org/matrix-spec-proposals/pull/3575)
+(and its proposed successor [MSC4186](https://github.com/matrix-org/matrix-spec-proposals/pull/4186))
+which adds support for receiving profile updates via Sliding Sync. It complements


This MSC should be updated to focus on extending MSC4186, now that it has been accepted.

anoadragon453 · 2026-07-02T10:26:07Z

Implementation authors should be aware that their implementations (especially Synapse) may currently differ from the accepted underlying MSC4186: Simplified Sliding Sync document contents. See the bottom of that MSC for a list of implementation differences.

This MSC is written against the accepted version of MSC4186's definition of sliding sync.

anoadragon453 · 2026-07-02T10:44:59Z

+
+### Behaviour
+
+1. The extension only returns profile updates for users who are members of rooms that the client is


I had a similar question while reviewing MSC4186. There, a leave for a given room is only sent down to the client if the room that was left was previously sent to the client in that connection.

Seems this MSC could specify a similar rule when choosing which rooms to include profile updates for.

anoadragon453 · 2026-07-02T10:52:26Z

+3. The optional `include_history` argument controls whether the initial sync includes recent
+   historical profile changes:
+   - If false (default), only current profile states are sent on initial sync
+   - If true, the server MAY include recent profile changes that occurred before the sync


Why would a client want previous profile data? Do homeservers even store historical profile state (Synapse doesn't)?

I believe the objective was to show changes that occurred within the last minute or two before sync to understand whether a field has just updated, but a little time has passed so it's entirely possible I was on crack! 😄

anoadragon453 · 2026-07-02T10:53:48Z

+   - If true, the server MAY include recent profile changes that occurred before the sync
+
+4. On an initial sync:
+   - Profile data MUST only be sent for rooms returned in the sliding sync response


We ended up doing this to avoid performance problems in the legacy sync variant of this MSC: https://github.com/matrix-org/matrix-spec-proposals/pull/4429/changes#diff-ff7b92bd96566832eba816741b724860e898458319a5e7aaf3bb4626b629fb07R175

anoadragon453 · 2026-07-02T11:05:56Z

+No unstable prefix as Sliding Sync is still in review. To enable this extension, add this to your
+request JSON:


Different now!

tcpipuk · 2026-07-02T11:15:36Z

Thank you for the offer, @anoadragon453 - I've let this one lapse because of a lot of life events over the last 12 months, so would be all too happy for you to shepherd this one through for Element (and the community's) benefit! 😊

tcpipuk added 4 commits February 3, 2025 13:14

MSC4262 initial commit

c02657e

Correct line wrapping

b1edd39

Reference MSC4186

cd8654f

Unwanted space characters

cdf2d47

clokep added proposal A matrix spec change proposal. Process state. A-Client Server Client-Server API kind:feature MSC for not-core and not-maintenance stuff needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. labels Feb 3, 2025

turt2live reviewed Feb 14, 2025

View reviewed changes

pixlwave reviewed May 28, 2026

View reviewed changes

pixlwave reviewed May 29, 2026

View reviewed changes

This was referenced Jun 8, 2026

Add support for MSC4262 (Profile Updates Sliding Sync Extension). ruma/ruma#2499

Merged

[Task] Add support for setting and reading m.status and m.call profile fields via MSC4426 matrix-org/matrix-rust-sdk#6616

Open

zecakeh reviewed Jun 24, 2026

View reviewed changes

zecakeh mentioned this pull request Jun 24, 2026

Add a merge function to UserProfile for handling sync responses. ruma/ruma#2518

Merged

anoadragon453 requested changes Jul 2, 2026

View reviewed changes


		### Behaviour

		1. The extension only returns profile updates for users who are members of rooms that the client is

		No unstable prefix as Sliding Sync is still in review. To enable this extension, add this to your
		request JSON:

Uh oh!

Conversation

tcpipuk commented Feb 3, 2025

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!

pixlwave May 28, 2026 • 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!

Choose a reason for hiding this comment

Uh oh!

pixlwave May 28, 2026 • 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!

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!

anoadragon453 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!

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!

tcpipuk commented Jul 2, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

pixlwave May 28, 2026 •

edited

Loading

pixlwave May 28, 2026 •

edited

Loading