From 8143d89cc3c9a5f601b55a904d3d294995f901cb Mon Sep 17 00:00:00 2001 From: Travis Ralston Date: Sun, 22 Oct 2023 22:16:19 -0600 Subject: [PATCH 1/3] MSC: Inhibit profile propagation --- proposals/0000-inhibit-profile-propagation.md | 77 +++++++++++++++++++ 1 file changed, 77 insertions(+) create mode 100644 proposals/0000-inhibit-profile-propagation.md diff --git a/proposals/0000-inhibit-profile-propagation.md b/proposals/0000-inhibit-profile-propagation.md new file mode 100644 index 00000000000..abece8a1282 --- /dev/null +++ b/proposals/0000-inhibit-profile-propagation.md @@ -0,0 +1,77 @@ +# MSC0000: Inhibit profile propagation + +The current [`PUT /avatar_url`](https://spec.matrix.org/v1.8/client-server-api/#put_matrixclientv3profileuseridavatar_url) +and [`PUT /displayname`](https://spec.matrix.org/v1.8/client-server-api/#put_matrixclientv3profileuseriddisplayname) +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](https://spec.matrix.org/v1.8/client-server-api/#events-on-change-of-profile-information) +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](https://github.com/turt2live/matrix-media-repo) +aiming to implement [MSC3911](https://github.com/matrix-org/matrix-spec-proposals/pull/3911): 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`](https://spec.matrix.org/v1.8/client-server-api/#put_matrixclientv3profileuseridavatar_url) +* [`PUT /displayname`](https://spec.matrix.org/v1.8/client-server-api/#put_matrixclientv3profileuseriddisplayname) + +With respect to [MSC3911](https://github.com/matrix-org/matrix-spec-proposals/pull/3911), 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](https://github.com/t2bot/synapse/commit/049cacfc2d9e98fc602b85978c70363ce3c4f52f) +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.msc0000.propagate` instead of +`?propagate`. To ensure the server supports the functionality before a spec release, clients should +look for the unstable feature `org.matrix.msc0000`. + +Once this MSC has successfully passed a merge FCP, clients can (and should) send *both* `?propagate` +and `?org.matrix.msc0000.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. From 58f726ba8212b6bb071b968e6c2c4e9d1f786078 Mon Sep 17 00:00:00 2001 From: Travis Ralston Date: Sun, 22 Oct 2023 22:17:31 -0600 Subject: [PATCH 2/3] Assign number --- ...propagation.md => 4069-inhibit-profile-propagation.md} | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) rename proposals/{0000-inhibit-profile-propagation.md => 4069-inhibit-profile-propagation.md} (95%) diff --git a/proposals/0000-inhibit-profile-propagation.md b/proposals/4069-inhibit-profile-propagation.md similarity index 95% rename from proposals/0000-inhibit-profile-propagation.md rename to proposals/4069-inhibit-profile-propagation.md index abece8a1282..a1adedb2f9e 100644 --- a/proposals/0000-inhibit-profile-propagation.md +++ b/proposals/4069-inhibit-profile-propagation.md @@ -1,4 +1,4 @@ -# MSC0000: Inhibit profile propagation +# MSC4069: Inhibit profile propagation The current [`PUT /avatar_url`](https://spec.matrix.org/v1.8/client-server-api/#put_matrixclientv3profileuseridavatar_url) and [`PUT /displayname`](https://spec.matrix.org/v1.8/client-server-api/#put_matrixclientv3profileuseriddisplayname) @@ -62,12 +62,12 @@ will be visible, regardless of this MSC. ## Unstable prefix -While this MSC is not considered stable, clients can use `?org.matrix.msc0000.propagate` instead of +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.msc0000`. +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.msc0000.propagate` to ensure backwards compatibility with slightly old servers. +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. From 8e6e8acd877dbae5cfca93bdae994870c6f63f4b Mon Sep 17 00:00:00 2001 From: Travis Ralston Date: Sun, 22 Oct 2023 22:26:20 -0600 Subject: [PATCH 3/3] Spec propagate=false --- proposals/4069-inhibit-profile-propagation.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/proposals/4069-inhibit-profile-propagation.md b/proposals/4069-inhibit-profile-propagation.md index a1adedb2f9e..aa423d2d6c9 100644 --- a/proposals/4069-inhibit-profile-propagation.md +++ b/proposals/4069-inhibit-profile-propagation.md @@ -29,6 +29,14 @@ Request error code is returned. * [`PUT /avatar_url`](https://spec.matrix.org/v1.8/client-server-api/#put_matrixclientv3profileuseridavatar_url) * [`PUT /displayname`](https://spec.matrix.org/v1.8/client-server-api/#put_matrixclientv3profileuseriddisplayname) +When `false`, `m.room.member` and `m.presence` events are *not* emitted automatically by the server +during execution of the above two endpoints. Servers should still perform this bit of the spec, +however: + +> Additionally, when homeservers emit room membership events for their own users, they should +> include the display name and avatar URL fields in these events so that clients already have these +> details to hand, and do not have to perform extra round trips to query it. + With respect to [MSC3911](https://github.com/matrix-org/matrix-spec-proposals/pull/3911), 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