[messaging] Message acknowledgement and delivery/read receipts

[Ximin Luo]

On 03/04/14 19:34, Michael Rogers wrote:
> On 03/04/14 16:17, Ximin Luo wrote:
>> Could you go into some more detail on what you mean by delivery 
>> receipt vs read receipt here? Under some interpretations, they
>> would be the same thing, just from the sender vs recipient points
>> of view.
> 
> A delivery receipt means the message has been delivered to the
> recipient's device; a read receipt means the recipient has read the
> message.
> 

So in your tests, effectively the recipients are sacrificing a little reliability (since the device may be lost before reading) for the privacy gain of the sender not knowing the exact time of reading. This seems reasonable.

It would be nice to regain this reliability though, for critical cases. If the recipient writes a reply, this clearly indicates understanding of the original message, in a way that an automatic "delivery receipt" doesn't. An empty manual reply ("ack" in Pond) serves a similar purpose, for those messages that don't warrant an explicit response.

Two levels of acks (manual, "understood") vs (auto, "delivered") makes more sense to me now. And I can see that "read receipts", in your sense, probably shouldn't be automatic.

Note however, that manual acks are not exactly equivalent to "oh just send an empty message", because they themselves don't need to be acked, which is important if you implement a resend-if-not-acked behaviour.

> WhatsApp and Telegram use a single tick for delivered and a double
> tick for read. I believe BBM uses S, D and R for sent, delivered and
> read. SMS can request delivery receipts, but not read receipts as far
> as I know, and I think it's optional to send a delivery receipt if one
> is requested. (Bernard?)
> 
> As of a few minutes ago, Briar uses a single tick for delivered (for
> one-to-one messages only). I'm not planning to implement read receipts.
> 
>> I can see how read receipts might seem creepy under some cases,
>> such as when demanded by someone you've never met, or when
>> immediately demanded over a high-latency medium. So, it's certainly
>> reasonable to give the user the option of not auto-acking received
>> messages.[1]
> 
> Acks may be needed by the protocol, as they are in Briar for example.
> Whether the acks are shown in the sender's UI is a separate issue -
> but I tend to think that concealing something in the UI for privacy
> reasons when the information's present in the backend is a bad idea:
> it gives the user a false sense of what information is exposed to
> other users (who may not use the same UI).
> 

I agree that acks should be shown on the sender's side. Or rather, unacked messages should be distinguished.

-- 
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/20140403/baf47218/attachment.sig>