Changes
Dmitri moved page [[MpOTR/incremental consistency]] to [[Np1sec/incremental consistency]]: protocol renamed
** we assume a server-dictated ordering, so accepting a message at seqnum i means we have already accepted all messages j ≤ i.
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 consistencyfor ''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 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 ==
* if u did not send m, and they have not acked m by t+ACK_GRACE_INTERVAL, they should send an explicit-ack
* if m is not fully-acked (from their POV) by t+(2*BROADCAST_LATENCY)+ACK_GRACE_INTERVAL then issue a local UI warning. Cancel the warning if/when full-ack is reached later.
Case '''(b)''': when a member ''u'' wants to part, they send a "farewell" message ''m'':
* Everyone should explicit-ack ''m'' as soon as they receive it from the server.
** This 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, encrypted to everyone except ''u''.
* When ''m'' is fully-acked, ''u'' reaches consistency for all previous messages up to ''m'', and may leave.
* Messages that others send to ''u'' that are echoed back after ''m'', will not be acked by ''u''.
** ''u'' won't have a chance to reach consistency for 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 ===
