ietf-wg-mimi / mimi-arch

An architecture for More Instant Messaging Interoperability
Other
4 stars 5 forks source link

Is membership clients or users? Pick one #1

Closed rohan-wire closed 1 year ago

rohan-wire commented 1 year ago

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.

rohan-wire commented 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."

rohan-wire commented 1 year ago

"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."

bifurcation commented 1 year ago

/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.

rohan-wire commented 1 year ago

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.

turt2live commented 1 year ago

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.

rohan-wire commented 1 year ago

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.

bifurcation commented 1 year ago

MLS's member is explicitly about clients. MLS doesn't know about users.

rohan-wire commented 1 year ago

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"