MSC4144: Per-message profiles #4144
Conversation
Signed-off-by: Tulir Asokan <[email protected]>
tulir
added
proposal
This comment was marked as resolved.
This comment was marked as resolved.
| 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. |
There was a problem hiding this comment.
What's the upside of doing it this way? Not needing admin access on the server?
There was a problem hiding this comment.
I think this is basically the same question as your first comment. The assumptions in both are correct: per-message profiles would allow bridging without admin access and with more encryption.
Beeper is going to switch to local bridges with an encrypted cloud "backup". The backup isn't allowed to leak any metadata, which means the remote user profile info must be encrypted and even user IDs can't be in plaintext. I want to try to keep the room data as Matrix-compatible as possible, hence this MSC.
There are rooms that use extremely ugly relaybot bridges even now (matterbridge), so there's clearly some demand for bridging without requiring admin access. This MSC would make those bridges look much nicer.
There was a problem hiding this comment.
Thanks for explaining! Does this mean that encrypted state (MSC3414?) is another alternative?
There was a problem hiding this comment.
To some extent yes, although that'd still leak some kinds of user IDs: even if the state keys were hashes or something, it'd still leak that a different user sent a message, which is more metadata than encrypted per-message profiles. It also wouldn't help with the non-admin-bridges
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 `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. |
There was a problem hiding this comment.
What is the scope of this id? I assume it needs to be scoped at least to the sender to avoid spoofing. But is it also scoped to the room, or are messages from the same sender in different rooms assumed to be the same?
There was a problem hiding this comment.
Probably makes sense to be user-specific (different sender mxid = different per-message profiles) but otherwise global (not room-specific)
There was a problem hiding this comment.
Scope has been defined to be only user-specific now
| 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
| 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
|
|
||
| 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. |
There was a problem hiding this comment.
It can happen that multiple platforms are relayed to the same Matrix room and clashes in names may happen. We should either mention that this id should contain a sufficient discriminant along with the remote user ID (e.g., prefixing it with the protocol or bridge gateway ID and a delimiter) or that we could introduce another field for this.
This is also important if we want to enable clients and bots to transparently ignore or ban relayed remote users by such a GUID.
There was a problem hiding this comment.
This sounds like the same question as #4144 (comment)
Rendered
Signed-off-by: Tulir Asokan [email protected]