MSC4144: Per-message profiles #4144
Conversation
Signed-off-by: Tulir Asokan <tulir@beeper.com>
tulir
added
proposal
This comment was marked as resolved.
This comment was marked as resolved.
There was a problem hiding this comment.
Implementation requirements:
- Client sending avatars
- Client using avatars
| Implementing encrypted avatars could cause difficulty for clients that assume | ||
| that avatars are always unencrypted mxc URIs. | ||
|
|
||
| ## Alternatives |
There was a problem hiding this comment.
Reminds me of MSC3464. This is more general than that MSC, though.
| 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. | ||
|
|
There was a problem hiding this comment.
I would like to propose a new field to forward the remote username or nickname in.
- The
idcan be either randomly generated or a decimal sequence number, but it is definitely not something that I would expect to be prominently displayed in a client. Incidentally, the mxid serves this purpose on Matrix internally. - The nickname is a short word that is quick to type in when we want to @-mention another member. Usually the localpart of the mxid acts as a poor substitute on matrix right now.
- Not all platforms support a display name, but where they do, it may contain the full, long personal name including spaces, pronouns, affiliations, position, emoji, etc. Many platforms also autocomplete for this when @-mentioning another user.
There was a problem hiding this comment.
There's currently no mention support here, but that might make sense if mention support is added. Not entirely sure if it should be in this MSC or a separate one (the feature can be neatly separated from the rest of the MSC and it requires modifying the matrix.to/matrix: URI spec)
There was a problem hiding this comment.
Leaning towards defining mentions to be out of scope here
There was a problem hiding this comment.
It can still be useful without support for mentions. For example, extant Matrix clients fall back to also showing the mxid (that can not clash) in case of a display name clash in a given room. Similarly they may want to fallback to the remote account name (remote nickname) when the remote display name clashes.
|
|
||
| ## 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, |
There was a problem hiding this comment.
We should provide guidance about the maximal length of each new field such as id and displayname.
There was a problem hiding this comment.
It would align with the present spec to state that
- the size of
idMUST NOT exceed 255 bytes - the size of
displaynameMUST NOT exceed 255 bytes
There was a problem hiding this comment.
Yeah for ids 255 bytes sounds right. Not entirely sure about the character set as user ids are quite messy currently (and it'd be nice to allow anything that can be in a matrix user id). Displaynames don't currently have any byte limits though
There was a problem hiding this comment.
Both of them could be any arbitrary UTF-8 string. Why would you want to restrict it if you already state that id is opaque? Clients are already expected to properly sanitize and wrap it for their own rendering.
Including a 64kB displayname in each reply sounds excessive. I'd rather we had a recommendation for how to shorten it (i.e., cut it properly on a UTF-8 boundary before reaching 256 bytes and ideally trimming whitespace at its edges).
There was a problem hiding this comment.
I would mention a suggestion that if the protocol and router discriminant, delimiter and the remote user ID together would exceed 255 bytes so it can't fit in the
id, hashing should be used (and the discriminant should be adjusted to specify this in this case). You can always find a protocol that allows just a little longer IDs than you have anticipated, or there's the simple case of cascading such relays by independent parties, increasing the length of each ID by just a little bit on every hop. 256 bits of entropy is usually considered good enough for a UUID and that fits within 43 characters of unpadded base64 or 64 characters of hex, so it should still leave plenty for further metadata. E.g.,
- For the user
@nick42:matrix.example, theidcould bemx1-mxid:@nick42:matrix.example - For a user with an excessive remote ID (
@too_long_name@matrix.example), this could bemx1-hash:04b9becd1c9306453d9aa80033a8a70fe9bd4c64989a06b470bc46ef6b8154c7
| 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. | ||
|
|
There was a problem hiding this comment.
User experience could be greatly improved in a room with mostly remote messages if this source disclaimer could be hidden (or only shown when clicking on the avatar) if all of the following conditions are met:
- The event sender is a moderator (e.g., has permission level for redaction or a new level)
- The impersonated user is not a member in the room
There was a problem hiding this comment.
I've added that now, but there's also 2 new todos to figure out the power level to use and whether anything needs to be done about multiple bridges where the remote users have conflicting displaynames
Rendered
Signed-off-by: Tulir Asokan tulir@beeper.com