On 10 Mar 2015, at 23:02, Ximin Luo <[email protected]> wrote: > On 10/03/15 19:36, Jeff Burdges wrote: >> There are three separate conversations from b’s perspective before the blue >> nodes, and a, c, and d only know about the ones they’re involved in, so some >> action by b precipitated the merges that occur in the blue nodes. > No, it's the same conversation. Different membership were initiated by > different people at different times. (Possibly I didn't explicitly define > enough members to be able do these concurrent operations, but you can just > imagine an extra constant set of members "xyz" at each node doing these > operations, which are the black edges labelled +a etc.)
Ahh yes! We could split b into x, y, and z who’re holding a conversation together and hold different opinions about a,c, and d, respectively, so d is unaware of the dislike x and y hold for c and a, respectively. If d were not present then you’d want ab and bc to merge into b probably. If d is present then network delay between x and y allows d to perform a different merge. Nice :) Imagine now that a and c left voluntarily, as opposed to being kicked. In this case, all b stop messaging them, but d continues. I donno if that’s too bad, well email causes this problem way more easily. If a and c recognized the thread they could leave it again, maybe automatically, but even manually works. I’m therefore wondering if the kick operation should be considered unnatural in the secure group chat context. Just focus on forking discussions instead. > One observation is that d mis-infers some merge edges to be "membership > operation" edges, because some other parents (of the blue nodes) are not > visible. Maybe this fact could help to work towards a solution. I donno if simple thread ban records would suffice since d could miss a whole kick war while offline. You could probably impose an ownership hierarchy that re-propagated it’s authoritative view, but that offends my anarchist sensibilities by creating property, and sounds odiously complex. We should seriously consider resolving this by abandoning the kick operation in favor of forking. Implement "kick” with the semantics of “ignore user” or “he goes or I go” aka “fork & drop original”. And client software should respect user bans established at thread creation time. I’ll reinterpret your scenario in this context : - x forks abc to ab dropping c, sending y an invite to the ab thread, and maybe dropping the abc to ayzc. - y forks abc to bc dropping a, sending x an invite to the bc thread, and maybe dropping the abc to axzc. Now x and y must both consider if they wish to remain with each other or a and b, respectively. If either x or y choose bc or ab, respectively, then they could refork down to a b thread. Also, ayzc and axzc both still contain conflicting pairs, so depending upon the “fork & drop original” operations semantics, we might wind up with only azc. Initially d was only invited to chat with b, but presumably that invite propagates into the forks since d was not banned, so d winds up with invites to ab and bc, and eventually the final b thread, along with ayzc and axzc. And d might retain an invite to message just the original b thread all along. All this sounds confusingly like email for d though since she doesn’t know what’s going on. In this case, there is at least a semantic reason for keeping the thread ban records around permanently, so d could learn those, which might help her client default to b over ayzc or axzc. Also, if those two made it to azc then d might face an interesting choice, but ideally he can treat it as a mostly separate conversation, like in email. Jeff _______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
