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.
This is a quality mailing list. :-) On Thu, Mar 12, 2015 at 7:39 AM, Ximin Luo <[email protected]> wrote: > On 11/03/15 19:59, Jeff Burdges wrote: > > > > 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. > > > > 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. > > > 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. > > > > 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. > > > 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. > > > > 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. > > >> 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. > > > > 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. > > > > 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? > > X > > -- > GPG: 4096R/1318EFAC5FBBDBCE > git://github.com/infinity0/pubkeys.git > _______________________________________________ > Messaging mailing list > [email protected] > https://moderncrypto.org/mailman/listinfo/messaging >
_______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
