[Standards] Unread syncing

Kevin Smith kevin.smith at isode.com
Fri Dec 2 14:07:15 UTC 2016

> On 2 Dec 2016, at 13:42, Christian Schudt <christian.schudt at gmx.de> wrote:
>> 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.
> Isn't MAM supposed to address the issue of "synchronizing multiple resources/clients", so that every client sees the same history of (chat) messages, even if they were originally delivered to another client?


> If that syncing works for chat messages, it should work for "read receipt" messages as well, no?

Except that they’re not chat messages, so won’t be stored, and if they were you’d be potentially up to doubling the size of your archive (I guess adding a quarter to, on average) as you fill it with read markers - unless you want to customise the MAM service to understand unread state, in which case what have you gained?

> The problem could also be exanded to other use cases like "syncing message corrections" between clients (XEP-0308), which would work the same: each client retrieves messages from MAM and applies them in order. If there's a message correction message, the client corrects the message.
> Likewise, if there are messages, which have no corresponding read marker, they are unread and can be displayed as unread by that client.

If you log on, your client does a complete synchronisation of all history from the (modified to include non-chat history for read markers) archive to local storage, and then processes the stanzas it will be able to see which contacts have unread messages and how many, yes. Having to do a full history download is clearly not tenable in the general case.

What I’m proposing is something like

<iq from=client to=account>

<iq from=account to=client>
<unread jid=romeo… id=oeub… count=3/>
<unread jid=juliet… id=acdb… count=1/>

We don’t have a sensible way of providing that with any of our current protocols (or, at least, none that spring to my mind).


More information about the Standards mailing list