MSC4429: Profile Updates for Legacy Sync

[anoadragon453]

Rendered

Conflict of Interest declaration: I am employed by Element. This MSC was written as part of my work on the Element Backend Team to land a "user status" feature (based on top of custom profiles, see MSC4426) for a customer.

Implementations:

• Element Web (merged)
• Synapse (include_profile_updates_in_sync option)

[turt2live]

Implementation requirements:

• Client (using)
• Server (sending)

[Half-Shot]

• Server Introduce support for MSC4429: Profile Updates for Legacy Sync element-hq/synapse#19556
• Client Implement MSC4429: Profile Updates for Legacy Sync matrix-js-sdk#5246

[Copilot]

Pull request overview

Adds a new MSC proposing how to deliver custom profile field updates over legacy /sync (similar in spirit to MSC4262 for Sliding Sync), including opt-in filtering and guidance for initial population/lazy-loading.

Changes:

• Proposes a new top-level users object in /sync carrying per-user profile_updates.
• Introduces a new filter field (profile_fields.ids) to opt-in to specific profile field IDs.
• Documents expected server/client behavior (initial sync behavior, lazy-loading interactions, implementation notes).

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[anoadragon453]

@zecakeh pointed out on the equivalent Sliding Sync MSC that:

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.

So actually null is a valid value, and we can't use it as a signal to clients that a field has been deleted, unfortunately.

Instead, we'll probably want a removed_profile_fields array or similar:

{
  "users": {
    "@user:example.org": {
      "profile_updates": {
          "m.status": {
	        "text": "Swimming in the Great Lakes!",
	        "emoji": "🏊️"
	      },
      },
      "removed_profile_fields": ["m.other_field"]
    }
  }
}

[clokep]

This sounds like it is re-treading conversations in #3391

[dbkr]

This sounds like it is re-treading conversations in #3391

I'm not sure, in this case there's already an established mechanism to delete a profile field (DELETE), that was about whether to add one.

What about either defining undefined as a deletion or else just changing it in this MSC so null is not an acceptable value? Having to add a separate field to track removed fields seems just unnecessary.

[reivilibre]

It would be very beneficial if the server could flag the difference between a profile delta and a complete profile to replace whatever the client has in cache.

Without that distinction, the server is limited in how much clean-up it can do; it has to (at the very least) remember the whole set of 'removed profile fields' for all of time.

Why? Because we never know what state the client is in. If we want to clean up our deltas server-side, we will have to, at some point, tell clients 'you are too old to get just the delta, here's the whole profile instead'.
Since we can only currently speak in deltas, then sending a 'whole profile' involves tracking all field names that we might have sent to a client in the past.

Maybe the keys we reserve are something like:

• profile: (fields)
• profile_reset: true (marks this as a 'whole profile', not a delta. Should this be automatically implied for an initial sync?)
• profile_remove: list of removed field names

You could, I suppose, make profile_remove: true the 'whole profile' marker. I don't know if that kind of double-duty is a good or bad thing. profile_reset and profile_remove do in fact clash so this 'naturally' resolves that clash by making it impossible

[reivilibre]

It is what it is, but profile_updates feels like a chunky key when it could have been called profile. It will be repeated a lot of times in the response body potentially.

[reivilibre]

Should include_redundant_members semantics apply also to profiles?

[dbkr]

Could you clarify what you mean here? Profile fields are sent when the profile updates, not with every event like member events?

[reivilibre]

As far as I understand it, include_redundant_members means that when using lazy-loading sync, you get sent those user's membership events every time they appear in the timeline, not just the first time they appear in the timeline.
This is useful for clients that don't maintain a persistent cache of users, so they can always display the relevant information in-context without having to make CS API requests first.

The question is whether this exact same system should apply also to the profiles sent down when lazy-loading. You could imagine the same argument applying: clients might want to show the 'away' state next to the user's name and may not maintain a cache. The client might have been 're-launched' since witnessing the first timeline event from a given user, which is how they would have received their profile fields.

[reivilibre]

I am partly wondering if this is actually necessary; would clients know to delete their profile cache because they already saw the user leave on their own?

[Half-Shot]

Clients will not always know if they no longer share a room with a user, for instance if the room was lazy-loaded.

[benkuly]

More general: Why not put them into the member events like already done with displayname and avatar? Now we have two places to gather profile information.

[dbkr]

Profile fields are global and not based on per-room member events so I don't believe tacking them onto existing member events would make sense.

[benkuly]

But who decides what is global? Shouldn't we consider to remove these information from the member event to have one single source of truth?

[reivilibre]

Putting them in per-room member events means we have the same ambiguity problems about what is intended to be global and what is intended to be per-room (e.g. per-room nicknames), so you don't know what you can and can't put in the user directory (for example) or use as a response to /profile.
The current profiles system (which is global) makes a lot of sense for this reason.

At the same time, removing the displayname and avatar from member events means that if the user's homeserver goes down, a new user joining the room won't know their name (or avatar). So there is some value in having these baked into the room state, even though the state bloat is undesirable.
(Either way, they can't be removed from room state yet for backwards compatibility reasons)