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
