> On 2 Dec 2016, at 13:42, Christian Schudt <[email protected]> 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?

Yes.

> 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>
<unread-please/>
</iq>

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

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).

/K
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: [email protected]
_______________________________________________

Reply via email to