[messaging] Group messaging consistency under resource constraints

[Andy Isaacson]

On Tue, Oct 07, 2014 at 12:41:15AM +0100, Ximin Luo wrote:
> On 07/10/14 00:37, Andy Isaacson wrote:
> > On Mon, Oct 06, 2014 at 11:07:13PM +0100, Ximin Luo wrote:
> >> 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.
> > 
> > That's a false dichotomy.  Systems frequently display messages as they
> > arrive, sometimes with an indication of missing history and sometimes
> > without; and systems frequently insert messages in the history when they
> > arrive, generally with some indication that this has happened.
> 
> Sure, prove me wrong. :) I have explained what I understand of the
> problem in the first post, maybe it will be useful for that effort.
> 
> > And then there's the IRC model where messages just get displayed as they
> > arrive, and the user can deal with any lossage.
> > 
> > Systems that do variations on this include
> > 
> > LINE
> > Hipchat
> > Slack
> > 
> > As it turns out, very few people anymore are using thermal paper
> > consoles http://www.columbia.edu/cu/computinghistory/la36.html and
> > UIs can go back and correct history when we learn more detail.
> 
> Do any of these systems try to achieve group consistency of history,
> under resource constraints?

Obviously not, since these systems all have a completely trusted server.

I'm simply referring to the UX -- these systems provide a visual
history with visual indications of inconsistency, generally just a
warning icon where there's a missing message, and inserting messages in
the correct order when they arrive out-of-order.  The UX is well proven,
lots of general purpose computer users use these systems every day and
find the UX comprehensible.

Of course a malicious-client-tolerant distributed cryptographic system
will have a somewhat different set of failure modes to convey to the
user, but I'm just responding to the argument that it is impossible to
design a UX to handle even the simplest case of transcript inconsistency
(of a missing message in the history).  The existing modern centralized
chat systems handle this case OK and users find it acceptable.  Let's
achieve feature parity in a distributed system and get on with finding
and solving the actually hard problems.

The first actually hard problem that we get to attack is, what happens
when Bob sends m1 to Alice and m2 to Carlos, then Alice replies m3.
What does Carlos see, and how can he prove it?  But there are more hard
problems than just that one. A taxonomy of transcript consistency errors
would be useful...

-andy