Conversation
clokep
added
proposal
There was a problem hiding this comment.
Implementation requirements:
- Client
- Server
There was a problem hiding this comment.
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
left a comment
anoadragon453
left a comment
There was a problem hiding this comment.
@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.
There was a problem hiding this comment.
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.
|
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! 😊 |
The previous wording was alluding to the fact that the field isn't "sticky". But readers probably won't have that assumption anyways, so let's just remove it.
| { | ||
| // extensions is a top-level field in the response body. | ||
| "extensions": { | ||
| "profiles": { |
There was a problem hiding this comment.
It's the dreaded question again: is there going to be any pagination, so the server doesn't send unboundedly large responses here? If so, how will it work?
matrix-org/matrix-spec#2378
There was a problem hiding this comment.
I don't believe there's any reason an HS couldn't split a profile with many fields up into several sync responses: I don't think there's any meaning attached to them arriving together or separately. Each field should be small.
There was a problem hiding this comment.
Feels like pagination should work similarly to how existing implementations are handling it, for example thread subscriptions / MSC4308.
| The `fields` parameter is optional. If omitted, *all* profile fields will be in | ||
| scope. |
There was a problem hiding this comment.
Note that this differs from the semantics of the profile_fields.ids parameter of MSC4429, where omitting the parameter means no profile fields will be in scope.
The goal is to not suddenly start sending profile fields to legacy clients. Instead, they must opt-in. In legacy sync, that opt-in is done by providing the profile_fields.ids parameter. In sliding sync, clients opt-in to extensions via setting their *.enabled boolean. From there, all other parameters assume the client wants profile fields.
Therefore, if we defined an omitted fields parameter to mean "no profile updates" (like in MSC4429), you'd have:
{
"enabled": true
}which wouldn't result in any fields being sent down. And that's practically useless. So instead we define it as "all fields".
I don't have a good use case for "receive updates to all known profile fields" yet, as clients will usually only want to receive updates for the fields they've built UI for already.
Perhaps if you're looking at a user's profile, showing all set fields, even unknown ones, and you want that UI to update in real time? 🤷 Interested in anyone has any other use cases.
This PR implements support for profile updates over Sliding Sync: matrix-org/matrix-spec-proposals#4262. This pr may be easier to review as a whole than commit by commit. This builds on the legacy sync profile updates feature #19556, specifically the profile updates stream it added. Submitting for early review to get consensus on implementation. There are some things we would like to add still, from spec, mainly: * > Homeservers should only consider a profile field update "accepted" by a client > once the client returns with a new /sync request with the next /sync token, > NOT just after sending down the profile update. The client may never receive > response due to network conditions, or a bug in the client implementation. * > When a room enters this subset in this connection for the first time, all requested > fields from profiles of users in that room MAY be sent down. This gives the client > a base set of information for which future field updates can be applied on top of. > The homeserver MAY omit some fields and profiles if it believes that the client has > already received them, likewise repeat profiles MAY be sent down based on homeserver > implementation. * > Finally, if the list of fields expands to cover a new field ID, those fields should > be sent down for all users that are within the current room subset. Future incremental > updates will then include changes to this field. * Additionally, we would need to implement a lazy loading cache similar to the legacy sync. (not part of MSC as such) Depending on review these could either be added to this pr, or to keep this pr from not growing too much, be added in a follow-up pr, as they are more enhancement to this base sliding sync profile updates functionality than a part of the core functionality. ### Pull Request Checklist <!-- Please read https://element-hq.github.io/synapse/latest/development/contributing_guide.html before submitting your pull request --> * [x] Pull request is based on the develop branch * [x] Pull request includes a [changelog file](https://element-hq.github.io/synapse/latest/development/contributing_guide.html#changelog). The entry should: - Be a short description of your change which makes sense to users. "Fixed a bug that prevented receiving messages from other servers." instead of "Moved X method from `EventStore` to `EventWorkerStore`.". - Use markdown where necessary, mostly for `code blocks`. - End with either a period (.) or an exclamation mark (!). - Start with a capital letter. - Feel free to credit yourself, by adding a sentence "Contributed by @github_username." or "Contributed by [Your Name]." to the end of the entry. * [x] [Code style](https://element-hq.github.io/synapse/latest/code_style.html) is correct (run the [linters](https://element-hq.github.io/synapse/latest/development/contributing_guide.html#run-the-linters)) --------- Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> Co-authored-by: Olivier 'reivilibre' <olivier@librepush.net> Co-authored-by: Olivier 'reivilibre <oliverw@element.io>
Tested on NetBSD 10 amd64 with 2026Q2 environment. # Synapse 1.160.0 (2026-09-02) ## Features - Add experimental support for [MSC4502](matrix-org/matrix-spec-proposals#4502): Targeted and unrestricted room member queries. ([\#19974](element-hq/synapse#19974)) - Add optional support for [MSC4262: Profile Updates for Sliding Sync](matrix-org/matrix-spec-proposals#4262). Currently defaults to disabled, and is limited to local users only for the sync results. ([\#20003](element-hq/synapse#20003)) - Allow specifying multiple `action_name` and `status` query parameters when listing scheduled tasks via the admin API. ([\#20067](element-hq/synapse#20067)) # Synapse 1.159.0 (2026-08-18) ## Features - Add optional support for [MSC4429: Profile Updates for Legacy Sync](matrix-org/matrix-spec-proposals#4429). Currently defaults to not enabled, and is limited to local users only for the sync results. ([\#19556](element-hq/synapse#19556))
10 participants
Rendered
Signed-off-by: Tom Foster tom@tcpip.uk
Known Implementations: