<div dir="ltr">Hi,<br><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Apr 17, 2014 at 1:32 AM, Ximin Luo <span dir="ltr"><<a href="mailto:infinity0@pwned.gg" target="_blank">infinity0@pwned.gg</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 16/04/14 23:38, Geoffroy Couprie wrote:<br>
><br>
> Le 17 avr. 2014 00:27, "Daniel Kahn Gillmor" <<a href="mailto:dkg@fifthhorseman.net">dkg@fifthhorseman.net</a> <mailto:<a href="mailto:dkg@fifthhorseman.net">dkg@fifthhorseman.net</a>>> a écrit :<br>
<div class="">>><br>
>> On 04/16/2014 06:19 PM, Geoffroy Couprie wrote:<br>
>> > A git-like scheme with an elected master could make the transcript totally<br>
>> > ordered. Basically, all the peers would receive the messages and still keep<br>
>> > them in an unstaged area, partially ordered so still useful for the UI.<br>
>> > Then the master would chime in and provide the definite message order,<br>
>> > kind of like a merge in git. The peers then reorder their transcript<br>
>> > accordingly.<br>
>><br>
>> a merge in git does not produce a total order; i don't think this<br>
>> proposal will work the way you think.<br>
><br>
> How so? In that scheme, the master defines clearly the order (even if it is not the absolutely exact time based order).<br>
><br>
<br>
</div>Could you offer some more details? There are several things aren't considered in your short description.<br></blockquote><div>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.<br>
<br></div><div>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.<br>
<br></div><div>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".<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
- 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?<br></blockquote><div>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.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- how would others display the "unstaged" items in the meantime?<br></blockquote><div>Some kind of background color for unconfirmed messages, maybe?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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.<br>
<div class="im HOEnZb"><br>
>><br>
>> I don't think a partial order is a bad thing, though. a partial order<br>
>> reflects the actual state of a distributed conversation; there's a<br>
>> reason that mail user agents have traditionally offered a threaded view.<br>
><br>
> 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.<br>
>><br>
>> --dkg<br>
>><br>
<br>
</div><div class="HOEnZb"><div class="h5">--<br>
GPG: 4096R/1318EFAC5FBBDBCE<br>
git://<a href="http://github.com/infinity0/pubkeys.git" target="_blank">github.com/infinity0/pubkeys.git</a><br>
<br>
</div></div><br>_______________________________________________<br>
Messaging mailing list<br>
<a href="mailto:Messaging@moderncrypto.org">Messaging@moderncrypto.org</a><br>
<a href="https://moderncrypto.org/mailman/listinfo/messaging" target="_blank">https://moderncrypto.org/mailman/listinfo/messaging</a><br>
<br></blockquote><div><br></div><div>Best regards,<br><br></div><div>Geoffroy Couprie<br></div></div></div></div></div>