[Standards] Unread syncing

Kevin Smith kevin.smith at isode.com
Fri Dec 2 11:44:43 UTC 2016

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.



More information about the Standards mailing list