<div dir="ltr">Something I appreciate about this list is the identification of the theoretical problem, and then re-titling the thread to separate it from the application and allow for a more objective analysis.<div><br></div><div>This is a quality mailing list. :-)</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 12, 2015 at 7:39 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"><span>On 11/03/15 19:59, Jeff Burdges wrote:<br>
><br>
</span>> Just one possible approach : Allow forks as new threads with history pointers to other threads.  Allow add operations by anyone.  Allow leave operations, but not kick operations.  Allow ban request operations for non-members at thread creation time.<br>
><br>
<br>
At the moment, I am ignoring this idea of "allow", because I think it's at a separate layer. I am just trying to work out how to execute things (specifically, merging membership operations) assuming that they are allowed and agreed to by everyone. This simplifies the problem, and I believe that the feature of "allowing" can be added later. Already, as I mentioned before, there already exists some sense of "allow" - you can leave the session, or reverse the operation yourself after it happens.<br>
<br>
> We can produce exactly your scenarios with add and leave operations here, but the semantics is “damn that thread keeps sending me crap I need to leave again”, which might be automated, rather than “this obnoxious guy has a network of lag bots that makes it impossible for me to kick him” in the kick scenario.<br>
><br>
<br>
But what do you mean by "leave", here? In my own thoughts about "leave", after you "leave" the session, you can't talk to anyone else. Do you mean "fork into a thread without person X (that I dislike)"? I don't think my idea is susceptible to "can't kick X because he's offline" - the leave operation does not cryptographically depend on X, it's not hard to achieve this - this is a basic requirement of a secure "kick" operation of course.<br>
<br>
> Also, bans are quite clumsy in that they expose contact information to future members, so they actually violates your anonymity desire that motivates this whole discussion, but you might just fork rather than fork+ban on the first attempt if that’s an issue.<br>
><br>
<br>
Yes, I haven't even thought about "bans". At the very least, they could be implemented simply as per-client "auto-kick" rules. I think it's fine not to think about a ban operation currently.<br>
<br>
>> The thing is, d does not *necessarily* need to continue messaging a or c. I would like to figure out a merge algorithm, such that d .. would do exactly the same thing as b. Or, if this is impossible, then some other mechanism whereby d (doesn't have to do / is prevented from doing) something that's inconsistent with what b would do.<br>
><br>
> As I pointed out, “he goes or I go” aka "fork with ban plus leave” could provide d with a bd thread along with the option to join spurious thread like azc, etc, which I think is reasonable.<br>
><br>
<br>
But what happens if d *wants to* just "go with the flow of what everyone else is doing" - since the user doesn't want to think about partial-order branches caused by asynchronity, or making decisions about merges?<br>
<div><div><br>
X<br>
<br>
--<br>
GPG: 4096R/1318EFAC5FBBDBCE<br>
git://<a href="http://github.com/infinity0/pubkeys.git" target="_blank">github.com/infinity0/pubkeys.git</a><br>
_______________________________________________<br>
Messaging mailing list<br>
<a href="mailto:Messaging@moderncrypto.org" target="_blank">Messaging@moderncrypto.org</a><br>
<a href="https://moderncrypto.org/mailman/listinfo/messaging" target="_blank">https://moderncrypto.org/mailman/listinfo/messaging</a><br>
</div></div></blockquote></div><br></div></div>