Original text:
When a participant A wants to establish a group with B and C, it first downloads InitKeys for B and C.  It then initializes a group <del> state containing only itself and uses the InitKeys to compute Add messages to add B and C, in a sequence chosen by A.  These messages are broadcasted to the Group, and processed in sequence by B and C. Messages received before a participant has joined the group are ignored.  Only after A has received its Add messages back from the server does it update its state to reflect their addition. </del>  Subsequent additions of group members proceed in the same way.  Any member of the group can download an InitKey for a new participant and derivation and signing.  The client's identity key is intended to be stable throughout the lifetime of the group; there is no mechanism to change it.  Init keys are intended to be used a very limited number <del> of times, potentially once. (see init-key-reuse). </del>  The init_keys array MUST have the same length as the cipher_suites array, and each entry in the init_keys array MUST be a public key for The Welcome message contains the information that the new member needs to initialize a GroupState object that can be updated to the <del> current state using the Add message: </del>  Note that the "init_secret" in the Welcome message is the "init_secret" at the output of the key schedule diagram in key-

Reviewer comments:
This PR addresses two outstanding issues with Welcome messages: Welcome messages were not encrypted for the new member, so that the information in them (in particular, init secrets) were not appropriately protected. The protocol overview had not been updated to include the Welcome-based add flow.
This was resolved in , but recording it in this issue for posterity. A Welcome message carries the value for the group, and so it needs to be encrypted for the new joiner. The struct proposed in the revised draft wraps the information in the Welcome in an ECIES ciphertext, and adds enough information to enable the joiner to identify the private key it needs to decrypt the Welcome message.

Revised text:
When a participant A wants to establish a group with B and C, it first downloads InitKeys for B and C.  It then initializes a group  <ins> state containing only itself and uses the InitKeys to compute Welcome and Add messages to add B and C, in a sequence chosen by A.  The Welcome messages are sent directly to the new members (there is no need to send them to the group).  The Add messages are broadcasted to the Group, and processed in sequence by B and C.  Messages received before a participant has joined the group are ignored.  Only after A has received its Add messages back from the server does it update its state to reflect their addition. </ins> Subsequent additions of group members proceed in the same way.  Any member of the group can download an InitKey for a new participant and derivation and signing.  The client's identity key is intended to be stable throughout the lifetime of the group; there is no mechanism to change it.  Init keys are intended to be used a very limited number  <ins> of times, potentially once. (see init-key-reuse).  UserInitKeys also contain an identifier chosen by the client, which the client MUST assure uniquely identifies a given UserInitKey object among the set of UserInitKeys created by this client. </ins> The init_keys array MUST have the same length as the cipher_suites array, and each entry in the init_keys array MUST be a public key for The Welcome message contains the information that the new member needs to initialize a GroupState object that can be updated to the  <ins> current state using the Add message.  This information is encrypted for the new member using ECIES.  The recipient key pair for the ECIES encryption is the one included in the indicated UserInitKey, corresponding to the indicated ciphersuite. </ins> Note that the "init_secret" in the Welcome message is the "init_secret" at the output of the key schedule diagram in key-