[messaging] Message order in group chat (attempt at summary)

[Ximin Luo]

On 18/04/14 16:42, Trevor Perrin wrote:
>  (3) This could be handled by either displaying the partial order, or
> - when two messages are sent at roughly the same time - by accepting
> one message, rejecting the other, and requiring the rejected user to
> explicitly resend.  I liked Tom Ritter's UI for displaying partial
> order [1].  I share dkg's suspicion that the protocol complexity and
> UI impact of reject/resend are worse than displaying the partial order
> [2].
> 

There are some nice properties to aim for when one is developing an algorithm that turns a partial order (things don't get misinterpreted) into a linear order (nicer for users):

- static order (you don't need to redraw the UI later)
- globally consistent (the same order appears for everyone)

Unfortunately, achieving both seems infeasible (without awkward strategies like holding back messages even though they are perfectly OK to display).

Say you have the following partial order:

  O
 / \
A   B

Any canonical linear ordering will turn this into O-A-B or O-B-A. Without loss of generality, assume the former.

But if a user doesn't receive A for a long time, then his UI is forced to display O-B.

So, some re-drawing will have to happen. Alternatively, one could:

a) reject message A. But then this needs to be communicated to the sender of A, and to everyone else.
b) delay displaying 0-B until we are sure no messages will be received in the meantime. But:
  - if you are only "slightly" sure, you are just delaying the problem
  - if you are "certainly" sure, e.g. if you receive messages from everyone else that points to B, this will cause a huge delay and be very bad UX

X

-- 
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 880 bytes
Desc: OpenPGP digital signature
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20140426/280fd19b/attachment.sig>