From f261e900fe07ebc2ff5ffdd4ec02ed4d0e6d2a56 Mon Sep 17 00:00:00 2001 From: Tulir Asokan Date: Fri, 10 May 2024 19:03:58 +0300 Subject: [PATCH 01/17] Proposal for per-message profiles Signed-off-by: Tulir Asokan --- proposals/4144-per-message-profile.md | 123 ++++++++++++++++++++++++++ 1 file changed, 123 insertions(+) create mode 100644 proposals/4144-per-message-profile.md diff --git a/proposals/4144-per-message-profile.md b/proposals/4144-per-message-profile.md new file mode 100644 index 00000000000..3923027a6c0 --- /dev/null +++ b/proposals/4144-per-message-profile.md @@ -0,0 +1,123 @@ +# MSC4144: Per-message profiles +Currently profiles in Matrix are defined by `m.room.member` state events, and +there is no easy way to have different profiles per message. + +## Proposal +The proposed solution is a new field called `m.per_message_profile`, which +contains a displayname and/or avatar URL to override the default profile, +plus an ID to identify different profiles within the same Matrix user. + +```json +{ + "msgtype": "m.text", + "body": "Hello, World!", + "m.per_message_profile": { + "id": "meow", + "displayname": "cat", + "avatar_url": "mxc://maunium.net/hgXsKqlmRfpKvCZdUoWDkFQo" + } +} +``` + +The `id` field is required and is an opaque string. Clients may use it to group +messages with the same ID like they would group messages from the same sender. +For example, bridges would likely set it to the immutable remote user ID. + +### Encrypted avatars +Because the profile is inside the ciphertext in encrypted events, the entire +profile can be hidden the server, as long as the avatar is also encrypted. +Encrypted avatars are placed under `avatar_file` instead of `avatar_url`. +The `avatar_file` field has the same schema as the `file` field in +`m.room.message` events. + +
+Encrypted avatar example + +```json +{ + "msgtype": "m.text", + "body": "Hello, World!", + "m.per_message_profile": { + "id": "meow", + "displayname": "cat", + "avatar_file": { + "v": "v2", + "key": { + "alg": "A256CTR", + "ext": true, + "k": "8dXeBMBMthuXGY5zmUh9Mi0aqC1kndMZ4NCa-0RhELc", + "key_ops": [ + "encrypt", + "decrypt" + ], + "kty": "oct" + }, + "iv": "L6zup2cR570AAAAAAAAAAA", + "hashes": { + "sha256": "/cTs+PajUcznbV3h1w5gh1AHnLjrKQVl2jU3xLCqoBI" + }, + "url": "mxc://maunium.net/eKLhozQduElYSgBkWjtwSXoi" + } + } +} +``` + +
+ +### Behavior of omitted and empty fields +If the `displayname` field is omitted, null, or an empty string, the +displayname from the member event should be used instead. Setting an empty +displayname using a per-message profile is not supported, as there aren't any +clear use cases for it. + +However, there are use cases for setting an empty avatar, so `avatar_url` being +an empty string should be treated as clearing the avatar and falling back to +the client's default blank avatar behavior (e.g. generating one based on the +displayname). If both `avatar_url` and `avatar_file` are omitted or null, the +avatar from the member event should be used instead. + +### Extensible profiles +This MSC is not related to extensible profiles and does not attempt to +implement them. However, in case extensible profiles are implemented as +something that can be referenced (e.g. room IDs), the MSC adding them could +allow per-message profiles to specify which extensible profile is used. + +## Use cases + +### Bridging +Per-message profiles will allow making "lighter-weight" bridges that don't need +appservice access. Currently the only option for such bridges is to prepend the +displayname to the message, which is extremely ugly. + +Such bridges would obviously have downsides, like not being able to start chats +via standard mechanisms, and not being able to see the member list on Matrix. +However, those may be acceptable compromises for non-puppeting bridges that +only operate in specific predetermined rooms. + +### Feature-parity with other platforms +Other chat applications such as Slack and Discord have "webhooks" which allow +per-message profile overrides. This MSC effectively enables the same on Matrix. + +### Roleplaying, plural users, etc +Some users want to be able to switch between profiles quickly, which would be +much easier using this MSC. Currently easiest way is to have multiple accounts, +which has other benefits, but is much more cumbersome to manage. + +## Potential issues +Implementing encrypted avatars could cause difficulty for clients that assume +that avatars are always unencrypted mxc URIs. + +## Alternatives +None. + +## Security considerations + +### Preventing impersonation +To prevent impersonation using per-message profiles, clients should somehow +indicate to the user that the message has a per-message profile with an easy +way to see the user's MXID or default profile. For example, a client could have +a small `via @user:example.com` text next to the per-message displayname. + +## Unstable prefix +`com.beeper.per_message_profile` should be used instead of `m.per_message_profile` +until this MSC is accepted. From 9758def1a970b4cfd7acd3d5de35195963a67f6f Mon Sep 17 00:00:00 2001 From: Tulir Asokan Date: Fri, 10 May 2024 20:17:44 +0300 Subject: [PATCH 02/17] Add new state event as an alternative --- proposals/4144-per-message-profile.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/proposals/4144-per-message-profile.md b/proposals/4144-per-message-profile.md index 3923027a6c0..d232ab455ea 100644 --- a/proposals/4144-per-message-profile.md +++ b/proposals/4144-per-message-profile.md @@ -108,7 +108,9 @@ Implementing encrypted avatars could cause difficulty for clients that assume that avatars are always unencrypted mxc URIs. ## Alternatives -None. +Per-message profiles could be transmitted more compactly by defining the profile +in a new state event and only referencing the state key in the message event. +However, that approach wouldn't enable encrypting per-message profiles. ## Security considerations From 1c0f03ef638ab9cb46b443e6dff7b89eff8c7e77 Mon Sep 17 00:00:00 2001 From: Tulir Asokan Date: Fri, 10 May 2024 22:19:54 +0300 Subject: [PATCH 03/17] Add more details on use cases --- proposals/4144-per-message-profile.md | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/proposals/4144-per-message-profile.md b/proposals/4144-per-message-profile.md index d232ab455ea..48e0f7d3dff 100644 --- a/proposals/4144-per-message-profile.md +++ b/proposals/4144-per-message-profile.md @@ -87,17 +87,25 @@ allow per-message profiles to specify which extensible profile is used. ### Bridging Per-message profiles will allow making "lighter-weight" bridges that don't need appservice access. Currently the only option for such bridges is to prepend the -displayname to the message, which is extremely ugly. +displayname to the message, which is extremely ugly. Even though they're ugly, +there are still rooms that use bot-based bridges like matterbridge, which shows +there's demand for bridging without requiring server admin access. Such bridges would obviously have downsides, like not being able to start chats via standard mechanisms, and not being able to see the member list on Matrix. However, those may be acceptable compromises for non-puppeting bridges that only operate in specific predetermined rooms. +This method also allows encrypting profile info, which reduces metadata leaked +by bridging. + ### Feature-parity with other platforms Other chat applications such as Slack and Discord have "webhooks" which allow per-message profile overrides. This MSC effectively enables the same on Matrix. +For example, Discord's [execute webhook](https://discord.com/developers/docs/resources/webhook#execute-webhook) +API takes `username` and `avatar_url` as optional parameters. + ### Roleplaying, plural users, etc Some users want to be able to switch between profiles quickly, which would be much easier using this MSC. Currently easiest way is to have multiple accounts, From 9b7d7be82701c51d4a71ea442f27bc6cff37abe9 Mon Sep 17 00:00:00 2001 From: Tulir Asokan Date: Sat, 11 May 2024 12:06:35 +0300 Subject: [PATCH 04/17] Write more words in alternatives section --- proposals/4144-per-message-profile.md | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/proposals/4144-per-message-profile.md b/proposals/4144-per-message-profile.md index 48e0f7d3dff..aa646d13874 100644 --- a/proposals/4144-per-message-profile.md +++ b/proposals/4144-per-message-profile.md @@ -116,9 +116,21 @@ Implementing encrypted avatars could cause difficulty for clients that assume that avatars are always unencrypted mxc URIs. ## Alternatives +### New state events Per-message profiles could be transmitted more compactly by defining the profile in a new state event and only referencing the state key in the message event. -However, that approach wouldn't enable encrypting per-message profiles. +However, that approach wouldn't enable encrypting per-message profiles without +inventing encrypted state events. Additionally, even with encrypted state +events, some kind of sender identifiers would be leaked via state keys. + +### Appservices +Appservices work perfectly fine for bridging already now, but they require +admin access to a server, which is not available for everyone. Additionally, +they have similar metadata issues as the "New state events" alternative above. + +For use cases involving a single human user, having multiple mxids (regardless +of whether they're registered manually or via an appservice) complicates things +unnecessarily. ## Security considerations From 99e6bea40bfa5e0d50da172abfd6f2d17cdbb420 Mon Sep 17 00:00:00 2001 From: Tulir Asokan Date: Sun, 24 Nov 2024 22:46:48 +0200 Subject: [PATCH 05/17] Specify behavior when no avatar is defined anywhere --- proposals/4144-per-message-profile.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/proposals/4144-per-message-profile.md b/proposals/4144-per-message-profile.md index aa646d13874..912fa8b5e50 100644 --- a/proposals/4144-per-message-profile.md +++ b/proposals/4144-per-message-profile.md @@ -74,7 +74,10 @@ However, there are use cases for setting an empty avatar, so `avatar_url` being an empty string should be treated as clearing the avatar and falling back to the client's default blank avatar behavior (e.g. generating one based on the displayname). If both `avatar_url` and `avatar_file` are omitted or null, the -avatar from the member event should be used instead. +avatar from the member event should be used instead. If the member event does +not have an avatar defined either, and the client uses the displayname to +generate fallback avatars, it should use the per-message displayname for the +fallback avatar rather than the global one. ### Extensible profiles This MSC is not related to extensible profiles and does not attempt to From 8b6b12a833ba36bc9ef165dcce202de3162725cd Mon Sep 17 00:00:00 2001 From: Tulir Asokan Date: Sun, 24 Nov 2024 22:49:31 +0200 Subject: [PATCH 06/17] Add missing word --- proposals/4144-per-message-profile.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/4144-per-message-profile.md b/proposals/4144-per-message-profile.md index 912fa8b5e50..e5b875f4cd6 100644 --- a/proposals/4144-per-message-profile.md +++ b/proposals/4144-per-message-profile.md @@ -25,7 +25,7 @@ For example, bridges would likely set it to the immutable remote user ID. ### Encrypted avatars Because the profile is inside the ciphertext in encrypted events, the entire -profile can be hidden the server, as long as the avatar is also encrypted. +profile can be hidden from the server, as long as the avatar is also encrypted. Encrypted avatars are placed under `avatar_file` instead of `avatar_url`. The `avatar_file` field has the same schema as the `file` field in `m.room.message` events. From c6abf19131cd67673653391c5ba4e9a1be9ff198 Mon Sep 17 00:00:00 2001 From: Tulir Asokan Date: Sun, 24 Nov 2024 22:58:45 +0200 Subject: [PATCH 07/17] Allow omitting via user indicator --- proposals/4144-per-message-profile.md | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/proposals/4144-per-message-profile.md b/proposals/4144-per-message-profile.md index e5b875f4cd6..f53bb3f2ebf 100644 --- a/proposals/4144-per-message-profile.md +++ b/proposals/4144-per-message-profile.md @@ -138,11 +138,18 @@ unnecessarily. ## Security considerations ### Preventing impersonation -To prevent impersonation using per-message profiles, clients should somehow +To prevent impersonation using per-message profiles, clients MUST somehow indicate to the user that the message has a per-message profile with an easy way to see the user's MXID or default profile. For example, a client could have a small `via @user:example.com` text next to the per-message displayname. +To improve user experience, clients MAY omit the indicator when the sender +account has sufficiently high power level, and the displayname is unique among +members of the room (i.e. it does not require disambiguation in the +["Calculating the display name for a user" spec](https://spec.matrix.org/v1.12/client-server-api/#calculating-the-display-name-for-a-user)). + +TODO: define the power level + ## Unstable prefix `com.beeper.per_message_profile` should be used instead of `m.per_message_profile` until this MSC is accepted. From c00010da6628aa6ce8cce56cd7f199a2f3351ac6 Mon Sep 17 00:00:00 2001 From: Tulir Asokan Date: Sun, 24 Nov 2024 23:20:40 +0200 Subject: [PATCH 08/17] Clarify scope of per-message profile ID --- proposals/4144-per-message-profile.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/proposals/4144-per-message-profile.md b/proposals/4144-per-message-profile.md index f53bb3f2ebf..e8e9de3f622 100644 --- a/proposals/4144-per-message-profile.md +++ b/proposals/4144-per-message-profile.md @@ -23,6 +23,11 @@ The `id` field is required and is an opaque string. Clients may use it to group messages with the same ID like they would group messages from the same sender. For example, bridges would likely set it to the immutable remote user ID. +This ID is scoped to the real MXID used to send the event, but is otherwise +global. In other words, the same ID in different rooms from the same account +can be considered to be the same user, but the same ID in the same room from +different accounts are considered to be different users. + ### Encrypted avatars Because the profile is inside the ciphertext in encrypted events, the entire profile can be hidden from the server, as long as the avatar is also encrypted. From b0838432203c00577c7f69a0181b04ba457e0a7e Mon Sep 17 00:00:00 2001 From: Tulir Asokan Date: Sun, 24 Nov 2024 23:25:25 +0200 Subject: [PATCH 09/17] Specify which event types the field is allowed on --- proposals/4144-per-message-profile.md | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/proposals/4144-per-message-profile.md b/proposals/4144-per-message-profile.md index e8e9de3f622..0cffc3ac166 100644 --- a/proposals/4144-per-message-profile.md +++ b/proposals/4144-per-message-profile.md @@ -28,6 +28,10 @@ global. In other words, the same ID in different rooms from the same account can be considered to be the same user, but the same ID in the same room from different accounts are considered to be different users. +The field is allowed for all message events, which currently means +`m.room.message` and `m.sticker`. A future MSC may expand the field to other +events, such as reactions. + ### Encrypted avatars Because the profile is inside the ciphertext in encrypted events, the entire profile can be hidden from the server, as long as the avatar is also encrypted. @@ -102,7 +106,8 @@ there's demand for bridging without requiring server admin access. Such bridges would obviously have downsides, like not being able to start chats via standard mechanisms, and not being able to see the member list on Matrix. However, those may be acceptable compromises for non-puppeting bridges that -only operate in specific predetermined rooms. +only operate in specific predetermined rooms. Non-message events like reactions +are also not supported by this MSC, but they could be allowed in the future. This method also allows encrypting profile info, which reduces metadata leaked by bridging. From 26846d21453a5f79a7e4e68690c7eee765da601d Mon Sep 17 00:00:00 2001 From: Tulir Asokan Date: Sun, 24 Nov 2024 23:29:31 +0200 Subject: [PATCH 10/17] Add todo about disambiguation with multiple bridges --- proposals/4144-per-message-profile.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/proposals/4144-per-message-profile.md b/proposals/4144-per-message-profile.md index 0cffc3ac166..14129302a09 100644 --- a/proposals/4144-per-message-profile.md +++ b/proposals/4144-per-message-profile.md @@ -158,7 +158,10 @@ account has sufficiently high power level, and the displayname is unique among members of the room (i.e. it does not require disambiguation in the ["Calculating the display name for a user" spec](https://spec.matrix.org/v1.12/client-server-api/#calculating-the-display-name-for-a-user)). -TODO: define the power level +TODO: define the power level +TODO2: what if the same name is used by multiple different bridges using +per-message profiles? Maybe it's enough to recommend configuring bridges to +append a network identifier to names? ## Unstable prefix `com.beeper.per_message_profile` should be used instead of `m.per_message_profile` From 2361a1ceed23fbb6fbcd3b5faade2627ae80e30b Mon Sep 17 00:00:00 2001 From: Tulir Asokan Date: Sat, 14 Jun 2025 18:08:04 +0300 Subject: [PATCH 11/17] Define power level to check --- proposals/4144-per-message-profile.md | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/proposals/4144-per-message-profile.md b/proposals/4144-per-message-profile.md index 14129302a09..18422b72b1d 100644 --- a/proposals/4144-per-message-profile.md +++ b/proposals/4144-per-message-profile.md @@ -158,10 +158,9 @@ account has sufficiently high power level, and the displayname is unique among members of the room (i.e. it does not require disambiguation in the ["Calculating the display name for a user" spec](https://spec.matrix.org/v1.12/client-server-api/#calculating-the-display-name-for-a-user)). -TODO: define the power level -TODO2: what if the same name is used by multiple different bridges using -per-message profiles? Maybe it's enough to recommend configuring bridges to -append a network identifier to names? +The recommended power level to check is the level for a `m.per_message_profile` +state event (i.e. check `events` -> `m.per_message_profile` and fall back to +`state_default` if not set). ## Unstable prefix `com.beeper.per_message_profile` should be used instead of `m.per_message_profile` From 734225a184bd6fbdde8330ed938658cb54d30297 Mon Sep 17 00:00:00 2001 From: Tulir Asokan Date: Sat, 14 Jun 2025 18:16:41 +0300 Subject: [PATCH 12/17] Define fallback for old clients --- proposals/4144-per-message-profile.md | 52 +++++++++++++++++++++++++++ 1 file changed, 52 insertions(+) diff --git a/proposals/4144-per-message-profile.md b/proposals/4144-per-message-profile.md index 18422b72b1d..1c04fb50520 100644 --- a/proposals/4144-per-message-profile.md +++ b/proposals/4144-per-message-profile.md @@ -94,6 +94,58 @@ implement them. However, in case extensible profiles are implemented as something that can be referenced (e.g. room IDs), the MSC adding them could allow per-message profiles to specify which extensible profile is used. +### Fallbacks for old clients +In order for users on old clients to see the per-message profile data, sending +clients SHOULD include a fallback containing the per-message displayname. +When a fallback is used, the per-message profile object MUST include +`"has_fallback": true`. + +#### Plaintext fallback +The fallback MUST be at the beginning of the plaintext `body` and consist of +the exact value of the `displayname` property, followed by a colon (`:`) and +a space (`\x20`), e.g. `cat: original message`. + +To remove the plaintext fallback, trim the prefix `{displayname}: ` from the body. + +#### HTML fallback +If a `formatted_body` of type `org.matrix.custom.html` is present, it SHOULD +include the same fallback text inside a `strong` tag with the `data-mx-profile-fallback` +attribute, e.g. `cat: original message`. + +The displayname MUST be HTML-escaped and there MUST NOT be any HTML tags inside +the fallback. The tag MUST NOT have any other attributes. The attribute MAY +have an empty string as its value (`=""`) for compatibility with all HTML +generators, but MUST NOT have any other value. The HTML fallback is not mandated +to be at the beginning of the string, as there may be valid reasons to put it +inside another tag, such as a `

