[messaging] Minimal requirements for group chat

[Ximin Luo]

On 17/04/14 12:03, Michael Rogers wrote:
> On 16/04/14 22:42, Ximin Luo wrote:
>> Extending this to dynamic groups is more tricky however, since one
>> needs to figure out what happens when join/part operations interact
>> with the partial-order. I can go in more detail, but the last time
>> I did so it didn't seem like anyone else was interested in the
>> problem.
> 
> For what it's worth, I'm definitely interested in hearing more about
> your partial ordering ideas - I just didn't have anything intelligent
> to say about them last time. :-) I do think though that it's worth
> separating the problems of ordering and membership management if we
> possibly can. Each of them looks to be a pretty hard problem in its
> own right.
> 

I agree with the benefits of separation; this engineering principle could be approached in multiple ways here:

a. Separate membership ops vs messaging into "phases". Phases themselves are totally-ordered wrt each other, but within a messaging phase, individual messages are partially-ordered wrt each other.

b. Form an abstract general model of what happens during a join/part operation (e.g. a GKE), and see how this may (or may not) interface with an abstract general partial-order scheme. Then, one can substitute specific implementations for the membership management vs ordering, separately, as long as they each fit the abstract model developed earlier.

(a) is indeed simpler, but you lose a lot of the benefits of partial order, especially if members come and go very often. (b) is what I'm looking into, and might be able to support more flexible join/part patterns, such as when two members each try to invite a guest, both in parallel.

BTW, whilst we're on the topic, here are some partially-ordered transcripts I generated not too long ago:

https://people.torproject.org/~infinity0/res/mpotr/

The sequence numbers represent the generated total-order; I did a topological order based on the receive-time (which is different for each recipient). Unfortunately though, dot doesn't respect these numbers in the generated layout.

X

-- 
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 880 bytes
Desc: OpenPGP digital signature
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20140417/0de8a0af/attachment.sig>