I think the issue with embedding it in a message is the neither XEP-0136 or XEP-0313 store message that have no body, which a includes a last read message. > > Keeping it as a separate XEP means it can be used with any Message Archiving > solution. > > Also the auto sending of read is something I want to avoid, if they haven't > read it then don't move the marker. There is a separate delivered marker for > this. I appreciate that delivery receipts already exist but they have to be > sent for every message that requests them and as you alluded to, how your > supposed to handle them with archived messages is a bit ambiguous. > > One solution I thought of for duplicate message ids, is for the server to > embed a timestamp based on the archive into the chat marker. > > Naturally if I turned this into any XEP then all of this would only be sent > to clients that advertise support. > > Regards > > Spencer > > On Sunday, 19 May 2013 at 09:23, Lance Stout wrote: > >>> 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 >> _______________________________________________ >> JDev mailing list >> Info: http://mail.jabber.org/mailman/listinfo/jdev >> Unsubscribe: [email protected] >> _______________________________________________ >> >> Attachments: >> - smime.p7s > > _______________________________________________ > JDev mailing list > Info: http://mail.jabber.org/mailman/listinfo/jdev > Unsubscribe: [email protected] > _______________________________________________
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ JDev mailing list Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: [email protected] _______________________________________________
