jiebi/TextFlow huggingface dataset:
Original text:
the new state is the "prior_confirmed_transcript_hash" in the GroupInfo object. <del> Process the "path" field in the GroupInfo to update the new group state: </del>  <del> Apply the DirectPath to the tree, as described in synchronizing-views-of-the-tree. </del>  <del> Define "commit_secret" as the value "path_secret[n+1]" derived from the "path_secret[n]" value assigned to the root node. </del>  Use the "epoch_secret" from the KeyPackage object to generate the epoch secret and other derived secrets for the current epoch.

Reviewer comments:
This PR adapts the Welcome logic so that the new joiners get their path secrets directly, rather than from a DirectPath. This cleans things up in a few ways. The new joiners no longer have to have the context for the previous epoch (which was used to encrypt the DirectPath). And we can get away with one HPKE operation per new joiner instead of two (one for the EncryptedKeyPackage and one for the DirectPath). The major cost is that there's a bit more complexity in the TreeKEM. Instead of just producing and consuming DirectPaths, you now need to know which path secrets go with which nodes. You also need tree math to identify the common ancestor of two leaves, but there's a simple closed-form formula for that, expressed in the Python code here.
NAME - Curious if this seems implementable to you. Clearly it's possible, since I did it in Go :) But it also needs to make sense to other people.

Revised text:
the new state is the "prior_confirmed_transcript_hash" in the GroupInfo object.  <ins> Update the leaf at index "index" with the private key corresponding to the public key in the node. </ins>  <ins> Identify the lowest common ancestor of the leaves at "index" and at "GroupInfo.signer_index".  Set the private key for this node to the private key derived from the "path_secret" in the KeyPackage object. </ins>  <ins> 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 private key MUST be the private key that correspondns to the public key in the node. </ins> Use the "epoch_secret" from the KeyPackage object to generate the epoch secret and other derived secrets for the current epoch.
Original text:
A hash function <del> A Diffie-Hellman finite-field group or elliptic curve group </del>  An AEAD encryption algorithm A signature algorithm <del> The ciphersuite's Diffie-Hellman group is used to instantiate an HPKE I-D.irtf-cfrg-hpke instance for the purpose of public-key encryption. The ciphersuite must specify an algorithm "Derive-Key-Pair" that maps octet strings with length Hash.length to HPKE key pairs. </del>  Ciphersuites are represented with the CipherSuite type.  HPKE public <del> keys are opaque values in a format defined by the underlying Diffie- Hellman protocol (see the Ciphersuites section of the HPKE specification for more information). </del>  The signature algorithm specified in the ciphersuite is the mandatory algorithm to be used for signatures in MLSPlaintext and the tree

Reviewer comments:
The first commit is editorial. I removed all the DH terminology I could find and replaced it with KEM terminology. The second commit is related to URL It would massively reduce complexity of implementations if people were able to rely on HPKE to do all private key parsing, key validation, public key computation, etc. Currently, all the information in the deleted CFRG and NIST sections is either redundant (performed by HPKE) or outdated and performed correctly by HPKE (e.g., old P-256 DH secret representation). Instead of having all this duplicated, it would be easier to keep it in one place. An issue with the new definition of : Repeatedly calling can be computationally expensive. Each call requires computing the group hash (which, okay, it could be cached) and serializing a struct. It would be nice to do something that's cheaper but still ties context into the secret key generation.
Update: This now uses HPKE's function to do all the heavy lifting

Revised text:
A hash function  <ins> A key encapsulation mechanism (KEM) </ins> An AEAD encryption algorithm A signature algorithm  <ins> The ciphersuite's KEM used to instantiate an HPKE I-D.irtf-cfrg-hpke instance for the purpose of public-key encryption.  Each ciphersuite has a "Derive-Key-Pair" function that maps octet strings of length "Nsk" (a KEM-specific constant defined by HPKE) to HPKE key pairs. This function is defined to be HPKE's "DeriveKeyPair" function. </ins> Ciphersuites are represented with the CipherSuite type.  HPKE public  <ins> keys are opaque values in a format defined by the underlying protocol (see the Cryptographic Dependencies section of the HPKE specification for more information). </ins> The signature algorithm specified in the ciphersuite is the mandatory algorithm to be used for signatures in MLSPlaintext and the tree
Original text:
Note that, as a PSK may have a different lifetime than an update, it does not necessarily provide the same Forward Secrecy (FS) or Post- <del> Compromise Security (PCS) guarantees than a Commit message. </del>  7.10.

