jiebi/TextFlow huggingface dataset:
Original text:
public keys are opaque values in a format defined by the signature scheme.  6.4. To allow group members to verify that they agree on the cryptographic

Reviewer comments:
I couldn't find this written anywhere else and this is also related to a discussion about PCS with Cas and al.
Here's the Weekly Digest for : - - Last week, no issues were created. - - Last week, 5 pull requests were created, updated or merged. Last week, 3 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 2 pull requests were merged. :purpleheart: , by :purpleheart: , by - - Last week there were 2 commits. :hammerandwrench: by :hammerandwrench: by - - Last week there was 1 contributor. :bustin_silhouette: - - 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 18 issues were created. Of these, 3 issues have been closed and 15 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :heart: , by :heart: , by :heart: , by :speaker: , by It received 5 comments. - - Last week, 10 pull requests were created, updated or merged. Last week, 1 pull request was opened. :greenheart: , by Last week, 7 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 2 pull requests were merged. :purpleheart: , by :purpleheart: , by - - Last week there were 4 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there were 4 contributors. :bustinsilhouette: :bustinsilhouette: :bustinsilhouette: :bustin_silhouette: - - 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:
public keys are opaque values in a format defined by the signature scheme. <ins> Note that each new credential that has not already been validated by the application SHOULD be validated against the Authentication Service. [[OPEN ISSUE: 1.  SHOULD vs MUST.  2.  A client that wants to update its identity key can perform the operation UNDER THIS CONDITION by 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 application.  If this verfication is not met, there is no authentication guarantee at the application layer anyway.]] </ins> 6.4. To allow group members to verify that they agree on the cryptographic
Original text:
The resolution of a blank leaf node is the empty list The resolution of a blank intermediate node is the result of <del> concatinating the resolution of its left child with the resolution </del>  of its right child, in that order For example, consider the following tree, where the "_" character

Reviewer comments:
This PR corrects three minor typos.
Thank you Pascal !
Here's the Weekly Digest for : - - Last week 18 issues were created. Of these, 3 issues have been closed and 15 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :heart: , by :heart: , by :heart: , by :speaker: , by It received 5 comments. - - Last week, 10 pull requests were created, updated or merged. Last week, 1 pull request was opened. :greenheart: , by Last week, 7 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 2 pull requests were merged. :purpleheart: , by :purpleheart: , by - - Last week there were 4 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there were 4 contributors. :bustinsilhouette: :bustinsilhouette: :bustinsilhouette: :bustin_silhouette: - - 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:
The resolution of a blank leaf node is the empty list The resolution of a blank intermediate node is the result of  <ins> concatenating the resolution of its left child with the resolution </ins> of its right child, in that order For example, consider the following tree, where the "_" character
Original text:
updated root key after an Update operation, it cannot compute any derived secrets.  12.4. Initialization keys are intended to be used only once and then

Reviewer comments:
Here's the Weekly Digest for : - - Last week, no issues were created. - - Last week, 5 pull requests were created, updated or merged. Last week, 3 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 2 pull requests were merged. :purpleheart: , by :purpleheart: , by - - Last week there were 2 commits. :hammerandwrench: by :hammerandwrench: by - - Last week there was 1 contributor. :bustin_silhouette: - - 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 18 issues were created. Of these, 3 issues have been closed and 15 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :heart: , by :heart: , by :heart: , by :speaker: , by It received 5 comments. - - Last week, 10 pull requests were created, updated or merged. Last week, 1 pull request was opened. :greenheart: , by Last week, 7 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 2 pull requests were merged. :purpleheart: , by :purpleheart: , by - - Last week there were 4 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there were 4 contributors. :bustinsilhouette: :bustinsilhouette: :bustinsilhouette: :bustin_silhouette: - - 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:
updated root key after an Update operation, it cannot compute any derived secrets. <ins> In the case where the client could have been compromised (device loss...), the client SHOULD signal the delivery service to expire all the previous ClientInitKeys and publish fresh ones for PCS. </ins> 12.4. Initialization keys are intended to be used only once and then
Original text:
for the specified KEM from a symmetric secret, using the specified hash function. <del> Each node in a ratchet tree contains up to three values: </del>  A private key (only within direct path, see below) If necessary, extend the tree to the right until it has at least index + 1 leaves <del> For each intermediate node along the path from the leaf at position "index" to the root, add "index" to the "unmerged_leaves" list for the node. Blank the path from the leaf at position "index" to the root </del>  Set the leaf node in the tree at position "index" to a new node containing the public key from the ClientInitKey in the Add, as

Reviewer comments:
Blanking on add (I think) was obsoleted by unmerged leaves Add leaf to unmerged list for non-blank nodes on add There are now four elements in each node
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 .
Nice catch, Thank you !

