[messaging] Message delivery and revocation in Pond etc

[Ben Laurie]

On 3 April 2014 01:54, Tom Ritter <tom at ritter.vg> wrote:
> On 2 April 2014 06:43, Ben Laurie <ben at links.org> wrote:
>> On 31 March 2014 20:11, Ximin Luo <infinity0 at pwned.gg> wrote:
>>> I'm more and more favouring the idea that, in an end-to-end-secure system, you should *not* consider a message "definitely received" by the intended recipients, until you receive an ACK from them that strongly (but perhaps indirectly) refers to the message that you sent. (With email this is a no-no but here we've already authorized the sender.)
>>
>> +1!
>>
>> I once had a bug in my XMPP server that caused it to drop ~50% of
>> messages. It took a surprisingly long time and some rather odd
>> conversations before anyone noticed.
>
>
> Facebook somewhat recently added in a feature where, when you send a
> message to a user, and you can see when they 'saw' it.
>
> Whole idea of read receipts skeeves me out.  My software will receive
> a message from you.  I may very well spend a single second glancing at
> it to determine whether or not it is time-sensitive. But the fact that
> you know I received it now implies that I need to get to it and reply
> to it.

That seems like a social contract that is up to you to define, not
software. Doing group messaging well without acks seems hard.
Actually, doing _instant_ messaging (the clue is in the name, btw) is
hard without acks, too.

>  Or confirms conclusively that I received but chose to ignore.
> I don't like my software leaking time of receipt or time of access.

Agree about time of access. In any case, s/w can't know that.