[Standards] Multi-client operation and read-until-X markers

Kevin Smith kevin.smith at isode.com
Fri Jan 15 16:55:23 UTC 2016

Thread necromancy!

On 2 Apr 2015, at 18:12, Georg Lukas <georg at op-co.de> wrote:
> The first problem I encountered (after implementing carbons) is user
> notification on mobile (i.e. play a ringtone, vibrate, display a popup
> like https://yaxim.org/screenshots/tiny/notification.png ).
> When the user is actively using his desktop client, the mobile client
> needs a way to detect that and prevent notifications / ringtone /
> vibrations. In theory, this is accomplished by resource-locking
> combined with no notifications on carbons, but in practice there are
> some issues with that:

I think you can effectively solve this in most cases by delaying notifications for a few seconds when you’re in the background, and then cancel any pending notification when it’s marked as Read (obviously needs Read support).

> MUCs
> As stated above, nick-sharing is the only sane way to do MUCs with
> multi-clients, and we have multiple problems to solve here:

We need to solve this for MIX, at least. It’d be good to make sure we keep this in mind during MIX work.

> In multi-client operation, it is important to synchronize between
> clients, which messages have been read (displayed to the user) already.
> This is different from Chat Markers (XEP-0333), which indicate the
> read-state to the sender of the message.

Yes, very much, this is the big missing bit of the picture. We discussed this at the last summit and came up with a solution, but no-one wrote it up into a protoXEP. Mostly, I suspect, because I was supposed to do that and have been trying to get MIX out first.


More information about the Standards mailing list