Closed rohan-wire closed 1 year ago
The following statement is impossible:
"As discussed above, user-level and client-level membership must be kept in sync. When a user is added, some set of their clients should be added as well; when a user leaves or is evicted, any clients joined to the room should be removed. The cryptographic constraints of end-to-end security protocols mean that servers cannot perform this synchronization; it is up to clients to keep these two types of state in sync."
"Membership I do not think we will be able to have sane discussions if membership means:
I have now had literally thousands of confusing conversations conflating different meanings of member. I have felt the pain firsthand. I do not wish that on the MIMI WG. I propose that member should mean membership in an MLS group only, and that we use another term (for example participant) to refer to a user."
/me looks for the "bikeshed" tag :)
Personally, I think we can have sane discussions if we're clear that user and client memberships are distinct notions. I think it will usually be clear from context which is meant. But if you want to propose some different terminology, I'm open to it.
But if you want to propose some different terminology, I'm open to it.
I propose that member should mean membership in an MLS group only, and that we use another term (for example participant) to refer to a user.
But if you want to propose some different terminology, I'm open to it.
I propose that member should mean membership in an MLS group only, and that we use another term (for example participant) to refer to a user.
I'd flip this the other way. Users are members of a room, but participating in the MLS group. They aren't participating in the room in most cases, if we split signaling how Matthew & I are proposing.
But if you want to propose some different terminology, I'm open to it.
I propose that member should mean membership in an MLS group only, and that we use another term (for example participant) to refer to a user.
I'd flip this the other way. Users are members of a room, but participating in the MLS group. They aren't participating in the room in most cases, if we split signaling how Matthew & I are proposing.
MLS is already an RFC and already defines member
as a client having the keys of an MLS group. Since we are following, I'd prefer we minimize overloading.
MLS's member
is explicitly about clients. MLS doesn't know about users.
MLS's
member
is explicitly about clients. MLS doesn't know about users.
Yes, but having a member of MLS group and member of a room that uses an MLS group meaning two very different things is still very confusing and should be avoided. I have had plenty of these discussions and they were painful.
For example: "A user which is no longer a member of the room but which briefly has clients which are still members of the corresponding MLS group should be able to receive handshake message, but might not receive application messages. The (MLS) member should still be able to send Proposals but not application messages or Commits. The roster might still distinctively render the non-room member (for example grayed out) in the roster as long as that former member has clients which are still members of the corresponding MLS group"
We will tie ourselves in knots if we use the word member and membership to mean both the clients and the users who interact with a room.
I propose we reserve the term
member
to be for clients. For users, I propose either "a user in the room", or a "participant" in the room.