Is an additional primitive needed to add/remove a user added/removed using and MLS Commit?

[rohan-wire]

"Role of Signaling I see the signaling and the DS as peers. I see Signaling as policy (about and often by users), and the DS and clients as the enforcers and executors of this policy. The DS deals only with clients. I do not see MLS handshake messages as signaling. I see them as a third thing which is related to the e2ee protocol. A signaling message is not going to result in MLS application messages / content format, and there are many signaling actions that will result in no MLS messages at all. Likewise, adding or removing a client when that does not change the roster shouldn't result in a separate signaling event."

"If Alice is a participant in a room and adds two of Bob's clients (with his consent) to the corresponding MLS group, do I really need a separate signaling event (something other than an MLS Commit)? I don't think we do. I think we might need a signaling message to make Bob allowed to join a room, but there are several ways to do this that would result in a signaling event happening at a very different time. Example:

• Alice sends a signaling event requesting consent to add Bob to a room. This could include permission for Bob to join.
• Bob sends a signaling event consenting to be added to the room
• Alice adds Bob's clients via MLS, or one of Bob's clients joins via External Commit"

[bifurcation]

The text of your issue here doesn't seem to match the title. That is, in the title, you seem to think that some MLS actions should have signaling consequences, and in the body, you say they should be separate.

I think the crux here is the caveat "adding or removing a client when that does not change the roster". Why should we special-case certain MLS messages? Wouldn't it be cleaner to have more complete parallelism? Have a signaling event that says Bob is now a (user-level) member -- which implies his clients are allowed to join / be added -- followed by an E2EE event that actually joins the clients.

In other words, you seem to think that an MLS Commit adding clients for a new user should implicitly change the user-level roster. I think it would be cleaner to explicitly change the roster (and reject such a commit until then) and then add the clients.

(Obviously, in practice, these things can be bundled; Alice can send both actions at once.)

[rohan-wire]

The text of your issue here doesn't seem to match the title. That is, in the title, you seem to think that some MLS actions should have signaling consequences, and in the body, you say they should be separate.

The title comes from the second paragraph. I debated omitting the first paragraph.

Why should we special-case certain MLS messages? Wouldn't it be cleaner to have more complete parallelism? Have a signaling event that says Bob is now a (user-level) member -- which implies his clients are allowed to join / be added -- followed by an E2EE event that actually joins the clients.

to avoid pathological race conditions.

In other words, you seem to think that an MLS Commit adding clients for a new user should implicitly change the user-level roster. I think it would be cleaner to explicitly change the roster (and reject such a commit until then) and then add the clients.

yes

(Obviously, in practice, these things can be bundled; Alice can send both actions at once.)

They cannot, because the MLS messages are going to the clients and any other messages are only going to the provider.

[bifurcation]

This has been resolved with further discussion in the design team, and no action is required.