[Standards] Unread syncing

Kevin Smith kevin.smith at isode.com
Fri Dec 2 13:06:21 UTC 2016


> On 2 Dec 2016, at 13:00, Christian Schudt <christian.schudt at gmx.de> wrote:
> 
> Can't XEP-0333 used for that?
>  
> A sends a message to B with a "read request".
> B reads the message and sends a "read receipt" back to A.
>  
> The read receipt is stored in the server archive normally as any other (chat) message.
>  
> Clients can query the archive in a normal way, e.g. all message from "today", e.g. receive 3 chat messages and 2 read receipts and therefore know, that there's one "new", unread message.
>  
> I probably don't understand your point though…

I think you possibly don’t :)

This is for synchronising the ‘read’ status between all of my clients, such that a) they’re consistent and b) when a new client comes online it can quickly determine which contacts have unread messages.

/K

>  
> -- Christian
>  
> Gesendet: Freitag, 02. Dezember 2016 um 12:44 Uhr
> Von: "Kevin Smith" <kevin.smith at isode.com>
> An: "XMPP Standards" <standards at xmpp.org>
> Betreff: [Standards] Unread syncing
> A question:
> 
> I’ve always assumed that we would do sync of the unread (or, rather read) status of messages between contacts via private PEP and, indeed, this is the approach we verbally specced at a summit a while back (which I have yet to write up).
> 
> I’ve been thinking about this further, in the context of how the big picture looks for a server and many clients, and I’m coming to the conclusion that it’s not the best approach. Yes, it avoids need for any changes on the server, but I think we’re in a world (MIX, PAM, MAM) where for a modern XMPP setup, we’re going to need modern XMPP servers and so as long as we don’t break existing interop with older systems that’s ok.
> 
> I think that the better solution is going to be putting this into the server, tied with MAM. The basic flow then is that the server injects stable IDs (the ones used by MAM) into stanzas you receive. Then, whenever it likes, a client can tell the server that id X for contact Y has been read. The server checks that this is a newer read marker than was there, to avoid race conditions, and updates its state for that contact (this then gets propagated to other clients). Then when coming online a client can query this state to find not only the contacts with unread messages, but also the number of unread messages. It can then, whenever it wants (e.g. immediately, or when a chat window is opened) query either a chunk of history (e.g. last 20 messages) or all unread messages for that contact (or those contacts). I think this makes the client implementation vastly simpler, the server implementation isn’t complex (and is simpler than the client implementation would need to be for the other approach), it avoids nasty race conditions that need fancy handling otherwise, and also lets a client show useful information (the unread count per contact) with less exchanged data on startup.
> 
> Thoughts?
> 
> /K
> _______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________
> _______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________



More information about the Standards mailing list