[jdev] Message Read Receipts

Hund, Johannes johannes.hund at siemens.com
Tue May 21 07:57:01 UTC 2013

I like the idea of either piggy-backing the read receipt or sending it standalone, if no message is there to piggy-back.
I agree it can be quite difficult to define a "read" state of a message in a chat client interacting with a human, but I also think these read states or confirmations can play an important role in M2M or business applications. I am not sure if that should be an issue of standardization, but rather a solution to be thought out by implementers. (could be many different solutions, each specific for each application, dependent on environment e.g. Smartphone, Webclient or PC application).

So if the XEP defines well how to do it and what the receipt message is supposed to mean, it can be up to the implementers when to do it. (But of course, some implementation hints or best practices are always nice to have)

Regards, Johannes


I don't think its realistic to expect a user to hit a button to confirm that they've read the message. If you were going to do this, you're probably better off just having that confirmation button send an actual chat message to the person saying "I've read your message." This way you don't even have to build anything net new.

Most clients that implement read status do so based on simple activation the conversation. This is consistent across iMessage, BBM, and most email clients. As I said above we do this at my firm using a pubsub message to keep multiple client sessions in sync in terms of whats been read. This could easily be extended to notify the sender of the message.

On Mon, May 20, 2013 at 4:48 AM, Jon Doyle <jdoyle at communigate.com<mailto:jdoyle at communigate.com>> wrote:

If the given chat is active then yes it gets marked as read straight away, buy if a your online and in another chat the read marker isn't moved.

Is that not more "delivered" than actually "read"? It would not take long for my 12 year old daughter to figure out this trick.... and it could be useful to me when the GF gives me some instruction and I forget to say it might have went to the client, but I had "just stepped away to the phone and ran out the door".

A true "read" should have some indication from the human user IMO. That would have a value, for not just being sure somebody "read" something so you can have a GF with tapping foot when you arrive home, but you can imagine the business implications to be able to timestamp and show (evidence) that the user accepted some message as read (not just delivered).



JDev mailing list
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: JDev-unsubscribe at jabber.org<mailto:JDev-unsubscribe at jabber.org>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/jdev/attachments/20130521/cb29616c/attachment.html>

More information about the JDev mailing list