Change:
Confirmed transcript hash: The zero-length octet string <del> Interim transcript hash: The zero-length octet string Init secret: A fresh random value of size "KDF.Nh" </del> <ins> Epoch secret: A fresh random value of size "KDF.Nh" </ins> Extensions: Any values of the creator's choosing <del> For each member, construct an Add proposal from the KeyPackage for that member (see add) </del> <ins> Calculate the interim transcript hash: </ins> <del> Construct a Commit message that commits all of the Add proposals, in any order chosen by the creator (see commit) </del> <ins> Derive the "confirmation_key" for the epoch as described in key-schedule. </ins> <del> Process the Commit message to obtain a new group state (for the epoch in which the new members are added) and a Welcome message </del> <ins> Compute a "confirmation_tag" over the empty "confirmed_transcript_hash" using the "confirmation_key" as described in content-authentication. </ins> <del> Transmit the Welcome message to the other new members </del> <ins> Compute the updated "interim_transcript_hash" from the "confirmed_transcript_hash" and the "confirmation_tag" as described in </ins> <del> Group IDs SHOULD be constructed in such a way that there's an overwhelmingly low probability of honest group creators generating the same group ID, even without assistance from the Delivery Service. For example, by making the group ID a freshly generated random value of size "KDF.Nh".  The Delivery Service MAY attempt to ensure that group IDs are globally unique by rejecting the creation of new groups with a previously used ID. </del> <ins> At this point, the creator's state represents a one-member group with a fully initialized key schedule, transcript hashes, etc.  Proposals and Commits can be generated for this group state just like any other state of the group, such as Add proposals and Commits to add other members to the group.  A GroupInfo object for this group state can also be published to facilitate external joins. </ins> <del> The recipient of a Welcome message processes it as described in joining-via-welcome-message. </del> <ins> Members other than the creator join either by being sent a Welcome message (as described in joining-via-welcome-message) or by sending an external Commit (see joining-via-external-commits). </ins> In principle, the above process could be streamlined by having the creator directly create a tree and choose a random value for first

Discussion:
This PR is an alternative to . This PR updates the group creation process so that epoch 0 is a "full-fledged" epoch, with an epoch secret (and all the derivatives) instead of just an init secret. One implication of that is that the interim transcript hash can now be computed in the usual way, by extending the confirmed transcript hash with a confirmation tag: This has the nice side effect of immediately mixing the epoch secret into the transcript hash, helping the group diverge (a concern NAME raised on the call today). While I was editing the group creation section, I also rationalized the requirements a bit. One reason that came up is that the group creation section currently assumes you're always starting with multiple members. So the MUST-level requirement to fetch key packages has been downgraded to a SHOULD. Finally, I updated the specification of GroupInfo to explain the fields, in particular explaining how you get the confirmation tag in epoch 0 or later epochs.
Since this PR clarifies more than and the solution is equally good, I'd suggest closing and merging this one.