MSC4256: RFC 9420 MLS mode Matrix #4256
Conversation
ara4n
changed the title
tulir
added
e2e
client-server
turt2live
added
the
implementation-needs-checking
|
|
||
| ![Invite flow][invite-flow] | ||
|
|
||
| ## Potential issues |
There was a problem hiding this comment.
What about display name and avatar url of members? Are they stored in the MLS group context too? And if so, how to prevent malicious users from changing them.
| less strict validation, those rules tend to favour stricter validation. Some of those rules could be | ||
| made more lenient to allow more extensibility if such a need is expected. | ||
|
|
||
| 1. if state_key is not empty, reject |
There was a problem hiding this comment.
Maybe splitting hairs but empty and missing are considered equivalent here, right?
| 9. If the `can_propose` has entries not in `servers`, reject | ||
| 10. Otherwise, allow | ||
| 10. If the event type is `m.mls.pending_commit`: | ||
| 1. If the epoch of this event is not exactly the epoch of the previous `m.mls.commit` event + 1, reject |
There was a problem hiding this comment.
"the current m.mls.commit event" might be clearer here since m.mls.pending_commit doesn't directly replace that event. This could maybe also be applied to 9.2.
| 7. If the `powers` has entries not in `servers`, reject | ||
| 8. If the `powers` start not with exactly the same entries in the same order as the subset of | ||
| entries in the previous `powers` above the `origin` , reject | ||
| 9. If the `can_propose` has entries not in `servers`, reject |
There was a problem hiding this comment.
Would we need to enforce that entries from powers also appear in can_propose to enable the process described in "Commit handling with multiple servers" below?
| { | ||
| "type": "m.room.encrypted", | ||
| "content": { | ||
| "algorithm": "m.megolm.v1.aes-sha2", |
There was a problem hiding this comment.
Should this not be something starting with m.mls.v1?
| Currently redactions are not supported in the outer protocol layer. This has the benefit of making | ||
| redactions invisible to the server, but also prevents any server side aggregation. This also means | ||
| content can’t be deleted. As we require all events to be encrypted, this might not be a major | ||
| problem, but policy makers might disagree. Redactions could be supported in various ways and we |
There was a problem hiding this comment.
Redactions are not only relevant in the context of data privacy but also for moderation. Not being able to delete malicious or illegal content seems like a significant problem. 😕
Rendered
Server/Synapse implementation:
Client implementation:
Related to: