Remove major MLS/DS components; Update event approach #2
Conversation
This comment was marked as duplicate.
This comment was marked as duplicate.
| @@ -200,12 +217,18 @@ struct { | |||
| > **TODO**: Include fields for encryption information. Possibly ciphersuite and | |||
| > similar so a server can check to ensure it supports the MLS dialect? | |||
|
|
|||
| **Fanout considerations**: | |||
|
|
|||
| `CreateEvent` is *unsigned* in all cases it is used. The create event is used | |||
There was a problem hiding this comment.
We don't require other providers to be notified when a new room is created. I don't see why we have a create event.
There was a problem hiding this comment.
This is not being used as an advertisement to other providers. It's used to carry information over the API because the framing is an Event. See "check invite" API.
There was a problem hiding this comment.
(looks like replying via email doesn't work with threads)
@rohan-wire says:
Why do other mimi providers need to be notified about a created room? It doesn't seem actionable by a remote provider. Can't they just become aware of a room the first time one of their users is added to it?
There was a problem hiding this comment.
Other providers are not notified. This is how they become aware of the room - there's still more work to be done on the create event contents before this is ready for review.
There was a problem hiding this comment.
I think the name is a bit misleading at this point, as it's a bit of a vestige from when room state was event based. Now, the "CreateEvent" contains the static information of the room required for a new provider/user to join the room. Since the provider also needs the GroupInfo and the participant list, I think we'll condense this down to one or maybe two events.
|
|
||
| 1. Using an external commit to Add themselves to the MLS group. | ||
| 2. Receiving a Welcome message from a joined member of the MLS group. | ||
|
|
There was a problem hiding this comment.
- Create a group and add others to it.
There was a problem hiding this comment.
MIMI requires signaling, which does not permit the creation of an MLS group outside of a room.
There was a problem hiding this comment.
@rohan-wire says:
Your statement is about users. Users of a MIMI-capable provider can certainly create rooms and MLS groups as they like. Why is this controversial? By the time users on foreign providers start to get involved there will be a room and a group, but we need to ne clear about how users end up in groups because the other users need to authorize them. -r
There was a problem hiding this comment.
I wouldn't say it's controversial yet, but I'm having trouble understanding the motivation for the initial comment. It's on a deleted line, and doesn't include much detail.
MLS groups can of course be created, but joins (where this comment is placed) happen within signaling. There's already text to permit/allow the addition of clients without user signaling messages.
There was a problem hiding this comment.
(moving to a thread for replies)
@rohan-wire says:
Hi Travis,
I don't think this particular list of events is helping us move forward.
The m.room.create event is out of scope of MIMI.
In the MLS case, I think we had strong consensus to use an MLS Proposal to update the participant list. So, we don't need the m.room.user event.
Sending an application message does not require a signature, and sending an MLS handshake (and therefore participant list modification) in MLS does not require a signature. Therefore, we should remove them from every event. We can add a signature to the specific events that need them (ex: consent).
There was a problem hiding this comment.
The m.room.create event is out of scope of MIMI.
See https://github.com/bifurcation/ietf-mimi-protocol/pull/2/files#r1375474716
In the MLS case, I think we had strong consensus to use an MLS Proposal to update the participant list. So, we don't need the m.room.user event.
I don't agree that we had consensus on using MLS Proposals for participant list changes. This document is shaped independently of MLS though, so events could run over MLS Proposals in a different document if desired. We should discuss this as a Design Team.
Sending an application message does not require a signature, and sending an MLS handshake (and therefore participant list modification) in MLS does not require a signature. Therefore, we should remove them from every event. We can add a signature to the specific events that need them (ex: consent).
The application message is not signed by the protocol document (in fact, it's been removed in this PR). Participant list events are required to be signed because they transit multiple hops, however redactions and hash chaining were removed in an earlier PR already.
There was a problem hiding this comment.
@rohan-wire says:
Regardless what protocol you use, you will need some binding between participant list changes and the e2e encryption protocol. For MLS, Konrad and Raphael suggested [using an MLS
Proposal], Tom chimed in that they do that too, and Richard and I both responded favorably. Nobody raised any objection or gave a reason why we would should not. Thanks, -rohan
There was a problem hiding this comment.
There is still a binding between participant list and MLS group, though not in this document specifically. We've talked several times as a design team about how this could be done, and Konrad and I are working on formalizing that in the DS and protocol documents. We should have something up for review on Tuesday by the design team.
What specific proposal are you speaking to? Thursday's design meeting is the state of decisions this PR is based upon (pending a re-review on Tuesday with the whole design team).
There was a problem hiding this comment.
I'm working on the next set of changes that will ensure the participant list is anchored in the room's underlying MLS group state.
This comment was marked as duplicate.
This comment was marked as duplicate.
This comment was marked as duplicate.
This comment was marked as duplicate.
This comment was marked as duplicate.
This comment was marked as duplicate.
| @@ -200,12 +217,18 @@ struct { | |||
| > **TODO**: Include fields for encryption information. Possibly ciphersuite and | |||
| > similar so a server can check to ensure it supports the MLS dialect? | |||
|
|
|||
| **Fanout considerations**: | |||
|
|
|||
| `CreateEvent` is *unsigned* in all cases it is used. The create event is used | |||
There was a problem hiding this comment.
I think the name is a bit misleading at this point, as it's a bit of a vestige from when room state was event based. Now, the "CreateEvent" contains the static information of the room required for a new provider/user to join the room. Since the provider also needs the GroupInfo and the participant list, I think we'll condense this down to one or maybe two events.
| The user's clients are then able to use external commits to join the MLS group. | ||
| This is accomplished using {{op-external-join}}. | ||
| A user already in the join participation state MAY add and remove their own | ||
| clients from the cryptographic state at will. For MLS specifically, clients |
There was a problem hiding this comment.
While it's fine to link limitations to MLS, we should probably not allude to non-MLS versions in this doc.
There was a problem hiding this comment.
I'm working on the next set of changes that will ensure the participant list is anchored in the room's underlying MLS group state.
No description provided.