Change:
3.1. Different applications operated by different entities can use MLS to <del> exchange E2EE messages.  For example in email applications, clients of email1.com can encrypt and decrypt E2EE email messages from email2.com. </del> <ins> exchange end-to-end encrypted messages.  For example in email applications, clients of email1.com can encrypt and decrypt end-to- end encrypted email messages from email2.com. </ins> 3.2. Different client applications operated by the same server can use MLS <del> to exchange E2EE handshake and application messages.  For example different browsers can implement the MLS protocol, and web developers write web applications that use the MLS implementation in the browser to encrypt and decrypt the messages.  This will require a new standard Web API to allow the client applications to set the address of the delivery service in the browser.  A more concrete example is using MLS in the browser to exchange SRTP keys for multi-party conference call. </del> <ins> to exchange end-to-end encrypted handshake and application messages. For example different browsers can implement the MLS protocol, and web developers write web applications that use the MLS implementation in the browser to encrypt and decrypt the messages.  This will require a new standard Web API to allow the client applications to set the address of the delivery service in the browser.  A more concrete example is using MLS in the browser to negotiate SRTP keys for multi-party conference calls. </ins> 4. 4.1. <del> In MLS environment the messages can either be delivered using client fanout or server fanout, each will have different requirements. </del> <ins> In a federated environment, the different members of a group might use different Delivery Services.  Each client SHOULD only connect to its respective Deliver Service, which in turn will connect to other Delivery Services to relay messages. </ins> <del> In a federated environment the client may communicate with one or more delivery services.  Discovering the delivery service and syncing between different delivery services are out of scope of this document. 4.1.1. In this mode, the client SHOULD support communicating with multiple delivery services.  Discovering the delivery service is out of scope </del> <ins> One Delivery Service MUST be responsible for handshake message ordering at any given point in time, since TreeKEM requires handshake messages to have a total order.  It MUST be clear to all clients and Delivery Services of the group which Delivery Service is responsible. The protocol between different delivery services is out of the scope </ins> of this document. <del> In this mode, the delivery service SHPULD be stateless, and it the clients responsibility to maintain the group state.  OPEN QUESTION: How ordering could be enforced in this mode? 4.1.2. Multiple delivery services can be avoided, with server side fan out, and all keys requests can be proxied through a single delivery service.  The protocol between different delivery services is out of the scope of this document. </del> OPEN QUESTION: How server assist could be used with multiple servers? how the server state is shared and synced ? 4.2. <del> There is no change needed for the authentication service, however the </del> <ins> There is no change needed for the Authentication Service, however </ins> authentication in a federated environment becomes more important. The ideal solution would be using a shared transparency log like KeyTransparency.

Discussion:
Addressed SV's comments Remove the client fanout concept (because of TreeKEM's handshake ordering requirements) Rename UserInitKeys to ClientInitKeys Minor editorial edits
drop client fanout specify why (policy enforcement, metadata protection) incorporated comments from SV check if it is necessary to define server-to-server message formats only one domain is responsible for a group
I'm very interested in the details of this, but was unable to attend the interim meeting. Does this mean that we are explicitly ruling out client fanout entirely? What metadata are we trying to protect here? You could in theory protect all the metadata with client fanout over Tor for example. Does domain here mean domain name? Why is that relevant? (I'd expect MLS to be independent of DNS) The kind of federated delivery service I'm hoping to be able to use with MLS is logically an append only list of messages published by each member. Where each member can read any other members queue and pull messages they don't have into their own queue (they push their own messages to their own queue only). This allows for diverse P2P topologies, and bandwidth efficient routing. This would be compatible with both and .
TreeKEM has the requirement of total ordering of handshake messages which doesn't work with client fanout. Therefore we drop the idea of client fanout until we have a better proposal on how to solve this. is more conceptual, it doesn't have to be an actual domain name.
Addressed in .