Change:
Enable Add and Remove proposals from outside the group (*) <ins> Replace Init messages with multi-recipient Welcome message (*) </ins> draft-07 Initial version of the Tree based Application Key Schedule (*)

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