[jdev] Message Read Receipts

[Lance Stout]

> Any thoughts either way on my "Chat Marker" proposal?

So, after some pondering, there are three user experiences I can see:

1) The primary clients talking to each other:

So XEP-0085 by itself should cover this, as Stefan pointed out. However, it
might leave holes because of non-instanaeous delivery. Eg, Juliet sends Romeo
a message at the same time he sends an active state message. So Juliet would
assume Romeo has read a message that he might not have actually received yet.

If we make a new element to tie the update with a specific message
ID, then that potential hole goes away. So we can add a new

     <lastread id="1234etc" xmlns="urn:xmpp:lastread:tmp" />

element to outgoing messages when:

a) The last ID sent by the other person has changed (so only send a
   <lastread /> update once per change in ID)
b) If the user doesn't send a response chat within some period of time,
   automatically send a <lastread /> update. Basically, give the user a chance
   to respond with a message and piggyback the <lastread /> update with that (maybe
   a composing state message would suffice), but if after a few seconds the user
   hasn't done something and the client is still focused and active, etc, emit a
   standalone update.

As usual, we don't send these updates when the other client doesn't advertise
support for it in disco.

The combination of just delivery receipt and chat state might be sufficient, 
but I've not been able to convince myself yet that it would properly handle 
case 3 with offline messages.


2) A secondary client that is online, which wishes to stay in sync:

This is the purpose of XEP-0280 Message Carbons. So long as the delivery receipts,
chat state notifications and the <lastread /> updates from case 1 are also synced
via carbons, everything should be covered.


3) A user has received messages while offline:

So this is the fun one because it requires some interaction with the archives.
When requesting history, the results should note the ID where the offline
storage began, as Zash pointed out.

Based on that, the client can send a <lastread /> update. Likewise it can
generate the delivery receipts requested in the offline messages (although,
there shouldn't actually be any since you wouldn't request receipts when sending
to an offline JID, and XEP-0184 has a slight ambiguity with how to handle offline
messages).

I would suggest that standalone lastread updates should be included in archived 
history because they're required to fully resume conversation state to match
other systems like iMessage, etc. The main question at this point is where to 
send the updates (if at all), particularly when the sender JID is no longer online.



In general, what makes things challenging is that message IDs are not required to
be globally unique. The same ID could be used multiple times during the same
conversation if a user is bouncing between clients or reconnects.


-- Lance
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4240 bytes
Desc: not available
URL: <https://www.jabber.org/jdev/attachments/20130519/147a8c0c/attachment.bin>