[messaging] Minimal requirements for group chat

[Geoffroy Couprie]

Hi,


On Thu, Apr 17, 2014 at 1:32 AM, Ximin Luo <infinity0 at pwned.gg> wrote:

> On 16/04/14 23:38, Geoffroy Couprie wrote:
> >
> > Le 17 avr. 2014 00:27, "Daniel Kahn Gillmor" <dkg at fifthhorseman.net<mailto:
> dkg at fifthhorseman.net>> a écrit :
> >>
> >> On 04/16/2014 06:19 PM, Geoffroy Couprie wrote:
> >> > A git-like scheme with an elected master could make the transcript
> totally
> >> > ordered. Basically, all the peers would receive the messages and
> still keep
> >> > them in an unstaged area, partially ordered so still useful for the
> UI.
> >> > Then the master would chime in and provide the definite  message
> order,
> >> > kind of like a merge in git. The peers then reorder their transcript
> >> > accordingly.
> >>
> >> a merge in git does not produce a total order; i don't think this
> >> proposal will work the way you think.
> >
> > How so? In that scheme, the master defines clearly the order (even if it
> is not the absolutely exact time based order).
> >
>
> Could you offer some more details? There are several things aren't
> considered in your short description.
>
I'm sorry, I wrote that in a hurry on my phone, and could not get back to
this in the meantime. I see the subject has been discussed at length, but I
can still provide the reasoning behind this idea.

Causal ordering works, but you need to keep a graph of essages and their
relations, and you may not have the exact same transcript as the other
participants, except if you spend a significant time to obtain a consensus
and regularly "reset" the causality graph.

The git merge idea is like a project with contributors: anybody can see the
patch and read them, but the project's developer decides which one is
merged first. If the developer is not nice, people fork the project. Here,
they elect a new master. This tends to minimize messages compared to
distributed consensus systems: after a certain number of messages, the
master merges a few of them (or even only one) and broadcasts the new
"head".


>
> - when would it be appropriate for the master to run this algorithm? what
> if he receives something "in the middle", after he has already decided the
> order?
>
if he receives something in the middle, you have to strategies: you can
have a rebase or a merge. Since rewriting history is not a good idea in
this context, merging (ie, a commit with two or more parents) is feasible.


> - how would others display the "unstaged" items in the meantime?
>
Some kind of background color for unconfirmed messages, maybe?


>
> I also don't think a merge is analogous to your scheme. Merges are done by
> clients themselves, and form part of the partial order, rather than turning
> it into a linear order.
>
> >>
> >> I don't think a partial order is a bad thing, though.  a partial order
> >> reflects the actual state of a distributed conversation; there's a
> >> reason that mail user agents have traditionally offered a threaded view.
> >
> > The point is to get clients to agree on a transcript. Reflecting that
> transcript in the UI would be confusing since it would incur reodering.
> There could be a way to alert the user, though.
> >>
> >>         --dkg
> >>
>
> --
> GPG: 4096R/1318EFAC5FBBDBCE
> git://github.com/infinity0/pubkeys.git
>
>
> _______________________________________________
> Messaging mailing list
> Messaging at moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/messaging
>
>
Best regards,

Geoffroy Couprie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20140418/7ca616a3/attachment.html>