Revised text:
for the specified KEM from a symmetric secret, using the specified hash function.  <ins> Each node in a ratchet tree contains up to four values: </ins> A private key (only within direct path, see below) If necessary, extend the tree to the right until it has at least index + 1 leaves  <ins> For each non-blank intermediate node along the path from the leaf at position "index" to the root, add "index" to the "unmerged_leaves" list for the node. </ins> Set the leaf node in the tree at position "index" to a new node containing the public key from the ClientInitKey in the Add, as
Original text:
Construct an initial Commit object with "updates", "removes", and "adds" fields populated from Proposals received during the current <del> epoch, and an empty "path" field. </del>  Generate a provisional GroupContext object by applying the proposals referenced in the initial Commit object in the order The "commit_secret" is the value "path_secret[n+1]" derived from the "path_secret[n]" value associated to the root node.  Construct an MLSPlaintext object containing the Commit object. Use the "commit_secret" to advance the key schedule and compute the "confirmation" value in the MLSPlaintext.  Sign the

Reviewer comments:
You can now rebase this on master for clarity.
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 :speaker: , by It received 3 comments. - - Last week, 8 pull requests were created, updated or merged. Last week, 7 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 1 pull request was merged. :purpleheart: , by - - Last week there were 3 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there were 2 contributors. :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 .
This looks good, just one minor clarification

Revised text:
Construct an initial Commit object with "updates", "removes", and "adds" fields populated from Proposals received during the current  <ins> epoch, and empty "client_init_key" and "path" fields. </ins> Generate a provisional GroupContext object by applying the proposals referenced in the initial Commit object in the order The "commit_secret" is the value "path_secret[n+1]" derived from the "path_secret[n]" value associated to the root node. <ins> Generate a new ClientInitKey for the Committer's own leaf.  Store it in the ratchet tree and assign it to the "client_init_key" field in the Commit object. </ins> Construct an MLSPlaintext object containing the Commit object. Use the "commit_secret" to advance the key schedule and compute the "confirmation" value in the MLSPlaintext.  Sign the
Original text:
While hashes at the nodes are used to check the integrity of the subtrees, signatures are required to provide authentication and group <del> agreement.  Siganatures are especially important in the case of </del>  newcomers and MUST be verified when joining.  All nodes in the tree MUST be signed to provide authentication and group agreement.

Reviewer comments:
These are resolved in .
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 :speaker: , by It received 3 comments. - - Last week, 8 pull requests were created, updated or merged. Last week, 7 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 1 pull request was merged. :purpleheart: , by - - Last week there were 3 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there were 2 contributors. :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 .

Revised text:
While hashes at the nodes are used to check the integrity of the subtrees, signatures are required to provide authentication and group  <ins> agreement.  Signatures are especially important in the case of </ins> newcomers and MUST be verified when joining.  All nodes in the tree MUST be signed to provide authentication and group agreement.
Original text:
Identify the lowest common ancestor in the tree of the new member's leaf node and the member sending the Commit <del> Compute the path secret corresponding to the commonn ancestor </del>  node Compute an EncryptedKeyPackage object that encapsulates the For each parent of the common ancestor, up to the root of the tree, derive a new path secret and set the private key for the node to the private key derived from the path secret.  The <del> private key MUST be the private key that correspondns to the </del>  public key in the node. Use the "epoch_secret" from the KeyPackage object to generate the signatures on the messages under identity keys. [[ OPEN ISSUE: Signatures under the identity keys, while simple, have <del> the side-effect of preclude deniability.  We may wish to allow other options, such as (ii) a key chained off of the identity key, or (iii) some other key obtained through a different manner, such as a </del>  pairwise channel that provides deniability for the message contents.]]

Reviewer comments:
This PR aims to fix some odd formulations, whilst maintaining the intended meaning of the sentences.
Thank you!

Revised text:
Identify the lowest common ancestor in the tree of the new member's leaf node and the member sending the Commit  <ins> Compute the path secret corresponding to the common ancestor </ins> node Compute an EncryptedKeyPackage object that encapsulates the For each parent of the common ancestor, up to the root of the tree, derive a new path secret and set the private key for the node to the private key derived from the path secret.  The  <ins> private key MUST be the private key that corresponds to the </ins> public key in the node. Use the "epoch_secret" from the KeyPackage object to generate the signatures on the messages under identity keys. [[ OPEN ISSUE: Signatures under the identity keys, while simple, have  <ins> the side-effect of precluding deniability.  We may wish to allow other options, such as (ii) a key chained off of the identity key, or (iii) some other key obtained through a different manner, such as a </ins> pairwise channel that provides deniability for the message contents.]]
Original text:
An agent that uses this protocol to establish shared cryptographic state with other clients.  A client is defined by the <del> 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. </del>  A collection of clients with shared cryptographic state.

Reviewer comments:
Could you please just restore the PSK part of the KeySchedule, I’ll handle that separately. Ps: we wouldn’t have forgot you... :) we intended to go back to the list later, but I’ll merge it now...

Revised text:
An agent that uses this protocol to establish shared cryptographic state with other clients.  A client is defined by the  <ins> cryptographic keys it holds. </ins> A collection of clients with shared cryptographic state.
Original text:
specification for more information). The signature algorithm specified in the ciphersuite is the mandatory <del> algorithm to be used for the signatutes in MLSPlaintext and the tree signatures.  It can be different from the signature algorithm specified in credential field of ClientInitKeys. </del>  The ciphersuites are defined in section mls-ciphersuites.