Reviewer comments:
A couple of minor editorial changes to the current draft, namely: There was a missing grave accent in one of the paragraphs of the Commit section causing some formatting issues Before: ! After: ! Fix typo Pre-Shared Keys section [...], it does not necessarily provide the same [...] guarantees ~than~ as a Commit message. Resolve remaining reference to priorepoch In the Sequencing section there was a reference to a field that was introduced in 2fa6ed3c6afc7d308905255b4cabe154a48d1e4b. However, in 69e12cd61378aae4a81199c28a16e2802666b6e3, it was removed from the struct where it was added. That entire struct was then removed in 27c9c28f9634a06a9b7921ea9c15e276f8c9ff6f, after which the trail runs cold. So I wasn't able to figure out exactly what it must be based on what on what it originally was. Hence, I replaced it with something that makes sense in context. I based the new text on the following line found in the (current) Commit section: Rewrite paragraph on the new_member SenderType I found the phrase " In such cases" after the sentence "Proposals with types other than Add MUST NOT be sent with this sender type" slightly confusing and awkward. To improve this I rewrote the paragraph.
Couple of nits on your nits

Revised text:
Note that, as a PSK may have a different lifetime than an update, it does not necessarily provide the same Forward Secrecy (FS) or Post-  <ins> Compromise Security (PCS) guarantees as a Commit message. </ins> 7.10.
Original text:
in MLSPlaintext. The "new_member" SenderType is used for clients proposing that they <del> themselves be added.  For this ID type the sender value MUST be zero. Proposals with types other than Add MUST NOT be sent with this sender type.  In such cases, the MLSPlaintext MUST be signed with the private key corresponding to the KeyPackage in the Add message. Recipients MUST verify that the MLSPlaintext carrying the Proposal message is validly signed with this key. </del>  The "preconfigured" SenderType is reserved for signers that are pre- provisioned to the clients within a group.  If proposals with these

Reviewer comments:
A couple of minor editorial changes to the current draft, namely: There was a missing grave accent in one of the paragraphs of the Commit section causing some formatting issues Before: ! After: ! Fix typo Pre-Shared Keys section [...], it does not necessarily provide the same [...] guarantees ~than~ as a Commit message. Resolve remaining reference to priorepoch In the Sequencing section there was a reference to a field that was introduced in 2fa6ed3c6afc7d308905255b4cabe154a48d1e4b. However, in 69e12cd61378aae4a81199c28a16e2802666b6e3, it was removed from the struct where it was added. That entire struct was then removed in 27c9c28f9634a06a9b7921ea9c15e276f8c9ff6f, after which the trail runs cold. So I wasn't able to figure out exactly what it must be based on what on what it originally was. Hence, I replaced it with something that makes sense in context. I based the new text on the following line found in the (current) Commit section: Rewrite paragraph on the new_member SenderType I found the phrase " In such cases" after the sentence "Proposals with types other than Add MUST NOT be sent with this sender type" slightly confusing and awkward. To improve this I rewrote the paragraph.
Couple of nits on your nits

