[messaging] UI problems with forced total ordering [was: Re: Minimal requirements for group chat]

[Daniel Kahn Gillmor]

On 04/17/2014 04:25 PM, Joseph Bonneau wrote:
> There appears to be a tension between UI from protocol complexity here. We
> can imagine designing a simple protocol that requires a baroque UI with
> messages threading and rejoining, or a very complicated protocol that
> allows a simple UI (linearized messages).
> 
> Personally I'd lean towards the latter approach. 

I have an ill-formed worry about serious UI problems with the latter
(enforced linearized) approach.  hopefully the explanation below makes
some sense:

I suspect that the complicated protocol for linearization will incur
some level of latency for message distribution.  This latency in turn
will make it so messages are displayed to the user after some delay,
quite possibly after they've already been writing the message they want
to send.

If the linearizing protocol requires clients to wait and retry to claim
the next sequence number during periods of message contention, the
obvious way to do this is automated re-tries, rather than hassling the
user each time their message gets bumped.

however, automatic re-tries pollute the meaning of the ordering that
linearization tries to produce.  In particular, if the user isn't able
to indicate to the UI which messages they read before writing the
message (which ones are the "parents" of a given message), then they
become vulnerable to the "ice cream" attack just by virtue of message
timing and automatic retries.

I do understand that partial ordering data model (which more closely
matches what the users actually saw when they were producing their
messages) entails UI difficulties on message display.

But i think any sort of forced linearization presents a different set of
UI difficulties on message creation and sending that seem likely to be
worse.  Do any of the advocates of strict linearization have a proposed
solution to this UI issue?  How do you avoid hassling the user about
sending any given message multiple times when the conversation is
flowing quickly, and still enforce a semantically meaningful total
ordering that isn't just a crapshoot for each user that might
misrepresent what they're replying to?

	--dkg

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