Changes

Np1sec/incremental consistency

1,432 bytes added, 9 years ago
/* Definitions */ add a background section for context, and extend definitions
This builds on the server-dictated ordered transcript hashes currently mentioned in [[SenderKeys]].
 
== Background ==
 
To summarise: we assume the central server reliably delivers messages to everyone, including the original sender, in the same order. (Discussion of potential failures and recovery will be covered elsewhere.)
 
Each message has an implicit server-sequence-number ("seqnum"), a receive-parent ("recv-parent" or "parent") and a sender-sequence-number ("own-seqnum"). Semantics of these is covered elsewhere.
 
Once a message m is received from the server (including own messages sent), a "transcript-hash" may be calculated for it, that commits to that message and all previous messages in the server-dictated order. This consists of:
 
* all messages seen by the sender when they sent m, namely:
** "recv-parent" p and messages with seqnum earlier than p
** all messages sent by the same sender (messages with own-seqnum earlier than m)
* ''as well as'' all messages inserted by the server, into the server-ordering between p and m
 
When a new message is sent, the transcript-hash of its recv-parent is included with it.
== Definitions ==
* ''accepted'' means delivered locally, i.e. received, then decrypted-verified including parent hash checks; all causally-previous messages must already be accepted
** 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 consistency". 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.
== Consistency ==
42
edits