Revised text:
in MLSPlaintext. The "new_member" SenderType is used for clients proposing that they  <ins> themselves be added.  For this ID type the sender value MUST be zero and the Proposal type MUST be Add. The MLSPlaintext MUST be signed with the private key corresponding to the KeyPackage in the Add message.  Recipients MUST verify that the MLSPlaintext carrying the Proposal message is validly signed with this key. </ins> The "preconfigured" SenderType is reserved for signers that are pre- provisioned to the clients within a group.  If proposals with these
Original text:
The "path" field of a Commit message MUST be populated if the Commit covers at least one Update or Remove proposal, i.e., if the length of <del> the "updates" or "removes vectors is greater than zero.  The "path"field MUST also be populated if the Commit covers no proposals at all (i.e., if all three proposal vectors are empty).  The "path"field MAY be omitted if the Commit covers only Add proposals. In pseudocode, the logic for whether the "path` field is required is as follows: </del>  To summarize, a Commit can have three different configurations, with different uses:

Reviewer comments:
A couple of minor editorial changes to the current draft, namely: There was a missing grave accent in one of the paragraphs of the Commit section causing some formatting issues Before: ! After: ! Fix typo Pre-Shared Keys section [...], it does not necessarily provide the same [...] guarantees ~than~ as a Commit message. Resolve remaining reference to priorepoch In the Sequencing section there was a reference to a field that was introduced in 2fa6ed3c6afc7d308905255b4cabe154a48d1e4b. However, in 69e12cd61378aae4a81199c28a16e2802666b6e3, it was removed from the struct where it was added. That entire struct was then removed in 27c9c28f9634a06a9b7921ea9c15e276f8c9ff6f, after which the trail runs cold. So I wasn't able to figure out exactly what it must be based on what on what it originally was. Hence, I replaced it with something that makes sense in context. I based the new text on the following line found in the (current) Commit section: Rewrite paragraph on the new_member SenderType I found the phrase " In such cases" after the sentence "Proposals with types other than Add MUST NOT be sent with this sender type" slightly confusing and awkward. To improve this I rewrote the paragraph.
Couple of nits on your nits

Revised text:
The "path" field of a Commit message MUST be populated if the Commit covers at least one Update or Remove proposal, i.e., if the length of  <ins> the "updates" or "removes" vectors is greater than zero.  The "path" field MUST also be populated if the Commit covers no proposals at all (i.e., if all three proposal vectors are empty).  The "path" field MAY be omitted if the Commit covers only Add proposals.  In pseudocode, the logic for whether the "path" field is required is as follows: </ins> To summarize, a Commit can have three different configurations, with different uses:
Original text:
12. Each Commit message is premised on a given starting state, indicated <del> in its "prior_epoch" field.  If the changes implied by a Commit messages are made starting from a different state, the results will be incorrect. </del>  This need for sequencing is not a problem as long as each time a group member sends a Commit message, it is based on the most current

Reviewer comments:
A couple of minor editorial changes to the current draft, namely: There was a missing grave accent in one of the paragraphs of the Commit section causing some formatting issues Before: ! After: ! Fix typo Pre-Shared Keys section [...], it does not necessarily provide the same [...] guarantees ~than~ as a Commit message. Resolve remaining reference to priorepoch In the Sequencing section there was a reference to a field that was introduced in 2fa6ed3c6afc7d308905255b4cabe154a48d1e4b. However, in 69e12cd61378aae4a81199c28a16e2802666b6e3, it was removed from the struct where it was added. That entire struct was then removed in 27c9c28f9634a06a9b7921ea9c15e276f8c9ff6f, after which the trail runs cold. So I wasn't able to figure out exactly what it must be based on what on what it originally was. Hence, I replaced it with something that makes sense in context. I based the new text on the following line found in the (current) Commit section: Rewrite paragraph on the new_member SenderType I found the phrase " In such cases" after the sentence "Proposals with types other than Add MUST NOT be sent with this sender type" slightly confusing and awkward. To improve this I rewrote the paragraph.
Couple of nits on your nits

Revised text:
12. Each Commit message is premised on a given starting state, indicated  <ins> by the "epoch" field of the enclosing MLSPlaintext message.  If the changes implied by a Commit messages are made starting from a different state, the results will be incorrect. </ins> This need for sequencing is not a problem as long as each time a group member sends a Commit message, it is based on the most current
Original text:
above), then it MUST be populated.  Otherwise, the sender MAY omit the "path" field at its discretion. <del> If populating the "path" field: Create a DirectPath using the new </del>  tree (which includes any new members).  The GroupContext for this operation uses the "group_id", "epoch", "tree_hash", and "confirmed_transcript_hash" values in the initial GroupContext object. <del> Assign this DirectPath to the "path" field in the Commit. </del>  <del> Apply the DirectPath to the tree, as described in </del>  synchronizing-views-of-the-tree.  Define "commit_secret" as the value "path_secret[n+1]" derived from the "path_secret[n]" value assigned to the root node.

Reviewer comments:
This is a simple rename of to to be more descriptive of the action being performed by the message. I'll open a separate PR after this PIR is merged with updates to the spec where it uses when instead it should say (since not every actually ratchets forward key material, as I understand). Some examples of where these clarifications should happen are: Line 1203 should instead say "each MLS UpdatePath message" The sections "Ratchet Tree Evolution" and "Sychronizing Views of the Tree" should describe the process of generating the key material for an message cc NAME
DirectPath corresponds to the graph theory term "direct path" of a leaf with the root
"Direct path" is still a thing, and the object in question here operates along a direct path, but I think "UpdatePath" indicates more clearly what it's doing.

Revised text:
above), then it MUST be populated.  Otherwise, the sender MAY omit the "path" field at its discretion.  <ins> If populating the "path" field: Create a UpdatePath using the new </ins> tree (which includes any new members).  The GroupContext for this operation uses the "group_id", "epoch", "tree_hash", and "confirmed_transcript_hash" values in the initial GroupContext object.  <ins> Assign this UpdatePath to the "path" field in the Commit. </ins>  <ins> Apply the UpdatePath to the tree, as described in </ins> synchronizing-views-of-the-tree.  Define "commit_secret" as the value "path_secret[n+1]" derived from the "path_secret[n]" value assigned to the root node.
Original text:
the ratchet tree the provisional GroupContext, to update the ratchet tree and generate the "commit_secret": <del> Apply the DirectPath to the tree, as described in </del>  synchronizing-views-of-the-tree, and store "key_package" at the Committer's leaf.

Reviewer comments:
This is a simple rename of to to be more descriptive of the action being performed by the message. I'll open a separate PR after this PIR is merged with updates to the spec where it uses when instead it should say (since not every actually ratchets forward key material, as I understand). Some examples of where these clarifications should happen are: Line 1203 should instead say "each MLS UpdatePath message" The sections "Ratchet Tree Evolution" and "Sychronizing Views of the Tree" should describe the process of generating the key material for an message cc NAME
DirectPath corresponds to the graph theory term "direct path" of a leaf with the root
"Direct path" is still a thing, and the object in question here operates along a direct path, but I think "UpdatePath" indicates more clearly what it's doing.

Revised text:
the ratchet tree the provisional GroupContext, to update the ratchet tree and generate the "commit_secret":  <ins> Apply the UpdatePath to the tree, as described in </ins> synchronizing-views-of-the-tree, and store "key_package" at the Committer's leaf.
Original text:
A key package that is prepublished by a client, which other clients can use to introduce the client to a new group. <del> A long-lived signing key pair used to authenticate the sender of a message. </del>  Terminology specific to tree computations is described in ratchet- trees.

Reviewer comments:
Rotating keys is important and in some cases, Signature Keys are not going to be very "long-term". Instead they're going to be rotated periodically. I thus propose we simply remove the assumption that Signature Keys are of a "long-term" nature (or otherwise "long-lived"). The second change in this PR is that I added a few words indicating explicitly that the identity must not change when updating a KeyPackage.

Revised text:
A key package that is prepublished by a client, which other clients can use to introduce the client to a new group.  <ins> A signing key pair used to authenticate the sender of a message. </ins> Terminology specific to tree computations is described in ratchet- trees.
Original text:
Provider (SP) as described in I-D.ietf-mls-architecture.  In particular, we assume the SP provides the following services: <del> A long-term signature key provider which allows clients to authenticate protocol messages in a group. </del>  A broadcast channel, for each group, which will relay a message to all members of a group.  For the most part, we assume that this

Reviewer comments:
Rotating keys is important and in some cases, Signature Keys are not going to be very "long-term". Instead they're going to be rotated periodically. I thus propose we simply remove the assumption that Signature Keys are of a "long-term" nature (or otherwise "long-lived"). The second change in this PR is that I added a few words indicating explicitly that the identity must not change when updating a KeyPackage.

Revised text:
Provider (SP) as described in I-D.ietf-mls-architecture.  In particular, we assume the SP provides the following services:  <ins> A signature key provider which allows clients to authenticate protocol messages in a group. </ins> A broadcast channel, for each group, which will relay a message to all members of a group.  For the most part, we assume that this
Original text:
as well as providing a public key that others can use for key agreement.  The client's signature key can be updated throughout the lifetime of the group by sending a new KeyPackage with a new <del> signature key; the new signature key MUST be validated by the </del>  authentication service. When used as InitKeys, KeyPackages are intended to be used only once

Reviewer comments:
Rotating keys is important and in some cases, Signature Keys are not going to be very "long-term". Instead they're going to be rotated periodically. I thus propose we simply remove the assumption that Signature Keys are of a "long-term" nature (or otherwise "long-lived"). The second change in this PR is that I added a few words indicating explicitly that the identity must not change when updating a KeyPackage.

Revised text:
as well as providing a public key that others can use for key agreement.  The client's signature key can be updated throughout the lifetime of the group by sending a new KeyPackage with a new  <ins> Credential.  However, the identity MUST be the same in both Credentials and the new Credential MUST be validated by the </ins> authentication service. When used as InitKeys, KeyPackages are intended to be used only once
Original text:
creator, because they are derived from an authenticated key exchange protocol.  Subsequent leaf keys are known only by their owner. <del> Note that the long-term signature keys used by the protocol MUST be distributed by an "honest" authentication service for clients to authenticate their legitimate peers. </del>  14.2.

Reviewer comments:
Rotating keys is important and in some cases, Signature Keys are not going to be very "long-term". Instead they're going to be rotated periodically. I thus propose we simply remove the assumption that Signature Keys are of a "long-term" nature (or otherwise "long-lived"). The second change in this PR is that I added a few words indicating explicitly that the identity must not change when updating a KeyPackage.

Revised text:
creator, because they are derived from an authenticated key exchange protocol.  Subsequent leaf keys are known only by their owner.  <ins> Note that the signature keys used by the protocol MUST be distributed by an "honest" authentication service for clients to authenticate their legitimate peers. </ins> 14.2.