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

[Ben Laurie]

On 17 April 2014 22:03, Daniel Kahn Gillmor <dkg at fifthhorseman.net> wrote:
> 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?

I don't get why sending multiple times comes into it - you send it, it
gets ordered, then you display it.

This does present a UI problem, though - your messages are not
displayed until some time later (I guess they can sit in a stack
somewhere in the meantime, tho).