[messaging] Merging in partially-ordered private group chats; was: Re: Matrix.org: Decentralized group chat
nadim at nadim.computer
Sat Mar 14 13:53:35 PDT 2015
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 <infinity0 at pwned.gg> 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?
> GPG: 4096R/1318EFAC5FBBDBCE
> Messaging mailing list
> Messaging at moderncrypto.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Messaging