Change:
10.2.1. <del> The sender of a Commit message is responsible for sending Welcome messages to any new members added via Add proposals.  The Welcome message provides the new member with the current state of the group, after the application of the Commit message.  So the new member will </del> <ins> The sender of a Commit message is responsible for sending a Welcome message to any new members added via Add proposals.  The Welcome message provides the new members with the current state of the group, after the application of the Commit message.  The new members will </ins> not be able to decrypt or verify the Commit message, but will have <del> the secrets it needs to participate in the epoch initiated by the </del> <ins> the secrets they need to participate in the epoch initiated by the </ins> Commit message. <del> The information in a Welcome message is encrypted for the new member using HPKE.  The recipient key pair for the HPKE encryption is the one included in the indicated ClientInitKey. </del> <ins> In order to allow the same Welcome message to be sent to all new members, information describing the group is encrypted with a symmetric key and nonce randomly chosen by the sender.  This key and nonce are then encrypted to each new member using HPKE.  In the same encrypted package, the committer transmits the path secret for the lowest node contained in the direct paths of both the committer and the new member.  This allows the new member to compute private keys for nodes in its direct path that are being reset by the corresponding Commit. </ins> In the description of the tree as a list of nodes, the "credential" field for a node MUST be populated if and only if that node is a leaf <del> in the tree. </del> <ins> in the tree (i.e., a node with an even index). On receiving a Welcome message, a client processes it using the following steps: </ins> <del> [[ OPEN ISSUE: If multiple members are being added, it would be nice to be able to encrypt the group state once and just encrypt the key to the members.  In that case, you would also need to factor out the "index" field. ]] </del> <ins> Identify an entry in the "key_packages" array where the "client_init_key_hash" value corresponds to one of this client's ClientInitKeys, using the hash indicated by the "cipher_suite" field.  If no such field exists, or if the ciphersuite indicated in the ClientInitKey does not match the one in the Welcome message, return an error. Decrypt the "encrypted_key_package" using HPKE with the algorithms indicated by the ciphersuite and the HPKE public key in the ClientInitKey. Decrypt the "encrypted_group_info" field using the key and nonce in the decrypted KeyPackage object. Verify the signature on the GroupInfo object.  The signature input comprises all of the fields in the GroupInfo object except the signature field.  The public key and algorithm are taken from the credential in the leaf node at position "signer_index".  If this verification fails, return an error. Identify a leaf in the "tree" array (i.e., an even-numbered node) whose "public_key" and "credential" fields are identical to the corresponding fields in the ClientInitKey.  If no such field exists, return an error.  Let "index" represent the index of this node among the leaves in the tree, namely the index of the node in the "tree" array divided by two. Construct a new group state using the information in the GroupInfo object.  The new member's position in the tree is "index", as defined above. Identify the lowest node at which the direct paths from "index" and "signer_index" overlap.  Set private keys for that node and its parents up to the root of the tree, using the "path_secret" from the KeyPackage and following the algorithm in ratchet-tree- updates to move up the tree. </ins> 11.

Discussion:
This PR makes two major changes that are enabled by Proposals: Multiple participants added in the same epoch receive the same Welcome message Init is always a special case of Add Prior to Proposals, treating Init as a special case of Add led to a performance degradation (). With Proposals, any number of Adds can be done with a single Commit (at cost), so there is no more degradation. The result seems (IMO) much more elegant than before. The main cost is that encryption of Welcome messages is now in two stages (three if you include the internal HPKE stage!), even if there is only one new member. Depends on Obsoletes and
Here's the Weekly Digest for : - - Last week 9 issues were created. Of these, 6 issues have been closed and 3 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :heart: , by :heart: , by :heart: , by :heart: , by :heart: , by :heart: , by :speaker: , by It received 2 comments. - - Last week, 13 pull requests were created, updated or merged. Last week, 3 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 10 pull requests were merged. :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by - - Last week there were 38 commits.

:hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there were 2 contributors. :bustinsilhouette: :bustin_silhouette: - - Last week there was 1 stargazer. :star: You are the star! :star2: - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .*
Instead of initializing new members with information from the previous epoch and requiring them to process an Add, we should initialize new members directly with current epoch information. This is covered in , but should be factored out.
Dependent on: Some modeling to convince ourselves that removing isn't dangerous Blocks:
I have made a Tamarin model of the 2- and 3-member cases of the proposal in , which shows that it provides certain authentication properties that one should expect of an AKE.

In particular, it provides the property that even if the adder is malicious, they cannot cause the new member and the existing members to come to differing views of the group without causing to group to decohere. (Since the GroupContext is included in the key schedule, this might not be surprising.) Tamarin model here: URL Given this analysis, I'm comfortable making this change. It's preliminary, but I think it's good enough to justify moving forward with this concept pending a more complete analysis.
Fixed in
Modulo fixes discussed with Richard