Original text:
adding a new version of herself using a new credential signed under a new IdentityKey, then performing a remove of the old leaf.  This is fine as long as the credential binds to the same identity for the <del> application.  If this verfication is not met, there is no </del>  authentication guarantee at the application layer anyway.]] 6.3. The "epoch" field represents the current version of the group key. The "tree_hash" field contains a commitment to the contents of the <del> group's rachet tree and the credentials for the members of the </del>  group, as described in tree-hashes. The "confirmed_transcript_hash" field contains a running hash over The key and nonce used for the encryption of the message depend on the content type of the message.  The sender chooses the handshake <del> key for a handshake message or an ununsed generation from its (per- </del>  sender) application key chain for the current epoch, according to the type of message being encrypted.

Reviewer comments:
Yeah, I noticed that too as I was implementing. I will fix it in a “reconciliation with implementation” PR I’m working on.
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 11 issues were created. Of these, 1 issues have been closed and 10 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :heart: , by :speaker: , by It received 2 comments. - - Last week, 11 pull requests were created, updated or merged. Last week, 6 pull requests were opened. :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by Last week, 4 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 1 pull request was merged. :purpleheart: , by - - Last week there were 2 commits. :hammerandwrench: by :hammerandwrench: by - - Last week there were 2 contributors. :bustinsilhouette: :bustin_silhouette: - - Last week there were 2 stagazers. :star: :star: You all are the stars! :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:
adding a new version of herself using a new credential signed under a new IdentityKey, then performing a remove of the old leaf.  This is fine as long as the credential binds to the same identity for the  <ins> application.  If this verification is not met, there is no </ins> authentication guarantee at the application layer anyway.]] 6.3. The "epoch" field represents the current version of the group key. The "tree_hash" field contains a commitment to the contents of the  <ins> group's ratchet tree and the credentials for the members of the </ins> group, as described in tree-hashes. The "confirmed_transcript_hash" field contains a running hash over The key and nonce used for the encryption of the message depend on the content type of the message.  The sender chooses the handshake  <ins> key for a handshake message or an unused generation from its (per- </ins> sender) application key chain for the current epoch, according to the type of message being encrypted.