A message m is "fully-acked" (from the POV of a given member u) iff, for all recipients r, u has accepted a message by r whose sender-parent is >= m's seqnum.* "recipients" possibly includes u, but certainly excludes m's sender* "accepted" means delivered locally, i.e. received, then decrypted-verified including parent hash checks; all previous messages must already be accepted= Definitions ==

* when a member ''recipients'' possibly includes u wants to part, they send a "farewell" message but certainly excludes m:'s sender** everyone should explicit-ack this message ASAP*** this message should contain the next-sender-key''accepted'' means delivered locally, to be used after u leaves, encrypted to everyone except ui. (Hopefully this addresses the concern Joe brought upe.)*** could probably do something similar for group keys** when this message is fullyreceived, then decrypted-acked, u gains consistency for verified including parent hash checks; all previous messages up to m, and may leave*** other messages should must already be probably be discarded, u won't have a chance to verify their consistency.** TBD: need to think about simultaneous partsaccepted

== Consistency == When a member u wants to part, they send a "farewell" message m: * everyone should explicit-ack this message ASAP** this message should contain the next-sender-key, to be used after u leaves, encrypted to everyone except u. (Hopefully this addresses the concern Joe brought up.)** could probably do something similar for group keys* when this message is fully-acked, u gains consistency for all previous messages up to m, and may leave** other messages should be probably be discarded, u won't have a chance to verify their consistency.* TBD: need to think about simultaneous parts When a member u accepts a non-explicit-ack message m at time t** if u did not send m, and they have not acked m by t+MAX_GRACE, they should send an explicit-ack** if m is not fully-acked (from their POV) by t+(2*MAX_RTT)+(k*MAX_GRACE) (k slightly > 1) then issue a local UI warning. Cancel the warning if/when full-ack is reached later. === Parameters and properties ===

Trevor was also worried about Ensure that messages appearing in wildlyreceived out-of-different positions in a linear order, due are highly visible to malicious server delaying messages. I didn't like the MAX_RTD idea for various reasons; here is an alternative:user.

A message m is *rejected* ''out-of-order'' if its sender-parent's seqnum is < (m's seqnum - MAX_UNSYNC_COUNT)* MAX_UNSYNC_COUNT may either be constant, or a linear function of the number of members, TBD.

Seqnums are re-defined to ignore *rejected* messagesMAX_UNSYNC_COUNT may either be constant, or a linear function of the number of members, TBD.

This definition These messages should hopefully be globally consistent (or else transcript consistency breaks) so it's easier to reason abouthighlighted in some way in the UI that is not too severe. They are still valid messages, and the sender of the rejected message can detect this reliably and offer the user should just be informed that they refer to re-sendolder context.

It This definition is harder to be sure that time-based rejection conditions would be globally-consistent. Of course (or else transcript consistency still breaks in that case, but ) so it is *more likely* 's easier to breakreason about, and I think reducing this chance would be betterthe warning is simpler to explain than MAX_RTD.