Original text:
The former is used to update the confirmed transcript hash and the latter to update the interim transcript hash.  8.3. In addition to initializing a new epoch via KDF invocations as 11. <del> A group is always created with a single member, the "creator".  The other members are added when the creator effectively sends itself Add proposals, commits them, and then sends the corresponding Welcome message to the new participants.  These processes are described in detail in add, commit, and joining-via-welcome-message. </del>  The creator of a group MUST take the following steps to initialize the group: <del> Fetch KeyPackages for the members to be added, and select a version and ciphersuite according to the capabilities of the members.  To protect against downgrade attacks, the creator MUST use the "capabilities" information in these KeyPackages to verify that the chosen version and ciphersuite is the best option supported by all members. </del> Initialize a one-member group with the following initial values: Ratchet tree: A tree with a single node, a leaf containing an 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>  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>  <del> Construct a Commit message that commits all of the Add proposals, in any order chosen by the creator (see commit) </del>  <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>  <del> Transmit the Welcome message to the other new members </del>  <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>  <del> The recipient of a Welcome message processes it as described in joining-via-welcome-message. </del>  In principle, the above process could be streamlined by having the creator directly create a tree and choose a random value for first In both cases, the new members need information to bootstrap their local group state.  New members MUST verify that "group_id" is unique among the groups they're currently participating in.

Reviewer comments:
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.

Revised text:
The former is used to update the confirmed transcript hash and the latter to update the interim transcript hash. <ins> In this notation, "InterimTranscriptHashInput_[epoch]" and "ConfirmedTranscriptHashInput_[epoch+1]" are based on the Commit that initiated the epoch with epoch number "epoch".  (Note that the "epoch" field in this Commit will be set to "epoch - 1", since it is sent within the previous epoch.) </ins> 8.3. In addition to initializing a new epoch via KDF invocations as 11.  <ins> A group is always created with a single member, the "creator".  Other members are then added to the group using the usual Add/Commit mechanism. The creator of a group is responsible for setting the group ID, ciphersuite, and initial extensions for the group.  If the creator intends to add other members at the time of creation, then it SHOULD Fetch KeyPackages for the members to be added, and select a ciphersuite and extensions according to the capabilities of the members.  To protect against downgrade attacks, the creator MUST use the "capabilities" information in these KeyPackages to verify that the chosen version and ciphersuite is the best option supported by all members. 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. </ins> The creator of a group MUST take the following steps to initialize the group:  Initialize a one-member group with the following initial values: Ratchet tree: A tree with a single node, a leaf containing an Confirmed transcript hash: The zero-length octet string  <ins> Epoch secret: A fresh random value of size "KDF.Nh" </ins> Extensions: Any values of the creator's choosing  <ins> Calculate the interim transcript hash: </ins>  <ins> Derive the "confirmation_key" for the epoch as described in key-schedule. </ins>  <ins> Compute a "confirmation_tag" over the empty "confirmed_transcript_hash" using the "confirmation_key" as described in content-authentication. </ins>  <ins> Compute the updated "interim_transcript_hash" from the "confirmed_transcript_hash" and the "confirmation_tag" as described in </ins>  <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>  <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 In both cases, the new members need information to bootstrap their local group state. <ins> The "group_context" field represents the current state of the group. The "extensions" field allows the sender to provide additional data that might be useful to new joiners.  The "confirmation_tag" represents the confirmation tag from the Commit that initiated the current epoch, or for epoch 0, the confirmation tag computed in the creation of the group (see group-creation).  (In either case, the creator of a GroupInfo may recompute the confirmation tag as "MAC(confirmation_key, confirmed_transcript_hash)".) </ins> New members MUST verify that "group_id" is unique among the groups they're currently participating in.