Original text:
Add extensions to ClientInitKeys for expiration and downgrade resistance (*)  draft-07 Initial version of the Tree based Application Key Schedule (*) messages encoded as MLSPlaintext objects in cases where it is necessary for the delivery service to examine such messages. <del> [[ OPEN-ISSUE: Should we allow multiple payloads to be packed into a single MLSPlaintext?  For example, this would allow a Proposal and a Commit to be sent at the same time, emulating the behavior of earlier verions of this protocol.  Or you could emulate Signal by always sending an Update and Commit when you send a message.  Syntactically, you would just define an MLSFrame that would encapsulate the select statement in the middle of MLSPlaintext, and have MLSPlaintext carry a vector of them. ]] </del> The remainder of this section describes how to compute the signature of an MLSPlaintext object and how to convert it to an MLSCiphertext object.  The overall process is as follows:

Reviewer comments:
This is a light optimization over , removing the overhead of extra encryptions/signatures in the case where proposal(s) and a commit are sent at the same time. Depends on
Unfortunately, using a single content type enforces the DS to order everything while there is no reason to force ordering of proposals made for the same epoch.
On conversation with NAME - Will keep content types separate, but allow Commit to have proposals.
Here's the Weekly Digest for : - - Last week 9 issues were created. Of these, 6 issues have been closed and 3 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :heart: , by :heart: , by :heart: , by :heart: , by :heart: , by :heart: , by :speaker: , by It received 2 comments. - - Last week, 13 pull requests were created, updated or merged. Last week, 3 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 10 pull requests were merged. :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by - - Last week there were 38 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there were 2 contributors. :bustinsilhouette: :bustin_silhouette: - - 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 .*
This allows combo operations -- multiple adds, moves, resyncs -- without having to worry about getting interrupted mid-operation.
On discussion at the interim 2019-01: It may be better to do not just throw a blind combo layer in here, but rather to have more operation types. That way, we can fully think through the implications of each one.
Deferred for further discussion on the mailing list.
Repurposing this issue for combo moves with regard to Proposals and Commits. We should cover the following cases: One or more Proposals with no Commit A Commit with no Proposals One or more Proposals bundled with a Commit It seems like something like the following would be appropriate: ... together with a requirement that at least one of them be populated.
At the interim: Commit must cover all Proposals in the same message As a result, if any of the Proposals are invalid, then the whole thing fails
Fixed in
Good to go modulo fix.

Revised text:
Add extensions to ClientInitKeys for expiration and downgrade resistance (*) <ins> Allow multiple Proposals and a single Commit in one MLSPlaintext (*) </ins> draft-07 Initial version of the Tree based Application Key Schedule (*) messages encoded as MLSPlaintext objects in cases where it is necessary for the delivery service to examine such messages.  The remainder of this section describes how to compute the signature of an MLSPlaintext object and how to convert it to an MLSCiphertext object.  The overall process is as follows: