[messaging] Merging in partially-ordered private group chats; was: Re: Matrix.org: Decentralized group chat

[Nadim Kobeissi]

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?
>
> X
>
> --
> GPG: 4096R/1318EFAC5FBBDBCE
> git://github.com/infinity0/pubkeys.git
> _______________________________________________
> Messaging mailing list
> Messaging at moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/messaging
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20150314/b6bf6f79/attachment.html>