On 17 April 2014 22:03, Daniel Kahn Gillmor <[email protected]> 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). _______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
