jiebi/TextFlow huggingface dataset:
Original text:
A Diffie-Hellman finite-field group or elliptic curve <del> A Derive-Key-Pair function that produces a key pair from an octet string </del>  <del> A hash function </del>  A ratchet tree is a left-balanced binary tree, in which each node contains up to three values: An asymmetric public key <del> The private key and public key for a node are derived from its secret value using the Derive-Key-Pair operation. </del>  The contents of a parent node are computed from one of its children as follows: updated child * Identify a node in the resolution of the copath node for which this node has a private key * Decrypt the secret value for the parent of the copath node using the private key from <del> the resolution node * Compute secret values for ancestors of that node by hashing the decrypted secret </del>  Merge the updated secrets into the tree * Replace the public keys for nodes on the direct path with the received public keys * For

Reviewer comments:
For now, I've only touched the sections until the "Cryptographic Objects" section, which seems to be outdated anyway. Once those are updated at some point, I'm happy to help moving from hashing to KDF-derivation there as well.
Thanks Konrad ! : )

Revised text:
A Diffie-Hellman finite-field group or elliptic curve  <ins> A Key Derivation Function (KDF) </ins>  <ins> A Derive-Public-Key function that produces a public key from a private key </ins> A ratchet tree is a left-balanced binary tree, in which each node contains up to three values: An asymmetric public key  <ins> The private key for a node is derived from its secret value using the KDF.  The public key is then derived from the private key using the Derive-Public-Key function. </ins> The contents of a parent node are computed from one of its children as follows: updated child * Identify a node in the resolution of the copath node for which this node has a private key * Decrypt the secret value for the parent of the copath node using the private key from  <ins> the resolution node * Derive secret values for ancestors of that node using the KDF keyed with the decrypted secret </ins> Merge the updated secrets into the tree * Replace the public keys for nodes on the direct path with the received public keys * For
Original text:
Since the new member is expected to process the Add message for itself, the Welcome message should reflect the state of the group before the new user is added.  The sender of the Welcome message can <del> simply copy all fields except the "leaf_secret" from its GroupState object. </del>  [[ OPEN ISSUE: The Welcome message needs to be synchronized in the same way as the Add.  That is, the Welcome should be sent only if the

Reviewer comments:
There is no "leaf_secret" field in GroupState. While there might be one in the group state struct that the implementation maintains locally, I think it's safe to recommend copying everything from the GroupState object as it's defined earlier in the document.

Revised text:
Since the new member is expected to process the Add message for itself, the Welcome message should reflect the state of the group before the new user is added.  The sender of the Welcome message can  <ins> simply copy all fields from their GroupState object. </ins> [[ OPEN ISSUE: The Welcome message needs to be synchronized in the same way as the Add.  That is, the Welcome should be sent only if the
Original text:
corresponding to the ciphersuite in use, as well as the credential under which the UserInitKey was signed <del> The update secret resulting from this change is an all-zero octet </del>  string of length Hash.length. After processing an Add message, the new member SHOULD send an Update path from the updated leaf using the information contained in the Update message <del> The update secret resulting from this change is the path secret for the root node of the ratchet tree. </del>  9.4. justifies the existence of a non-blank leaf in the ratchet tree in step 5. <del> The update secret resulting from this change is the path secret computed for the root node of the ratchet tree in the first step. </del>  10.

Reviewer comments:
"The update secret resulting from this change is the path secret for the root node of the ratchet tree." is suspicious because in the derivation, the index for both the and is the same as the level of the node. It should be the "above the root" and not "for the root" (which is the one used to derive the of the root)...
Here's the Weekly Digest for : - - Last week 5 issues were created. Of these, 1 issues have been closed and 4 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :heart: , by - - Last week, 9 pull requests were created, updated or merged. Last week, 3 pull requests were opened. :greenheart: , by :greenheart: , by :greenheart: , by Last week, 1 pull request was updated. :yellowheart: , by Last week, 5 pull requests were merged. :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by - - Last week there were 8 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there were 2 contributors. :bustinsilhouette: :bustinsilhouette: - - 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:
corresponding to the ciphersuite in use, as well as the credential under which the UserInitKey was signed  <ins> The "update_secret" resulting from this change is an all-zero octet </ins> string of length Hash.length. After processing an Add message, the new member SHOULD send an Update path from the updated leaf using the information contained in the Update message  <ins> The "update_secret" resulting from this change is the "path_secret[i+1]" derived from the "path_secret[i]" associated to the root node. </ins> 9.4. justifies the existence of a non-blank leaf in the ratchet tree in step 5.  <ins> The "update_secret" resulting from this change is the "path_secret[i+1]" derived from the "path_secret[i]" associated to the root node. </ins> 10.
Original text:
cryptographic keys it holds.  An application or user may use one client per device (keeping keys local to each device) or sync keys among a user's devices so that each user appears as a single  client. A collection of clients with shared cryptographic state. negotiated MLS ciphersuite to AEAD encrypt and decrypt their Application messages according to the Message Framing section. <del> The group identifier and epoch allow a device to know which group </del>  secrets should be used and from which Epoch secret to start computing other secrets and keys.  The "sender" identifier is used to derive the member's Application secret chain from the initial group

Reviewer comments:
Here's the Weekly Digest for : - - Last week 5 issues were created. Of these, 1 issues have been closed and 4 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :heart: , by - - Last week, 9 pull requests were created, updated or merged. Last week, 3 pull requests were opened. :greenheart: , by :greenheart: , by :greenheart: , by Last week, 1 pull request was updated. :yellowheart: , by Last week, 5 pull requests were merged. :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by - - Last week there were 8 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there were 2 contributors. :bustinsilhouette: :bustinsilhouette: - - 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:
cryptographic keys it holds.  An application or user may use one client per device (keeping keys local to each device) or sync keys among a user's devices so that each user appears as a single <ins> client.  In the scenario where multiple devices share the cryptographic material the client is referred to as a "virtual" </ins> client. A collection of clients with shared cryptographic state. negotiated MLS ciphersuite to AEAD encrypt and decrypt their Application messages according to the Message Framing section.  <ins> The group identifier and epoch allow a recipient to know which group </ins> secrets should be used and from which Epoch secret to start computing other secrets and keys.  The "sender" identifier is used to derive the member's Application secret chain from the initial group
Original text:
cases, the path is ordered from the leaf to the root; each node MUST be the parent of its predecessor. <del> The length of the "node_secrets" vector MUST be zero for the first </del>  node in the path.  For the remaining elements in the vector, the <del> number of ciphertexts in the "node_secrets" vector MUST be equal to </del>  the length of the resolution of the corresponding copath node.  Each ciphertext in the list is the encryption to the corresponding node in the resolution.

Reviewer comments:
The underscore character does not have to be escaped in code environments. This applies to the inline (backticks) as well as block (tildes) variants.
Here's the Weekly Digest for : - - Last week 2 issues were created. Of these, 2 issues have been closed and 0 issues are still open. :heart: , by :heart: , by - - Last week, 4 pull requests were created, updated or merged. Last week, 4 pull requests were merged. :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by - - Last week there were 9 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there was 1 contributor. :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 5 issues were created. Of these, 1 issues have been closed and 4 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :heart: , by - - Last week, 9 pull requests were created, updated or merged. Last week, 3 pull requests were opened. :greenheart: , by :greenheart: , by :greenheart: , by Last week, 1 pull request was updated. :yellowheart: , by Last week, 5 pull requests were merged. :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by - - Last week there were 8 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there were 2 contributors. :bustinsilhouette: :bustinsilhouette: - - 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:
cases, the path is ordered from the leaf to the root; each node MUST be the parent of its predecessor.  <ins> The length of the "node_secrets" vector MUST be zero for the first </ins> node in the path.  For the remaining elements in the vector, the  <ins> number of ciphertexts in the "node_secrets" vector MUST be equal to </ins> the length of the resolution of the corresponding copath node.  Each ciphertext in the list is the encryption to the corresponding node in the resolution.
Original text:
This structure incorporates everything in an MLSPlaintext up to the confirmation field in the transcript that is included in that <del> confirmation field (via the GroupState).  The confirmation and </del>  signature fields are then included in the transcript for the next operation.  The intermediate hash enables implementations to in corporate a plaintext into the transcript without having to store the

Reviewer comments:
Race condition between and
Here's the Weekly Digest for : - - Last week 2 issues were created. Of these, 2 issues have been closed and 0 issues are still open. :heart: , by :heart: , by - - Last week, 4 pull requests were created, updated or merged. Last week, 4 pull requests were merged. :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by - - Last week there were 9 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there was 1 contributor. :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 .

Revised text:
This structure incorporates everything in an MLSPlaintext up to the confirmation field in the transcript that is included in that  <ins> confirmation field (via the GroupContext).  The confirmation and </ins> signature fields are then included in the transcript for the next operation.  The intermediate hash enables implementations to in corporate a plaintext into the transcript without having to store the
Original text:
cases, the path is ordered from the leaf to the root; each node MUST be the parent of its predecessor. <del> The length of the "node_secrets" vector MUST be zero for the first node in the path.  For the remaining elements in the vector, the number of ciphertexts in the "node_secrets" vector MUST be equal to the length of the resolution of the corresponding copath node.  Each ciphertext in the list is the encryption to the corresponding node in the resolution. </del>  The HPKECiphertext values are computed according to the Encrypt function defined in I-D.barnes-cfrg-hpke.

Reviewer comments:
NAME pointed out this disconnect in , but the fix needs to be the other way around.
Here's the Weekly Digest for : - - Last week 2 issues were created. Of these, 2 issues have been closed and 0 issues are still open. :heart: , by :heart: , by - - Last week, 4 pull requests were created, updated or merged. Last week, 4 pull requests were merged. :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by - - Last week there were 9 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there was 1 contributor. :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 .

Revised text:
cases, the path is ordered from the leaf to the root; each node MUST be the parent of its predecessor.  <ins> The length of the "encrypted_path_secret" vector MUST be zero for the first node in the path.  For the remaining elements in the vector, the number of ciphertexts in the "encrypted_path_secret" vector MUST be equal to the length of the resolution of the corresponding copath node.  Each ciphertext in the list is the encryption to the corresponding node in the resolution. </ins> The HPKECiphertext values are computed according to the Encrypt function defined in I-D.barnes-cfrg-hpke.
Original text:
node.  Each ciphertext in the list is the encryption to the corresponding node in the resolution. <del> The HPKECiphertext values are computed according to the Encrypt function defined in I-D.barnes-cfrg-hpke. </del>  Decryption is performed in the corresponding way, using the private key of the resolution node and the ephemeral public key transmitted

Reviewer comments:
Here's the Weekly Digest for : This week, 8 issues were created. Of these, 4 issues have been closed and 4 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :heart: , by :heart: , by :heart: , by :heart: , by The issue most discussed this week has been: :speaker: , by It received 9 comments. This week, no pull requests has been proposed by the users. This week, 4 users have contributed to this repository. They are , , , and . This week, no user has starred this repository. This week, there have been 4 commits in the repository. These are: :hammerandwrench: Merge pull request from rozbb/mlsplaintext-signature Multiple clarifications around Framing by :hammerandwrench: Merge pull request from rozbb/hpke-encrypt Clarify how HPKE ciphertexts are computed by :hammerandwrench: by :hammerand_wrench: by # RELEASES This week, no releases were published. That's all for this week, please watch :eyes: and star :star: to receive next weekly updates. :smiley:

Revised text:
node.  Each ciphertext in the list is the encryption to the corresponding node in the resolution.  <ins> The HPKECiphertext values are computed as where "node_public_key" is the public key of the node that the path secret is being encrypted for, and the functions "SetupBaseI" and "Seal" are defined according to I-D.barnes-cfrg-hpke. </ins> Decryption is performed in the corresponding way, using the private key of the resolution node and the ephemeral public key transmitted
Original text:
current state using the Add message.  This information is encrypted for the new member using HPKE.  The recipient key pair for the HPKE encryption is the one included in the indicated ClientInitKey, <del> corresponding to the indicated ciphersuite. </del>  In the description of the tree as a list of nodes, the "credential" field for a node MUST be populated if and only if that node is a leaf

Reviewer comments:
Prior drafts enabled encryption of handshake messages, via the common framing structure. This had the unfortunate effect of making it impossible to add new members! If an Add is sent encrypted, then the new joiner had no way to get the key to decrypt it. This PR adds the key and nonce for the Add encryption to the corresponding WelcomeInfo structure. This maintains the confidentiality of the Add because the WelcomeInfo is encrypted to the new joiner, while providing the new joiner the key material it needs to decrypt the Add.
I think we'll need to carefully study the impact of this one but this seems fine for now. In the future aligning the way we do and (for the new member) which both are PKE operations will probably allow us to merge and and remove that issue all together.

Revised text:
current state using the Add message.  This information is encrypted for the new member using HPKE.  The recipient key pair for the HPKE encryption is the one included in the indicated ClientInitKey,  <ins> corresponding to the indicated ciphersuite.  The "add_key_nonce" field contains the key and nonce used to encrypt the corresponding Add message; if it is not encrypted, then this field MUST be set to the null optional value. </ins> In the description of the tree as a list of nodes, the "credential" field for a node MUST be populated if and only if that node is a leaf
Original text:
specifies both (i) how a client performs the operation and (ii) how other clients update their state based on it. <del> There are four major operations in the lifecycle of a group: </del>  Adding a member, initiated by a current member;

Reviewer comments:
The operations in the lifecycle of a group has been reduced to three.
Thank you !
Here's the Weekly Digest for : - - Last week 2 issues were created. Of these, 1 issues have been closed and 1 issues are still open. :greenheart: , by :heart: , by :+1: , by It received :+1: x1, :smile: x0, :tada: x0 and :heart: x0. :speaker: , by It received 1 comments. - - Last week, 3 pull requests were created, updated or merged. Last week, 1 pull request was opened. :greenheart: , by Last week, 1 pull request was updated. :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: :bustinsilhouette: - - Last week there were 3 stagazers. :star: :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:
specifies both (i) how a client performs the operation and (ii) how other clients update their state based on it.  <ins> There are three major operations in the lifecycle of a group: </ins> Adding a member, initiated by a current member;
Original text:
RFC EDITOR PLEASE DELETE THIS SECTION.  draft-07 Initial version of the Tree based Application Key Schedule (*)

Reviewer comments:
Merging myself because this is trivial.
Here's the Weekly Digest for : - - Last week 3 issues were created. Of these, 1 issues have been closed and 2 issues are still open. :greenheart: , by :greenheart: , by :heart: , by :speaker: , by It received 1 comments. - - Last week, 6 pull requests were created, updated or merged. Last week, 1 pull request was opened. :greenheart: , by Last week, 1 pull request was updated. :yellowheart: , by Last week, 4 pull requests were merged. :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by - - Last week there were 6 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there was 1 contributor. :bustinsilhouette: - - 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:
RFC EDITOR PLEASE DELETE THIS SECTION. <ins> draft-08 Change ClientInitKeys so that they only refer to one ciphersuite (*) </ins> draft-07 Initial version of the Tree based Application Key Schedule (*)