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.

[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"]
    }
  }
}