[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