<div><br></div><div><br></div><div>to my usage 1 / 2 client is a fair limitation of magic folder is working</div><div><br></div><div><br></div><div>i was just asking about the branch for it.</div><div>is it in master ? or in a special branch ?</div><div><br></div><div>to reactivate my network to have a try on it.<br></div><div><br></div><div><br></div><div><br></div><div><br></div><br><br>Le jeudi 12 novembre 2015, David Stainton <<a href="mailto:dstainton415@gmail.com">dstainton415@gmail.com</a>> a écrit :<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">actually we didn't finish implementing the two party conflict<br>
detection... but we *could* finish it... but why? i think we should<br>
just solve the harder problem instead.<br>
<br>
On Thu, Nov 12, 2015 at 2:34 PM, Freelab initiative<br>
<<a href="javascript:;" onclick="_e(event, 'cvml', 'freelab.cc@gmail.com')">freelab.cc@gmail.com</a>> wrote:<br>
> it is very great if magic folder are now working<br>
><br>
> 2 clients on same file is fair enough<br>
><br>
> we shall grab the last github to build to test this.<br>
> or we shall take any other build/repo ?<br>
><br>
><br>
> thanks<br>
><br>
> xavier<br>
><br>
><br>
> Le dimanche 8 novembre 2015, David Stainton <<a href="javascript:;" onclick="_e(event, 'cvml', 'dstainton415@gmail.com')">dstainton415@gmail.com</a>> a écrit<br>
> :<br>
>><br>
>> Agreed; If possible we'd like to first hear Daira's solution before we<br>
>> send Leif's.<br>
>> I'm also curious to hear Zooko's solution.<br>
>><br>
>> I've written a proposal document explaining Leif's solution.<br>
>> Hopefully later today Leif will apply more corrections to this document<br>
>> which is almost ready to be reviewed.<br>
>><br>
>> On Fri, Nov 6, 2015 at 6:55 PM, Zooko Wilcox-O'Hearn <<a href="javascript:;" onclick="_e(event, 'cvml', 'zookog@gmail.com')">zookog@gmail.com</a>><br>
>> wrote:<br>
>> > Dear folks:<br>
>> ><br>
>> > Context: “Magic Folders” is a new layer on top of Tahoe-LAFS which<br>
>> > implements Dropbox-like "auto-sync" behavior. It's super exciting!<br>
>> > Development of it was sponsored by Open Technology Fund. We've<br>
>> > finished implementing it, but now we're noticing some bugs and<br>
>> > limitations, and this is the biggest one I'm aware of right now.<br>
>> ><br>
>> > As David described in this comment:<br>
>> ><br>
>> > <a href="https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2551#comment:22" target="_blank">https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2551#comment:22</a><br>
>> ><br>
>> > The current design and implementation of Magic Folders only works if<br>
>> > you have no more than two clients attached to it. By "clients" I mean<br>
>> > here either two devices owned by the same user or two users each with<br>
>> > their own device — Tahoe-LAFS and Magic Folders are unaware of any<br>
>> > distinction between a separate human user with their own device versus<br>
>> > a separate client/node/process/device operated by the same human user.<br>
>> ><br>
>> > The problem is subtle, and I'm writing this letter mostly in order to<br>
>> > cement my own understanding of *why* the current design fails in the<br>
>> > 3-party (or more) case. Also in order to draw Daira's attention to it<br>
>> > and see what sort of fix she would suggest.<br>
>> ><br>
>> > Here is the section of the design doc about the problem of<br>
>> > distinguishing conflicts from overwrites pushed by your peer. We<br>
>> > whimsically named this problem the "Fire Dragons" problem.<br>
>> ><br>
>> ><br>
>> > <a href="https://tahoe-lafs.org/trac/tahoe-lafs/browser/docs/proposed/magic-folder/remote-to-local-sync.rst#fire-dragons-distinguishing-conflicts-from-overwrites" target="_blank">https://tahoe-lafs.org/trac/tahoe-lafs/browser/docs/proposed/magic-folder/remote-to-local-sync.rst#fire-dragons-distinguishing-conflicts-from-overwrites</a><br>
>> ><br>
>> > The goal of the Fire Dragon slaying protocol is to make it so that you<br>
>> > can reliably tell whether a given new version submitted to you by your<br>
>> > peer was derived from the most recent version that *you* created, or<br>
>> > if it was derived from a previous version than the most recent version<br>
>> > that you created. If your peer says that it was derived from the most<br>
>> > recent version that you created, then this means your peer is<br>
>> > instructing you to *overwrite* your most recent version with their new<br>
>> > version. If instead your peer says that it was derived from an earlier<br>
>> > version, then this means there is a *conflict*, where you and your<br>
>> > peer simultaneously made changes to the file.<br>
>> ><br>
>> > The way the current Fire Dragon slaying protocol attempts to track<br>
>> > this distinction is by including a slot with each upload called the<br>
>> > "last-downloaded record". When you receive a new version from someone<br>
>> > else, you inspect the last-downloaded record that accompanies that<br>
>> > version, and if it shows that the version they started from was the<br>
>> > most recent version you sent them, then you know it is an overwrite<br>
>> > [*], and if it isn't, then you know it is a conflict.<br>
>> ><br>
>> > Now here's the problem: this design assumes that you are the only<br>
>> > source of downloadable versions that they could have started with! But<br>
>> > if there's a *third* party, and they started with a download from that<br>
>> > third party, then with this design you will assume that they are<br>
>> > starting from an *earlier version from you*, when in fact they are<br>
>> > starting from a version from the third party, which might in turn have<br>
>> > been derived from the most recent version from you. (Or it might not<br>
>> > have — it might have been derived from a previous version from you.)<br>
>> ><br>
>> > Bottom line:<br>
>> ><br>
>> > 1. Magic Folders exists, and is awesome.<br>
>> > 2. It works fine if you have no more than 2 devices/users/endpoints<br>
>> > attached. (Or if no more than two of them are editing the same<br>
>> > document at the same time.)<br>
>> > 3. The current version doesn't work if more than 2 endpoints edit the<br>
>> > same file at the same time.<br>
>> ><br>
>> > I have an idea about how to fix this, but I'm not going to include it<br>
>> > in this note, because I want Daira to have a chance to think about the<br>
>> > problem and propose a fix before being biased by my proposed fix, and<br>
>> > I want Leif to have a chance to reply with his proposed fix (that he<br>
>> > attempted to explain to me at the Nuts & Bolts party today).<br>
>> ><br>
>> > Regards,<br>
>> ><br>
>> > Zooko<br>
>> ><br>
>> > [*] Except if there turns out to be an Earth Dragon — see the design<br>
>> > doc for details.<br>
>> > _______________________________________________<br>
>> > tahoe-dev mailing list<br>
>> > <a href="javascript:;" onclick="_e(event, 'cvml', 'tahoe-dev@tahoe-lafs.org')">tahoe-dev@tahoe-lafs.org</a><br>
>> > <a href="https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev" target="_blank">https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev</a><br>
>> _______________________________________________<br>
>> tahoe-dev mailing list<br>
>> <a href="javascript:;" onclick="_e(event, 'cvml', 'tahoe-dev@tahoe-lafs.org')">tahoe-dev@tahoe-lafs.org</a><br>
>> <a href="https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev" target="_blank">https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev</a><br>
</blockquote>