[messaging] Group messaging consistency under resource constraints

[Ximin Luo]

On 06/10/14 22:29, Trevor Perrin wrote:
> So you're arguing it's a desirable UX if out-of-order messages are not
> displayed until their ancestors have been displayed, and that this is
> generally achievable since clients can use a retransmit mechanism to
> get any lost messages.
> 
> I note that in asynchronous messaging (email, text messaging) you
> can't assume other parties are online to do retransmits, so you're
> assuming there's some server cacheing the ciphertexts that's able to
> do this.
> 

Not necessarily - other members that are online can retransmit ciphertexts on behalf of the original author. A server is only *needed* in the case that *no-one else* is online, though it might improve performance in the other cases.

> Anyways, this is partly just a UX question.  Are there existing
> widespread messaging systems that work this way (delay message display
> until causal ancestors arrive)?  Most things I'm aware of simply
> display messages when they arrive.
> 

"Partly just"? :p

If one doesn't care about consistency of history, it's fine to just display messages immediately as they arrive. If one does care about it, then you can't. Or at least, I believe not - and nobody has proposed a system that does so.

I was trying to describe why I think this, using precise language rather than vague summaries, so that a coherent discussion can actually form and move forward. I appreciate it's a lot to read, but I think it's useful for people to grasp the problem.

I do describe other options where one *can* display messages immediately and get a certain form of consistency ("single-message consistency"). It depends on what one thinks is a suitable security property, and what resource constraints there are.

TCP delays packets until missed packets with earlier sequence numbers arrive...

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: 819 bytes
Desc: OpenPGP digital signature
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20141006/8ae3a5a8/attachment.sig>