[messaging] Message acknowledgement and delivery/read receipts

Michael Rogers michael at briarproject.org
Thu Apr 3 11:34:56 PDT 2014


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

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.

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).

> However, the key point is that there is no way for a sender to be 
> certain about receipt until the receiver acknowledges it. If the 
> recipient purposefully withholds acknowledgement, then it is 
> reasonable (surely?[2]) for the sender to keep re-sending the
> message until he gets the ack.

Yes, I think that's what most reliable messaging protocols would do.

> In a multiparty conversation, this is even more important for 
> transcript consistency - if Alice sends Bob a message M, Bob
> cannot be sure that this was seen by Carol and Dave, until he gets
> acks from them that refer to M.
> 
> You probably still want to display the messages in the meantime 
> though, so I'm imagining a UI where some messages have an
> indicator that "perhaps not everyone has seen this". But the UX
> people will tell me if this would be too complex. ¬.¬

What 'delivered' and 'read' mean in a group context is a can of worms
I haven't opened yet. :-)

Cheers,
Michael
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBCAAGBQJTPanQAAoJEBEET9GfxSfM0ywH/ij68YdjSSPbUOKoYUPHJhy5
oHixImMi+jzgm6uWLovPyIiBf6BKdiEnnxtPemkIQtHS/YF4OkWDFtjfERipcdGC
4ybcrO4CqxhdvRuddDdbnsFv60Sc/U+5XN1GmLfcvsynNQ9D2xAI77FkcTWkSzC2
ZLU30F5j9ei8vMqmpPd6PzkoE8mtR8jV1ehveyuoI554ojZJRJ4RbuNhzvsspEvD
Ju1GYlbBCL0ckiiL6icow8pA4lVYgCIX6o6iPOmO6Nos8EWZoLdJn62WmIpsbduF
yYwl+q4wIgGlwgo9N5HY7F6ZW4dkis/eM31RPZYyxjlaITV/JZNidz3ZGcW14SI=
=twnO
-----END PGP SIGNATURE-----


More information about the Messaging mailing list