[messaging] Minimal requirements for group chat

Wed Apr 16 14:42:49 PDT 2014

I missed the part where Michael said "Group membership is fixed for the duration of the chat". In this case yes, partial ordering is very straightforward, and works very similarly to a git history graph. So I would very much suggest to just follow the scheme Moxie mentions below. The UI ordering issue is tricky though - perhaps Moxie you can elaborate on how TextSecure "linearizes" things?

Note that by "counter", (I assume) this means counter from the sender's point of view - you have a counter for each message you send, and you increment this and send it with each message (so it forms part of the identity of the message.) As opposed to, the recipients keep separate counters of how many messages they receive from the same sender, which will be subjective for each message.

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.

X

On 16/04/14 21:58, Moxie Marlinspike wrote:
> 
> TextSecure supports group messaging.  I've been meaning to write up a
> blog post about it, but if I understand correctly, you're mostly asking
> about transcript consistency in a "pairwise group" model.
> 
> We believe this can be as simple as including the truncated hash of the
> (sender, plaintext, counter) tuple for the last messages seen with every
> message sent.
> 
> This allows each client to build a view of a message transcript that's
> reminiscent of a git commit log, where each message is a commit.  One
> could imagine visualizing this like an old-school email client
> visualizes conversation threads, which would make transcript
> inconsistencies and "reply intent" clear.  That way if Bob sends a
> message to everyone that says "Who wants to kill the president?" except
> Alice, who Bob instead sends "Who wants to get some ice cream?," when
> Alice responds "I do, how about this afternoon!" -- it'd be clear to
> everyone in the conversation that Alice is responding to something they
> didn't see.
> 
> Unfortunately, that type of UI isn't really possible on mobile devices,
> and even desktop communication apps are moving away from those types of
> threaded views.  For now, TextSecure conversations are "linearized," and
> the way to *display* transcript consistency for untrusted groups like
> these remains an open UI/UX question for us.
> 
> But at least at the protocol level, it's pretty simple even in an
> asynchronous environment.
> 
> - moxie
> 
> 
> On 04/16/2014 08:36 AM, Michael Rogers wrote:
> Hi all,
> 
> I've been thinking about ways to cut down the forward-secret group
> chat problem to a manageable size. I'm looking for a core problem
> that's big enough to be worth solving, but small enough to be solved;
> then we can think up some solutions, prototype them, and see whether
> we can extend them to solve bigger problems.
> 
> Here's a suggestion for a core problem we could start with:
> 
> * Small groups, so O(n^2) bandwidth or processing cost is OK
> * Group membership is fixed for the duration of the chat
> * All members know the membership of the group somehow
> * All members have pairwise OTR connections to all other members
> * We accept that any member can prevent the chat from making progress
> 
> Goals:
> 
> * Messages are forward secret
> * Messages can be authenticated by group members
> * Messages are repudiable
> * All members agree about which messages are part of the chat
> * All members agree about the order of the messages in the chat
> * Messages can only be added to the end of the chat
> 
> In some ways this is an easier problem than mpOTR, but I think a tool
> that met these goals would be worth having. As far as I know, that
> tool doesn't exist yet.
> 
> Here's a sketch of one possible approach to solving this problem. It's
> basically an append-only log with two-phase commit. Messages aren't
> shown in the UI until they've been committed. (If used over a
> high-latency transport there would need to be some intermediate UI
> state for messages that had been sent but not yet committed.)
> 
> Each member of the group has a copy of the log and a staging area for
> uncommitted messages. Messages in the log are numbered sequentially,
> and each message has a retransmission counter. When a member wants to
> send a message, she assigns the first unused sequence number to the
> message, stages the message, and sends a copy of the numbered message
> to every other member. Each member who receives the message stages it
> and sends an ack to every other member, including the author. The ack
> includes a hash over the author's identity, the sequence number, the
> retransmission counter and the content, so everyone knows whether
> everyone else is acking the same message. Each member who receives an
> ack from every other member except the author commits the staged
> message to the log.
> 
> If a member receives a message with the same sequence number as a
> staged message, she sends a nack to every other member and discards
> both messages. Anyone who receives a nack for a staged message
> discards the message, except the author, who unstages the message. If
> two or more authors try to send messages with the same sequence
> number, every colliding message will be nacked by at least one member,
> unstaged by its author and discarded by everyone else, and the
> sequence number will remain unused. Each author waits for a random
> interval and then resends her message with an incremented
> retransmission counter and the first unused sequence number, which may
> be the same as before, or higher if another message has been committed
> in the meantime.
> 
> The retransmission counter prevents confusion between acks or nacks
> for different transmissions of the same message. The retransmission
> interval increases exponentially to avoid repeated collisions.
> 
> What do you reckon - is this a problem worth tackling, and does this
> solution seem sound?
> 
> Cheers,
> Michael
>> _______________________________________________
>> Messaging mailing list
>> Messaging at moderncrypto.org
>> https://moderncrypto.org/mailman/listinfo/messaging
>>
>>
> 

-- 
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/20140416/de058bdb/attachment.sig>