Original text:
A signed object describing a client's identity and capabilities, and including a hybrid public-key encryption (HPKE I-D.irtf-cfrg- <del> hpke) public key that can be used to encrypt to that client. A key package that is prepublished by a client, which other clients can use to introduce the client to a new group. </del>  A signing key pair used to authenticate the sender of a message. messages directly, while in reality they would be sent encapsulated in MLSPlaintext or MLSCiphertext objects. <del> Before the initialization of a group, clients publish InitKeys (as KeyPackage objects) to a directory provided by the Service Provider. </del>  When a client A wants to establish a group with B and C, it first initializes a group state containing only itself and downloads 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 KeyPackage objects in the leaves of <del> the tree (including the InitKeys used to add new members). </del>  To disambiguate different signatures used in MLS, each signed value is prefixed by a label as shown below: along with an "endpoint_id" that, combined with the client's identity, serve to uniquely identify a client in a group. <del> When used as InitKeys, KeyPackages are intended to be used only once and SHOULD NOT be reused except in case of last resort.  (See initkey-reuse).  Clients MAY generate and publish multiple InitKeys to support multiple ciphersuites. </del>  The value for hpke_init_key MUST be a public key for the asymmetric encryption scheme defined by cipher_suite, and it MUST be unique In this process, the joiner sends a new "init_secret" value to the group using the HPKE export method.  The joiner then uses that <del> "init_secret" with information provided in the GroupInfo and an external Commit to initialize their copy of the key schedule for the new epoch. </del>  Members of the group receive the "kem_output" in an ExternalInit proposal and preform the corresponding calculation to retrieve the "init_secret" value. <del> In both cases, the "info" input to HPKE is set to the GroupInfo for the previous epoch, encoded using the TLS serialization. </del>  8.2. to encrypt or decrypt a message. Post-compromise security is also provided for new groups by members <del> regularly generating new InitKeys and uploading them to the Delivery Service, such that compromised key material won't be used when the member is added to a new group. </del>  15.4. <del> InitKeys are intended to be used only once.  That is, once an InitKey has been used to introduce the corresponding client to a group, it SHOULD be deleted from the InitKey publication system.  Reuse of InitKeys can lead to replay attacks. </del>  <del> An application MAY allow for reuse of a "last resort" InitKey in order to prevent denial of service attacks.  Since an InitKey is </del>  needed to add a client to a new group, an attacker could prevent a client being added to new groups by exhausting all available <del> InitKeys. </del>  15.5.

Reviewer comments:
Complete the renaming of InitKeys -> KeyPackages; and GroupInfo -> PublicGroupState
Comment by NAME Hmmm :P
Cf. RFC 8446 We could provide some more citations to the analyses that are now in the literature if you think that would help.
CC NAME NAME NAME for citations
They are also in this architecture document PR: URL
Oh good, I'll just add a citation over to mls-architecture.

Revised text:
A signed object describing a client's identity and capabilities, and including a hybrid public-key encryption (HPKE I-D.irtf-cfrg-  <ins> hpke) public key that can be used to encrypt to that client, and 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. messages directly, while in reality they would be sent encapsulated in MLSPlaintext or MLSCiphertext objects.  <ins> Before the initialization of a group, clients publish KeyPackages to a directory provided by the Service Provider. </ins> When a client A wants to establish a group with B and C, it first initializes a group state containing only itself and downloads 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 KeyPackage objects in the leaves of  <ins> the tree (including those used to add new members). </ins> To disambiguate different signatures used in MLS, each signed value is prefixed by a label as shown below: along with an "endpoint_id" that, combined with the client's identity, serve to uniquely identify a client in a group.  <ins> KeyPackages are intended to be used only once and SHOULD NOT be reused except in case of last resort.  (See keypackage-reuse). Clients MAY generate and publish multiple KeyPackages to support multiple ciphersuites. </ins> The value for hpke_init_key MUST be a public key for the asymmetric encryption scheme defined by cipher_suite, and it MUST be unique In this process, the joiner sends a new "init_secret" value to the group using the HPKE export method.  The joiner then uses that  <ins> "init_secret" with information provided in the PublicGroupState and an external Commit to initialize their copy of the key schedule for the new epoch. </ins> Members of the group receive the "kem_output" in an ExternalInit proposal and preform the corresponding calculation to retrieve the "init_secret" value.  <ins> In both cases, the "info" input to HPKE is set to the PublicGroupState for the previous epoch, encoded using the TLS serialization. </ins> 8.2. to encrypt or decrypt a message. Post-compromise security is also provided for new groups by members  <ins> regularly generating new KeyPackages and uploading them to the Delivery Service, such that compromised key material won't be used when the member is added to a new group. </ins> 15.4.  <ins> KeyPackages are intended to be used only once.  That is, once a KeyPackage has been used to introduce the corresponding client to a group, it SHOULD be deleted from the KeyPackage publication system. Reuse of KeyPackages can lead to replay attacks. </ins>  <ins> An application MAY allow for reuse of a "last resort" KeyPackage in order to prevent denial of service attacks.  Since a KeyPackage is </ins> needed to add a client to a new group, an attacker could prevent a client being added to new groups by exhausting all available  <ins> KeyPackages. </ins> 15.5.