Changes
Dmitri moved page [[MpOTR/incremental consistency]] to [[Np1sec/incremental consistency]]: protocol renamed
Once ''m'' is fully-acked, ''u'' knows that everyone else has seen ''m'' and all messages before it. We'll call the process of gaining that knowledge, "reaching consistency for ''m''" (given context, ''m'' might be implicit). We don't have another mechanism for it, so henceforth we'll use "reach consistency" interchangeably with "reach full-ack", though strictly the former is a security property and the latter is a mechanism for achieving it.
An '''explicit-ack''' is a message with no other user content, that is sent solely for the purpose of declaring (via recv-parent) what the sender has seen. We'll make use of these to ensure consistency is reached in a timely manner, even if no-one wants to send a normal message (that contains user-level contents, and which is an '''implicit-ack''').
== Consistency ==
Case '''(b)''': when a member ''u'' wants to part, they send a "farewell" message ''m'':
* Everyone should explicit-ack this message ASAP''m'' as soon as they receive it from the server.** This message should ack may also bundle any cryptographic material needed for other members to agree on a key or keys that exclude ''u''. For example, in the SenderKeys scenario, this would contain the next-sender-key, to be used after u leaves, encrypted to everyone except ''u. This ensures old members can't read new messages even if they eavesdrop'.** (We could probably do something similar for group keys.)* When this message ''m'' is fully-acked, ''u gains '' reaches consistency for all previous messages up to ''m'', and may leave.** Other messages should be probably Messages that others send to ''u'' that are echoed back after ''m'', will not be discarded - acked by ''u ''.** ''u'' won't have a chance to verify their reach consistencyfor these messages, even if ''u'' receives them.** Others won't have a chance to check that ''u'' read them, though they may be able to check that everyone else did. But ''u'' may still read them in theory, since they were encrypted to ''u''.** In either case, communicating this meaning to the user, should be already covered by the same UI as for case (a). In the first case, ''u'' may shortcut the timeout and just issue the warning straight away, or alternatively not display those messages to the user at all.
* TBD: need to think about simultaneous parts
=== Parameters and properties ===
