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.
| 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?
Rendered
Signed-off-by: Tulir Asokan tulir@beeper.com