Original text:
7.3.  To allow group members to verify that they agree on the public cryptographic state of the group, this section defines a scheme for generating a hash value that represents the contents of the group's Note that unlike a ParentNode, a ClientInitKey already contains a signature. <del> 7.4. </del>  Each member of the group maintains a GroupContext object that summarizes the state of the group: When a new group is created, the "interim_transcript_hash" field is set to the zero-length octet string. <del> 7.5. </del>  As described in commit, each MLS Commit message needs to transmit a ClientInitKey leaf and node values along its direct path.  The path key of the resolution node and the ephemeral public key transmitted in the message. <del> 7.6. </del>  Group keys are derived using the HKDF-Extract and HKDF-Expand functions as defined in RFC5869, as well as the functions defined Given these inputs, the derivation of secrets for an epoch proceeds as shown in the following diagram: <del> 7.7. </del>  Groups which already have an out-of-band mechanism to generate shared group secrets can inject those in the MLS key schedule to seed the [[OPEN ISSUE: We have to decide if we want an external coordination via the application of a Handshake proposal.]] <del> 7.8. </del>  As described in message-framing, MLS encrypts three different types of information: where "encode_big_endian()" encodes the generation in a big-endian integer of the same size as the base handshake nonce. <del> 7.9. </del>  The main MLS key schedule provides an "exporter_secret" which can be used by an application as the basis to derive new secrets called

Reviewer comments:
The is no longer needed, since CIKs are referenced by hash. ProposalIDs were no longer usable to refer to proposals since we enabled multiple proposals per MLSPlaintext The syntax description for Welcome was invalid
Merge with master obsoleted some changes. I re-implemented the "supportedversion"->"version" change, and added a "keyid" extension to address Benjamin's comment.
Here's the Weekly Digest for : - - Last week 4 issues were created. Of these, 0 issues have been closed and 4 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by - - Last week, 14 pull requests were created, updated or merged. Last week, 8 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 6 pull requests were merged. :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by - - Last week there were 10 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there were 3 contributors. :bustinsilhouette: :bustinsilhouette: :bustinsilhouette: - - Last week there were no stargazers. - - 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 .
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 .*

Revised text:
7.3. <ins> Within MLS, a ClientInitKey is identified by its hash (see, e.g., welcoming-new-members).  The "key_id" extension allows applications to add an explicit, application-defined identifier to a ClientInitKey. 7.4. </ins> To allow group members to verify that they agree on the public cryptographic state of the group, this section defines a scheme for generating a hash value that represents the contents of the group's Note that unlike a ParentNode, a ClientInitKey already contains a signature.  <ins> 7.5. </ins> Each member of the group maintains a GroupContext object that summarizes the state of the group: When a new group is created, the "interim_transcript_hash" field is set to the zero-length octet string.  <ins> 7.6. </ins> As described in commit, each MLS Commit message needs to transmit a ClientInitKey leaf and node values along its direct path.  The path key of the resolution node and the ephemeral public key transmitted in the message.  <ins> 7.7. </ins> Group keys are derived using the HKDF-Extract and HKDF-Expand functions as defined in RFC5869, as well as the functions defined Given these inputs, the derivation of secrets for an epoch proceeds as shown in the following diagram:  <ins> 7.8. </ins> Groups which already have an out-of-band mechanism to generate shared group secrets can inject those in the MLS key schedule to seed the [[OPEN ISSUE: We have to decide if we want an external coordination via the application of a Handshake proposal.]]  <ins> 7.9. </ins> As described in message-framing, MLS encrypts three different types of information: where "encode_big_endian()" encodes the generation in a big-endian integer of the same size as the base handshake nonce.  <ins> 7.10. </ins> The main MLS key schedule provides an "exporter_secret" which can be used by an application as the basis to derive new secrets called