[messaging] Group messaging consistency under resource constraints

Trevor Perrin trevp at trevp.net
Thu Oct 16 11:51:44 PDT 2014


On Thu, Oct 16, 2014 at 10:52 AM, Ximin Luo <infinity0 at pwned.gg> wrote:
> On 16/10/14 18:37, Trevor Perrin wrote:
>>
>> Pond doesn't have a notion of group messages.  But if it did, I
>> imagine they would still have these properties (in particular, I
>> imagine users would *not* want to reveal to mailbox servers what
>> groups they are members of, since hiding relationships is the point of
>> Pond).  So if the sender goes offline, there's no-one else who can
>> re-transmit a lost message.
>>
>
> I'm sure there would be ways to accomplish this. Doesn't everyone already contact the central server via Tor, so the server should not know who is doing the re-sending?

Everyone can have their own mailbox server - there's no "central server" here.

Anyways, who are you imagining doing the "re-sending"?  This is
asynchronous messaging - you can't assume users are online to
re-transmit messages to each other.


> Are there particular reasons why you think this might be fundamentally impossible or hard?

There's no-one to do this.


>> Dropped messages could easily arise, e.g. my network connection is
>> interrupted before I've sent my message to everyone in the group.
>>
>> In that case, it seems obvious that the UI would have to tolerate
>> dropped messages.  Having a single dropped message prevent that
>> recipient from seeing the rest of the conversation doesn't seem
>> acceptable.
>>
>
> To reason about this more precisely, we would want a model of delay. But, intuitively, in practise I don't think this situation is as severe as you think.
>
> The "prevention" is only temporary, never permanent. This is because, to be able to receive a message out-of-order in the first place, the transport is at least semi-reliable. If it is semi-reliable, then we can fix dropped messages just by resending them intelligently.

I don't think you've internalized the "asynchronous messaging" use
case (email, text messages, Pond, TextSecure).  It means messages can
be sent and received regardless of whether correspondents are online.

Alice to Bob, Charlie: "Krakens are coming!"
  <message delivered to Bob but not Charlie>
  <Alice eaten by Kraken>
Bob to Alice, Charlie: "Krakens headed Charlie's way!"
  <message delivered to Charlie>
  <Bob eaten by Kraken>

There is no way for Alice's message to be re-transmitted here.  So it
seems obvious to me that Charlie's client should display Bob's message
with some indicator that there's a missing predecessor (Alice's
message), and we need transcript consistency algorithms / UIs that can
support this.


> These strategies might work in greatly different ways, too. For example, there is a strategy that results in *no delay*, but takes more bandwidth so is not suitable for TextSecure SMS, but might fit within the larger (but granted, still limited) bandwidth constraints of Pond. Consider this sequence of events (from A's point of view):
>
> A: 1
> B: ack(1)
> A: 2
> A: 3
>
> When Alice sends 3, she knows that Bob has acked 1 but not 2, so she sends {3,2} at the same time. Quoting previous emails accomplishes the same thing, but in a more ad-hoc way.

So if one party in a group is offline, every new message to them
contains all previous messages?  That's impractical and a forward
secrecy problem.


Trevor


More information about the Messaging mailing list