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

Georg Lukas georg at op-co.de
Thu Apr 2 17:12:00 UTC 2015


Hi,

to bring todays discussion in jdev@ to a more formal ground, I'd like to
write down the list of problems I see with the operation of multiple
clients (e.g. desktop and mobile) on the same bare JID, regarding
notifications, MUCs, and the read-state of messages. This is slightly
related to the ongoing 0280 discussion - as was suggested in jdev@, we
need to point out the problems there are, the problems we can fix and
the possible solutions, in that order.

NOTIFICATIONS

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:

a) Auto-Away: on desktop clients, the default mechanism to give up the
lock is auto-away, which usually triggers after 5..15 minutes. In that
time frame, your mobile client won't beep on such important things as
"let's change our meeting place/time". (Maybe in some parallel universe
people are locking their desktop when moving out, and their XMPP clients
can detect that reliably and toggle "away").

b) Incorrect Routing: Some clients (*cough*yaxim*cough*) rely on the
server to route messages, whereas others might have bugs in their
resource locking mechanism. It has happened before that yaxim had a
higher resource priority, and thus received the normal messages, while
the desktop client (which the user was active at) only got the carbons.
The manifestation of this was yaxim beeping all the time. While this is
an implementation issue and not a problem of the protocol per se, it
should be kept in mind.

c) It doesn't work in MUCs when your clients share a nickname.
Currently, nick-sharing is merely a side effect (see below), but I
consider it a requirement for sane multi-client operation. However,
there is no side-channel in a MUC for your clients to exchange
information, and there is no reliable way to detect the presence of
parallel clients in a MUC (you can not even match your own outgoing
messages, see
<http://mail.jabber.org/pipermail/standards/2014-July/029012.html>).

yaxim's heuristic for notifications is as follows:

 * no notification/ringtone on "sent" carbons, i.e. for messages you
   wrote on the PC
 * one audible notification on the first "received" carbon
 * silent notification updates on further "received" carbons, until you
   open the chat window
 * audible notifications on received non-carbon messages

This is not perfect (I'm sure it violates the user model for many
people), so it would be good to discuss and define a standard
multi-client notification behaviour as an Informational XEP.


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:

1.) Bookmarks: There are two incompatible bookmark implementations
(private store vs. PEP), and neither allows to sync live state.
They have an "auto-join" flag, but they are missing a "joined" flag,
which is needed to sync multi-clients. I would propose just changing
the meaning of the existing flag, i.e. to unset the bookmarks'
"auto-join" when one client leaves a MUC, propagating that to all other
clients, making them leave the MUC as well. And vice-versa.

2.) Presence: other participants have no way to detect the presence of
multiple clients, the last client to send a presence stanza "wins" the
state. If one client is indicating "xa" and another "chat", the result
is random. The same problem arises with CSNs.
It might be possible for a client to deduce the presence of a second
client under the same nickname by carefully comparing outgoing presence
packets with what it receives, but there is no mechanism for
third parties.

3.) Routing: groupchat messages are rather easy, but what is supposed to
happen with IQs? How can we handle disco#info and other functionally
relevant mechansims when multiple clients hide behind the same resource?


MARK-AS-READ

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.

This is related to notifications (the client can automatically remove a
pending notification if it receives notice that another client has
displayed the messages), but it is not the same, as it does not solve
the problem of immediate (audible / haptic) notifications when the
messages are received.

Currently, there is no mechanism for marking messages as read. Opinions
vary on how to approach this - per-message, per-contact or globally.

Per-message: this would cause significant additional traffic, but is
extremely (too?) flexible, in cases when you just look at parts of a
conversation from your mobile device, and want to read up the remains
from your PC later on (IMAP, anyone?).

Per-contact (/-muc): this would provide every "chat window" with a
marker (e.g. a horizontal rule) that separates what has been read from
what is new. The overhead is probably comparable to (or slightly less
than) Chat State Notifications. This would not work reliably if a client
is missing parts of the history between the old and the new marker
positions (messages would remain unnoticed), so it would make sense to
combine this with MAM.

Globally: least overhead, but does not make much sense. Basically,
whenever you look at any of your clients, it would signal to all others
that all messages have been read.


There are heuristics to guess which messages might have been read by
another client. One such indicator is when you receive CSNs or "sent"
carbons - you probably can consider all messages with the respective
contact as "read" in that moment. However, this approach is prone to
rx/tx race conditions, and is still just a heuristic.

Similar to MUC notifications, we need some side-channel to synchronize
the read-markers.


Okay, this post has gotten long enough. There must be another dozen of
problems that don't come to my mind right now (like server-side presence
annotations for XEP-0198 session zombies), but let's get the above ones
sorted out first.


Georg

P.S: If you are only responding to individual parts / arguments, please
do not forget to change the subject accordingly :-)

P.P.S: Happy Easter to you all! Don't let a grumpy app developer ruin
your holidays!
-- 
|| http://op-co.de ++  GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N  ++
|| gpg: 0x962FD2DE ||  o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+  ||
|| Ge0rG: euIRCnet ||  X(+++) tv+ b+(++) DI+++ D- G e++++ h- r++ y?   ||
++ IRCnet OFTC OPN ||_________________________________________________||
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 811 bytes
Desc: Digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20150402/3afcd9c3/attachment.sig>


More information about the Standards mailing list