On Thu, Oct 16, 2014 at 10:52 AM, Ximin Luo <[email protected]> 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
_______________________________________________
Messaging mailing list
[email protected]
https://moderncrypto.org/mailman/listinfo/messaging
