[messaging] Message acknowledgement and delivery/read receipts

[Ximin Luo]

(rename subject)

On 03/04/14 12:10, Michael Rogers wrote:
> On 03/04/14 01:54, Tom Ritter wrote:
>> 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.  Or confirms conclusively that I
>> received but chose to ignore. I don't like my software leaking time
>> of receipt or time of access.
> 
> Bernard and I discussed this issue with a group of users during a
> recent usability test. The users distinguished between delivery
> receipts and read receipts. They liked the reassurance of delivery
> receipts for messages they sent, but not the intrusiveness of read
> receipts for messages they received. FWIW, the consensus seemed to be
> that delivery receipts were worthwhile on balance, and read receipts not.
> 
> I've since had several requests for delivery receipts from another
> group of users, and was planning to implement them today before
> getting sidetracked by email. ;-)
> 
> Cheers,
> Michael
> 

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.

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]

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.

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

X

[1] For efficiency, we could give the user a "grace period" before an auto-ack, depending on the expected human latency of the medium, so that we can do an implicit-ack using the manual reply that the user might give anyway during this period.

[2] Assuming that the recipient has already authorized the sender to send to them, unlike in email.

-- 
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/72c0026f/attachment.sig>