matrix-spec-proposals/proposals/4069-inhibit-profile-propagation.md

MSC4069: Inhibit profile propagation

The current PUT /avatar_url and PUT /displayname endpoints modify the "global" profile for the user. This profile is typically exposed through the user directory and other similar room-less places. Servers are additionally required to update the m.room.member (and similar) events for the user with the new profile information.

Some applications prefer to manually manage the profile updates in-room and over presence, as they may need to enable per-space, per-room, or other sufficiently limited profile updates. Instead of waiting for the server to update the user's profile everywhere before "fixing" the events, it could ask the server to not update the events in the first place. This proposal introduces an optional flag to enable that exact functionality.

A somewhat more niche usage of this MSC might be a project like matrix-media-repo aiming to implement MSC3911: when the user's avatar URL is changed, the media repo can intercept the request, proxy it forward to the homeserver as inhibited, then manually copy the media enough times to update all the user's joined rooms. This approach would reduce the number of custom endpoints required by a homeserver for MMR integration.

Proposal

The following two endpoints gain an optional new query parameter: propagate. The value MUST be a boolean, and defaults to true if not provided. If the value is not a boolean, a normal 400 Bad Request error code is returned.

• PUT /avatar_url
• PUT /displayname

With respect to MSC3911, when the user updates their profile's avatar with ?propagate=false, the media they use is not cloned nor used in event updates. The client can manually clone the media if they prefer using MSC3911's copy API.

Some servers use different rate limits depending on whether the client is using the profile APIs or state APIs. This proposal suggests no changes to the rate limits, though servers may wish to apply intelligent rate limits to state event changes. For example, detecting that the user is updating their profile information in a subset of rooms shortly after updating their global profile.

Potential issues

This adds a bit of API bloat for a relatively uncommon feature, though may enable other features to be more readily possible. For example, a client introducing per-space memberships might use this new query parameter to make it easier to manually apply m.room.member event changes.

Alternatives

Currently Discord bridges will update the global user profile, wait for that to complete (which can take minutes), then manually fix all of the m.room.member events for the user to accomplish proper platform bridging. While this does work, it is often slow and unreliable when the server takes an eternity to complete the profile change request due to a large number of rooms needing updates. Some servers, like t2bot.io, instead decide to patch their server software to enforce this MSC's behaviour with a more blunt instrument.

Security considerations

No major security considerations required. This MSC effectively reduces spam, though may affect a user's perceivable privacy. Clients should be careful to explain where a user's profile updates will be visible, regardless of this MSC.

Unstable prefix

While this MSC is not considered stable, clients can use ?org.matrix.msc4069.propagate instead of ?propagate. To ensure the server supports the functionality before a spec release, clients should look for the unstable feature org.matrix.msc4069.

Once this MSC has successfully passed a merge FCP, clients can (and should) send both ?propagate and ?org.matrix.msc4069.propagate to ensure backwards compatibility with slightly old servers.

Once released in the specification, clients should be checking for server support through advertised spec versions instead.

Dependencies

This MSC has no dependencies.