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 ||_________________________________________________||
signature.asc
Description: Digital signature