Reviewer comments:
required a common signature algorithm, but allowed credentials to deviate. This PR adds the requirement that credentials be consistent.

Revised text:
specification for more information). The signature algorithm specified in the ciphersuite is the mandatory  <ins> algorithm to be used for signatures in MLSPlaintext and the tree signatures.  It MUST be the same as the signature algorithm specified in the credential field of the ClientInitKey objects in the leaves of the tree (including the ClientInitKeys used to add new members). </ins> The ciphersuites are defined in section mls-ciphersuites.
Original text:
RFC EDITOR PLEASE DELETE THIS SECTION.  draft-08 Change ClientInitKeys so that they only refer to one ciphersuite This specification defines the following ciphersuites for use with MLS 1.0. <del> The KEM/DEM constructions used for HPKE are defined by HPKE.  The corresponding AEAD algorithms AEAD_AES_128_GCM and AEAD_AES_256_GCM, are defined in RFC5116.  AEAD_CHACHA20_POLY1305 is defined in RFC7539.  The corresponding hash algorithms are defined in SHS. </del>  It is advisable to keep the number of ciphersuites low to increase the chances clients can interoperate in a federated environment,

Reviewer comments:
Since draft-08, we have neglected to update the changelog, despite a bunch of significant changes. Also, because our CI is busted, some build failures crept in.

Revised text:
RFC EDITOR PLEASE DELETE THIS SECTION. <ins> draft-09 Remove blanking of nodes on Add (*) Change epoch numbers to uint64 (*) Add PSK inputs (*) Add key schedule exporter (*) Sign the updated direct path on Commit, using "parent hashes" and one signature per leaf (*) Use structured types for external senders (*) Redesign Welcome to include confirmation and use derived keys (*) Remove ignored proposals (*) Always include an Update with a Commit (*) Add per-message entropy to guard against nonce reuse (*) Use the same hash ratchet construct for both application and handshake keys (*) Add more ciphersuites Use HKDF to derive key pairs (*) Mandate expiration of ClientInitKeys (*) Add extensions to GroupContext and flesh out the extensibility story (*) </ins> draft-08 Change ClientInitKeys so that they only refer to one ciphersuite This specification defines the following ciphersuites for use with MLS 1.0.  <ins> The KEM/DEM constructions used for HPKE are defined by I-D.irtf-cfrg- hpke.  The corresponding AEAD algorithms AEAD_AES_128_GCM and AEAD_AES_256_GCM, are defined in RFC5116.  AEAD_CHACHA20_POLY1305 is defined in RFC7539.  The corresponding hash algorithms are defined in SHS. </ins> It is advisable to keep the number of ciphersuites low to increase the chances clients can interoperate in a federated environment,
Original text:
Generate a provisional GroupContext object by applying the proposals referenced in the initial Commit object in the order <del> provided, as described in proposals.  Add proposals are applied left to right: Each Add proposal is applied at the leftmost unoccupied leaf, or appended to the right edge of the tree if all leaves are occupied. </del>  Create a DirectPath using the new tree (which includes any new members).  The GroupContext for this operation uses the Generate a provisional GroupContext object by applying the proposals referenced in the commit object in the order provided, <del> as described in proposals.  Add proposals are applied left to right: Each Add proposal is applied at the leftmost unoccupied leaf, or appended to the right edge of the tree if all leaves are occupied. </del>  Process the "path" value using the ratchet tree the provisional GroupContext, to update the ratchet tree and generate the

Reviewer comments:
by updating the description for creating a commit to explicitly mention that first all update proposals are applied, then remove proposals, and last add proposals.
The writes: However, from this it is not immediately clear to me in which order the collections of proposals , , and are to be applied. I assume it should be in that order because it makes practical sense and because they're written in that order in the Commit struct. If my guess is correct, perhaps it would be useful to make this explicit? E.g.:
NAME - I agree with your interpretation here. Could you make a PR with some proposed wording?
Apologies for closing/opening the issue. I will open a PR to update the wording.

Revised text:
Generate a provisional GroupContext object by applying the proposals referenced in the initial Commit object in the order  <ins> provided, as described in proposals.  First the list of update proposals, then the list of remove proposals, and last the list of add proposals.  Add proposals are applied left to right: Each Add proposal is applied at the leftmost unoccupied leaf, or appended to the right edge of the tree if all leaves are occupied. </ins> Create a DirectPath using the new tree (which includes any new members).  The GroupContext for this operation uses the Generate a provisional GroupContext object by applying the proposals referenced in the commit object in the order provided,  <ins> as described in proposals.  First the list of update proposals, then the list of remove proposals, and last the list of add proposals.  Add proposals are applied left to right: Each Add proposal is applied at the leftmost unoccupied leaf, or appended to the right edge of the tree if all leaves are occupied. </ins> Process the "path" value using the ratchet tree the provisional GroupContext, to update the ratchet tree and generate the