Changes

Np1sec/SenderKeys

816 bytes added, 9 years ago
/* Causal order */ a single parent is not enough; add an explicit per-member sequence number and explain why
== Causal order ==
Some (all?) user-sent messages specify a "parent" sequence number which is the last message the user received before sending it. Note: 
* If Alice sends messages (A,B) in a row, A will not be B's parent unless Alice waits till A is received back from the server.
* The parent of a message is different from the "previous" message in the server's ordering, e.g. in a "simultaneous send" case two messages will have the same parent.
To prevent the server re-ordering (A, B) when they have the same parent, each message also includes an explicit own-sequence-number, incremented by the client themselves. We must enforce a few invariants. For every pair of messages A, B: * ownseqnum(A) &le; ownseqnum(B) <=> seqnum(A) &le; seqnum(B) <=> seqnum(parent(A)) &le; seqnum(parent(B) In practice, and because currently we implicitly allocate seqnums, for each incoming message m we only need to check: * let p be the latest message received from the same sender (of m). then, check that:** ownseqnum(p) == ownseqnum(m) + 1** seqnum(parent(p)) &le; seqnum(parent(m))* if p doesn't exist, then instead check that ownseqnum(m) == 0 Due to server ordering, the sender of message i must have seen allmessages from with seqnum between 0...parent(i's ), as well as all messages m with seqnum between parent(i)...i where ownseqnum(m) &le; ownseqnum(i). Thus, every user-sent message i has a membership set, determined by the JOIN / USER_LEFT messages from 0...i's parent.
== Transcript hashes ==
42
edits