[jdev] Message Read Receipts

[Spencer MacDonald]

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

The more I think about it the more it seems to be the correct solution.

The implementation is independent of Message Archiving and as it is only a
marker the amount of storage and bandwidth required is minimal.

If people thing it is a good idea I can draft an XEP.

Regards

Spencer


On Thu, May 16, 2013 at 11:58 AM, Spencer MacDonald <
spencer.macdonald.other at gmail.com> wrote:

> So my suggestion is "Chat Markers", where you mark a given message with a
> Chat Maker.
>
> So you could retrieve your chat makers between you and a given jid:
>
> <iq type='get' id='chat-marker-1'>
> <query xmlns='urn:xmpp:chat-marker:tmp'>
> <with>juliet at example.com</with>
>  </query>
> </iq>
>
> You would then receive the 'read' and 'received' chat marker between the
> you and the other jid.
>
> <iq to='romeo at example.com/phone' type='result' id='chat-marker-1'>
> <query xmlns='urn:xmpp:chat-marker:tmp'>
>  <read to='juliet at example.net' id='message-3'
> xmlns="urn:xmpp:chat-marker:tmp"/>
> <received to='juliet at example.net' id='message-3'
> xmlns="urn:xmpp:chat-marker:tmp"/>
>  <read from='juliet at example.net' id='message-1'
> xmlns="urn:xmpp:chat-marker:tmp"/>
>  <received from='juliet at example.net' id='message-2'
> xmlns="urn:xmpp:chat-marker:tmp"/>
>  </query>
> </iq>
>
> You can update you Chat Markers like so:
>
>  <iq type='set' id='chat-marker-2'>
>   <chat-markers xmlns='urn:xmpp:chat-marker:tmp'>
>  <with>juliet at example.net</with>
>  <read>message-4</read>
> <received>message-4</read>
>   </chat-markers>
>  </iq>
>
> These would be pushed to your other devices
>
> <iq to='romeo at example.com/tablet' type='set' id='chat-marker-3'>
>  <query xmlns='urn:xmpp:chat-marker:tmp'>
> <read to='juliet at example.net' id='message-4'
> xmlns="urn:xmpp:chat-marker:tmp"/>
>  <received to='juliet at example.net' id='message-4'
> xmlns="urn:xmpp:chat-marker:tmp"/>
> </query>
> </iq>
>
> and to other user's devices
>
> <iq to='juliet at example.com/phone' type='set' id='chat-marker-3'>
>  <query xmlns='urn:xmpp:chat-marker:tmp'>
> <read from='romeo at example.net' id='message-4'
> xmlns="urn:xmpp:chat-marker:tmp"/>
>  <received from='romeo at example.net' id='message-4'
> xmlns="urn:xmpp:chat-marker:tmp"/>
> </query>
> </iq>
>
> Regards
>
> Spencer
>
>
>
>
> On Thu, May 16, 2013 at 9:59 AM, Jon Doyle <jdoyle at communigate.com> wrote:
>
>> Hello;
>>
>> *[JH] I do think another interesting case is where the message is in
>> fact “read” by a agent/bot/program (e.g. service bots or even M2M
>> messaging),  a timestamped receipt request is in fact helpful as there is a
>> temporal difference between the reception, processing and response to a
>> message – would be a real-world case 1 example.*
>>
>>
>> I can see the value, and would propose that really means some "tangible"
>> action must occur for it to be a valid "receipt". No different than in the
>> human world where I sign for an envelope at the front door. I say this
>> because what you are saying is that the "value" here is to show the
>> "forensic" data, that "time-stamp" you mention. It should in fact be the
>> record of when the button was pushed, or the app "signed off" on receipt.
>> It could include a variety of things, the other side can see a display
>> (client side) of "read", but the data around that transaction could be
>> stored as a "receipt" which could be used in a lot of business or forensic
>> applications. All of which in theory could have tremendous value in a
>> variety of usage model cases.
>>
>> I think all of us that have used Skype or iMessage know about the
>> challenges of "message receipt" in a multi-cleint scenario.
>>
>> Regards,
>>
>> Jon
>>
>>
>> _______________________________________________
>> JDev mailing list
>> Info: http://mail.jabber.org/mailman/listinfo/jdev
>> Unsubscribe: JDev-unsubscribe at jabber.org
>> _______________________________________________
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.jabber.org/jdev/attachments/20130518/cc948887/attachment.html>