` tag. + +To remove the HTML fallback, either use a HTML parser to drop the entire `strong` +tag with a `data-mx-profile-fallback` attribute, or replace matches of the +following regex with an empty string: `([^<]+): ` + +#### Other details +If a fallback is used in a media message, the `filename` property MUST be set +to ensure the `body` is treated as a caption rather than a file name. + +Fallbacks MUST only be used when the `displayname` property is a non-empty +string, i.e. they are not used when falling back to the member event name. + +#### Example with fallback +```json +{ + "msgtype": "m.text", + "body": "cat: Hello, World!", + "format": "org.matrix.custom.html", + "formatted_body": "

cat: Hello, World!

", + "m.per_message_profile": { + "id": "meow", + "displayname": "cat", + "avatar_url": "mxc://maunium.net/hgXsKqlmRfpKvCZdUoWDkFQo", + "has_fallback": true + } +} +``` + ## Use cases ### Bridging From 9ca421e6c99bc9025edeb79daedf4c48caf4603c Mon Sep 17 00:00:00 2001 From: Tulir Asokan Date: Sat, 14 Jun 2025 18:16:47 +0300 Subject: [PATCH 13/17] Define field limits --- proposals/4144-per-message-profile.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/proposals/4144-per-message-profile.md b/proposals/4144-per-message-profile.md index 1c04fb50520..fabbcdac2b5 100644 --- a/proposals/4144-per-message-profile.md +++ b/proposals/4144-per-message-profile.md @@ -32,6 +32,14 @@ The field is allowed for all message events, which currently means `m.room.message` and `m.sticker`. A future MSC may expand the field to other events, such as reactions. +### Field limits +After JSON decoding, `id` and `displayname` MUST be at most 255 bytes of UTF-8 +and every code point MUST be a Unicode scalar. Null bytes (`\u0000`) are not +allowed. + +Like with other images and avatars, clients should ignore any avatar URL that +is not a `mxc://` URI. + ### Encrypted avatars Because the profile is inside the ciphertext in encrypted events, the entire profile can be hidden from the server, as long as the avatar is also encrypted. From cff64fbe3a8c7791abc0bf6c3ffeeb3e5f665059 Mon Sep 17 00:00:00 2001 From: Tulir Asokan Date: Sun, 15 Jun 2025 01:15:20 +0300 Subject: [PATCH 14/17] Add note about mentioning profiles --- proposals/4144-per-message-profile.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/proposals/4144-per-message-profile.md b/proposals/4144-per-message-profile.md index fabbcdac2b5..0c657994712 100644 --- a/proposals/4144-per-message-profile.md +++ b/proposals/4144-per-message-profile.md @@ -188,6 +188,10 @@ which has other benefits, but is much more cumbersome to manage. Implementing encrypted avatars could cause difficulty for clients that assume that avatars are always unencrypted mxc URIs. +When per-message profiles are used for bridging, there's no way to mention +specific users, as mentions will just target the single bridge bot. A future +MSC could define a way to specify which profile to mention. + ## Alternatives ### New state events Per-message profiles could be transmitted more compactly by defining the profile From b24060e2a66dc3e9b459f634ba91d3a34d702efa Mon Sep 17 00:00:00 2001 From: Tulir Asokan Date: Sun, 8 Mar 2026 20:20:57 +0200 Subject: [PATCH 15/17] Explicitly specify that fallbacks are optional --- proposals/4144-per-message-profile.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/proposals/4144-per-message-profile.md b/proposals/4144-per-message-profile.md index 0c657994712..905ceac8e8f 100644 --- a/proposals/4144-per-message-profile.md +++ b/proposals/4144-per-message-profile.md @@ -108,6 +108,9 @@ clients SHOULD include a fallback containing the per-message displayname. When a fallback is used, the per-message profile object MUST include `"has_fallback": true`. +Fallbacks are intentionally optional. Clients MUST NOT assume the message has +a fallback unless `has_fallback` is set to `true`, + #### Plaintext fallback The fallback MUST be at the beginning of the plaintext `body` and consist of the exact value of the `displayname` property, followed by a colon (`:`) and From a399fdac76b0aa9f1afc9691267f474168e4948b Mon Sep 17 00:00:00 2001 From: Tulir Asokan Date: Fri, 20 Mar 2026 13:29:16 +0200 Subject: [PATCH 16/17] Allow editing per-message profiles --- proposals/4144-per-message-profile.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/proposals/4144-per-message-profile.md b/proposals/4144-per-message-profile.md index 905ceac8e8f..30183cc1318 100644 --- a/proposals/4144-per-message-profile.md +++ b/proposals/4144-per-message-profile.md @@ -32,6 +32,12 @@ The field is allowed for all message events, which currently means `m.room.message` and `m.sticker`. A future MSC may expand the field to other events, such as reactions. +Modifying per-message profiles using edits is allowed, i.e. clients SHOULD +include the per-message profile object in `m.new_content` when sending edits +and read it when receiving edits. Including the per-message profile object in +the edit fallback at the top level is not necessary, as all clients that support +per-message profiles can be assumed to support edits. + ### Field limits After JSON decoding, `id` and `displayname` MUST be at most 255 bytes of UTF-8 and every code point MUST be a Unicode scalar. Null bytes (`\u0000`) are not From d4161fd4cfa25becbad356e48a62305635b4061c Mon Sep 17 00:00:00 2001 From: Tulir Asokan Date: Fri, 20 Mar 2026 13:30:45 +0200 Subject: [PATCH 17/17] Expand on new state event alternative --- proposals/4144-per-message-profile.md | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/proposals/4144-per-message-profile.md b/proposals/4144-per-message-profile.md index 30183cc1318..886a94216f1 100644 --- a/proposals/4144-per-message-profile.md +++ b/proposals/4144-per-message-profile.md @@ -209,6 +209,15 @@ However, that approach wouldn't enable encrypting per-message profiles without inventing encrypted state events. Additionally, even with encrypted state events, some kind of sender identifiers would be leaked via state keys. +State events also have the downside that they have to be sent into the room +separately, which means extra work for everyone. They would also pollute the +room state if a profile is only used once or a few times. + +The main benefit of state events is that it makes it easy to retroactively +modify the per-message profile of already sent messages. This MSC considers +retroactive modifications to be sufficiently low-priority that state events +are not worth it considering the other downsides. + ### Appservices Appservices work perfectly fine for bridging already now, but they require admin access to a server, which is not available for everyone. Additionally,