Change:
Action item from Singapore: it seems better to specify directly in the message if we have an external sender instead of using reserved ranges.
Here's the Weekly Digest for : - - Last week 3 issues were created. Of these, 0 issues have been closed and 3 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :speaker: , by It received 1 comments. - - Last week, 7 pull requests were created, updated or merged. Last week, 2 pull requests were opened. :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 3 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there were 2 contributors. :bustinsilhouette: :bustinsilhouette: - - 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 .
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 .

Discussion:
messages encoded as MLSPlaintext objects in cases where it is necessary for the delivery service to examine such messages. <ins> External sender types are sent as MLSPlaintext, see external- proposals for their use. </ins> The remainder of this section describes how to compute the signature of an MLSPlaintext object and how to convert it to an MLSCiphertext <del> object.  The overall process is as follows: Gather the required metadata: Group ID </del> <ins> object for "member" sender types.  The steps are: </ins> <del> Epoch </del> <ins> Set group_id, epoch, content_type and authenticated_data fields from the MLSPlaintext object directly </ins> <del> Content Type </del> <ins> Randomly generate the sender_data_nonce field </ins> <del> Nonce </del> <ins> Identify the key and key generation depending on the content type </ins> <del> Sender index </del> <ins> Encrypt an MLSSenderData object for the encrypted_sender_data field from MLSPlaintext and the key generation </ins> <del> Key generation </del> <ins> Generate and sign an MLSPlaintextSignatureInput object from the MLSPlaintext object </ins> <del> Sign the plaintext metadata - the group ID, epoch, sender index, and content type - as well as the authenticated data and message content </del> <ins> Encrypt an MLSCiphertextContent for the ciphertext field using the key identified, the signature, and MLSPlaintext object </ins> <del> Randomly generate sender_data_nonce and encrypt the sender information using it and the key derived from the sender_data_secret </del> <ins> Decryption is done by decrypting the metadata, then the message, and then verifying the content signature. </ins> <del> Encrypt the content using a content encryption key identified by the metadata The group identifier, epoch, content_type and authenticated data fields are copied from the MLSPlaintext object directly.  The content encryption process populates the ciphertext field of the MLSCiphertext object.  The metadata encryption step populates the encrypted_sender_data field. Decryption follows the same step in reverse: Decrypt the metadata, then the message and verify the content signature. </del> <ins> The following sections describe the encryption and signing processes in detail. </ins> 8.1.

the sender_data_key from the keyschedule.  It is encoded as an object of the following form: <ins> MLSSenderData.sender is assumed to be a "member" sender type.  When constructing an MLSSenderData from a Sender object, the sender MUST verify Sender.sender_type is "member" and use Sender.sender for MLSSenderData.sender. </ins> The Additional Authenticated Data (AAD) for the SenderData ciphertext computation is its prefix in the MLSCiphertext, namely:

might propose to remove a member of a group has been inactive for a long time, or propose adding a newly-hired staff member to a group representing a real-world team.  Proposals originating outside the <del> group are identified by having a "sender" value in the range 0xFFFFFF00 - 0xFFFFFFFF. The specific value 0xFFFFFFFF is reserved for clients proposing that they themselves be added.  Proposals with types other than Add MUST NOT be sent with this sender index.  In such cases, the MLSPlaintext MUST be signed with the private key corresponding to the ClientInitKey in the Add message.  Recipients MUST verify that the MLSPlaintext carrying the Proposal message is validly signed with this key. The remaining values 0xFFFFFF00 - 0xFFFFFFFE are reserved for signer that are pre-provisioned to the clients within a group.  If proposals with these sender IDs are to be accepted within a group, the members of the group MUST be provisioned by the application with a mapping between sender indices in this range and authorized signing keys.  To ensure consistent handling of external proposals, the application MUST ensure that the members of a group have the same mapping and apply the same policies to external proposals. </del> <ins> group are identified by an "preconfigured" or "new_member" SenderType in MLSPlaintext. The "new_member" SenderType is used for clients proposing that they 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 ClientInitKey in the Add message. Recipients MUST verify that the MLSPlaintext carrying the Proposal message is validly signed with this key. The "preconfigured" SenderType is reserved for signers that are pre- provisioned to the clients within a group.  If proposals with these sender IDs are to be accepted within a group, the members of the group MUST be provisioned by the application with a mapping between these IDs and authorized signing keys.  To ensure consistent handling of external proposals, the application MUST ensure that the members of a group have the same mapping and apply the same policies to external proposals. </ins> An external proposal MUST be sent as an MLSPlaintext object, since the sender will not have the keys necessary to construct an