Code change:
Blank the intermediate nodes along the path from the removed leaf to the root <ins> 10.1.4. Add and Remove proposals can be constructed and sent to the group by a party that is outside the group.  For example, a Delivery Service might propose to remove a member of a group has been inactive for a long time, or propose adding a newly-hired staff member to a group representing a real-world team.  Proposals originating outside the group are identified by having a "sender" value in the range 0xFFFFFF00 - 0xFFFFFFFF. The specific value 0xFFFFFFFF is reserved for clients proposing that they themselves be added.  Proposals with types other than Add MUST NOT be sent with this sender index.  In such cases, the MLSPlaintext MUST be signed with the private key corresponding to the ClientInitKey in the Add message.  Recipients MUST verify that the MLSPlaintext carrying the Proposal message is validly signed with this key. The remaining values 0xFFFFFF00 - 0xFFFFFFFE are reserved for signer that are pre-provisioned to the clients within a group.  If proposals with these sender IDs are to be accepted within a group, the members of the group MUST be provisioned by the application with a mapping between sender indices in this range and authorized signing keys.  To ensure consistent handling of external proposals, the application MUST ensure that the members of a group have the same mapping and apply the same policies to external proposals. An external proposal MUST be sent as an MLSPlaintext object, since the sender will not have the keys necessary to construct an MLSCiphertext object. [[ TODO: Should recognized external signers be added to some object that the group explicitly agrees on, e.g., as an extension to the GroupContext? ]] </ins> 10.2. A Commit message initiates a new epoch for the group, based on a

Related discussion:
text: the rest of the group The only difference between Remove and a server-initiated variant would be signature Other use cases: User deletes account User is no longer authorized to be in group Application would need to set policy about whether / when server-initiated actions would be allowed
I'm assigning this to draft-04 under the theory that the signature changes that will come about as a result of will make it straightforward to have an additional key for the server that can be used to sign Adds / Removes. If that doesn't turn out to be the case, this might get deferred.
After discussion with NAME and NAME There will be a need to signal that a non-member key is being used, e.g., with some reserved values Do the participants in the group need to agree the set of allowed non-member signers? If some members accept a signer, others don't, then you can get partition -04 will focus on Remove, not Add, and punt on the agreement question; we assume the application maintains consistency of the view of authorized signers.
We should push some of this to the application layer in order to not introduce a new handshake message with problematic authenticity (agreement on the list of non-members who can sign handshake messages). The server could publish an "intent to remove" that will be honored by the first client to come online. The actual Remove HS message will be issued by a member of the group. It can additionally be attached to the server intent to remove, so that clients can convey more contextual information to users. Example: Server issues the intent to remove Alice from the group. Bob comes online first after that and send a regular Remove HS message to remove Alice and links it to the sever intent. Other members of the group can now display "Alice was removed" instead of "Bob removed Alice" to the user. In this example Bob is the first member to come online, but it could really be any other member. This has the advantage that the protocol remains unaffected as such, while the desired behavior is still achieved.
Currently, in order for a new member to join a group, an existing member needs to add them to the group. Certain use cases work more naturally if a new joiner can initiate the add process. I think that broadly speaking we want a process here where someone outside the group can (1) request to be added and (2) send to the group, but cannot receive from the group until added.