XEP proposal: filtering chat notifications
I am an end-user using two XMPP clients: for desktop and mobile. Since there is no XEP standard for muting conversations, the two clients implement this in their own way, and they are out of sync: the contacts I have muted on phone are not automatically muted on desktop and vice-verse. While looking to see if XMPP have such XEP, I found these extensions from Tigase that might be helpful in writing an official XEP: https://xeps.tigase.net/docs/push-notifications/filters
I agree that it would be nice to have fine-grained notifications synchronization across clients.
While looking to see if XMPP have such XEP, I found these extensions from Tigase that might be helpful in writing an official XEP:
I think this covers the specific use case of a push server, which unfortunately limits its scope. For MUCs, it is a perfect fit for XEP-0402: PEP Native Bookmarks <extension>, in the spirit of XEP-0469: Bookmark Pinning? eg: <itemid='theplay@conference.shakespeare.lit'><conferencexmlns='urn:xmpp:bookmarks:1'name='The Play's the Thing'autojoin='true'><nick>JC</nick><extensions><notifyxmlns='urn:xmpp:filter-notifications:0'when='always'/></extensions></conference></item> with when= taking 3 possible values "always", "never" and "on-mention". For contacts, a PEP (XEP-0163: Personal Eventing Protocol) node would work. wouldn't it? <publishnode='urn:xmpp:filter-notifications:0'><itemid='that-damn-guy@annoying.server'><notify when='never'/></item></publish> I am not entirely sure about the real life use-case for muting notifications from a contact when you can just block them via other ways, but maybe I'm just not imaginative enough. :) List, any feedback on these ideas? -- Nicolas
We actually have it in Xabber, not as a part of push notifications, of course, but as a part of our broad XEP-SYNC extension that is aimed at syncing messenger state, including after startup, etc. It is correct that it definitely connected with push notifications, as the only way to silence a push notification on ios is to not send it, or else it will have to be shown. So our push notifications extension also sources settings from XEP-SYNC data and does not send notifications if they aren't needed. The end result looks like this -- conversation with heartbeat@redsolution.com is muted: [image: image.png] You can test it here on our test server, registration with a link: https://xabber.thebluemarble.ru/?rkey=ae69770abdxweu2e On Wed, 29 May 2024 at 15:31, Nicolas Cedilnik <nicoco@nicoco.fr> wrote:
I agree that it would be nice to have fine-grained notifications synchronization across clients.
While looking to see if XMPP have such XEP, I found these extensions from Tigase that might be helpful in writing an official XEP: https://xeps.tigase.net/docs/push-notifications/filters
I think this covers the specific use case of a push server, which unfortunately limits its scope.
For MUCs, it is a perfect fit for XEP-0402: PEP Native Bookmarks <extension>, in the spirit of XEP-0469: Bookmark Pinning? eg:
<item id='theplay@conference.shakespeare.lit'> <conference xmlns='urn:xmpp:bookmarks:1' name='The Play's the Thing' autojoin='true'> <nick>JC</nick> <extensions> <notify xmlns='urn:xmpp:filter-notifications:0' when='always'/> </extensions> </conference> </item>
with when= taking 3 possible values "always", "never" and "on-mention".
For contacts, a PEP (XEP-0163: Personal Eventing Protocol) node would work. wouldn't it?
<publish node='urn:xmpp:filter-notifications:0'> <item id='that-damn-guy@annoying.server'> <notify when='never'/> </item> </publish>
I am not entirely sure about the real life use-case for muting notifications from a contact when you can just block them via other ways, but maybe I'm just not imaginative enough. :)
List, any feedback on these ideas?
-- Nicolas _______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
For MUCs, it is a perfect fit for XEP-0402: PEP Native Bookmarks <extension>, in the spirit of XEP-0469: Bookmark Pinning? eg:
For MUCs or for any other chat with more than one person inside, which includes 1:1 chat. Bookmarks2 says exolicitlg that you can't assume the chats are MUCs.
On Wed, 2024-05-29 at 11:32 +0000, Stephen Paul Weber wrote:
For MUCs, it is a perfect fit for XEP-0402: PEP Native Bookmarks <extension>, in the spirit of XEP-0469: Bookmark Pinning? eg:
For MUCs or for any other chat with more than one person inside, which includes 1:1 chat. Bookmarks2 says exolicitlg that you can't assume the chats are MUCs.
The XEP is explicit that you *can* assume the chat to be MUC and that it must be a groupchat chatroom (which rules out a JID of a user that can be used to talk 1:1).
While a client can typically assume a chatroom based on Multi-User Chat (XEP-0045) [4], clients are free to store chatrooms based on any particular groupchat protocol.
The XEP is explicit that you *can* assume the chat to be MUC and that it must be a groupchat chatroom (which rules out a JID of a user that can be used to talk 1:1).
A 1:1 chat *is* a groupchat with two participants. It's not a MUC but as you quoted the XEP says it doesn't have to be.
On Wed, 2024-05-29 at 13:02 +0000, Stephen Paul Weber wrote:
A 1:1 chat *is* a groupchat with two participants. It's not a MUC but as you quoted the XEP says it doesn't have to be.
The XEP says that clients can assume it is MUC, but that it doesn't have to be. It has to be a "chatroom of any particular groupchat protocol". While you are free to argue that 1:1 chats are groupchats of a group of two and therefor regular chat messages form a groupchat protocol, I doubt it was intended that way by the authors (neither in XEP-0402 nor in any other XEP). What makes it still clear in the XEP, is that the bookmark must be of a *chatroom* of a groupchat protocol, and a regular user JID is certainly not a chatroom. The XEP is clearly hinting and a successor of MUC (like MIX) being potentially using it. Not that you use it for 1:1 chats. If there is really confusion about this and the word groupchat and you're not trying to make this up to retrofit this XEP, I suggest we put some official definitions of terms popularly used in XEPs up somewhere.
It has to be a "chatroom of any particular groupchat protocol". While you are free to argue that 1:1 chats are groupchats of a group of two and therefor regular chat messages form a groupchat protocol, I doubt it was intended that way by the authors (neither in XEP-0402 nor in any other XEP).
What makes it still clear in the XEP, is that the bookmark must be of a *chatroom* of a groupchat protocol, and a regular user JID is certainly not a chatroom.
I disagree. I think it is a chatroom. Author intention doesn't seem relevant here, and bookmarking 1:1 chats doesn't violate anything the XEP already requires an implementation to deal with (namely, that the groupchat may use a protocol other than MUC).
On Wed, 2024-05-29 at 08:57 -0500, Stephen Paul Weber wrote:
I disagree. I think it is a chatroom.
A user is not a chatroom. A chatroom is something where users join and leave and send messages to that are received by other currently joined users in the room. I have never heard of someone suggesting that a user is a chatroom or a user's personal JID is a chatroom JID or anything like this. In no other context we have previously understood user JIDs as groupchat chatrooms.
and bookmarking 1:1 chats doesn't violate anything the XEP already requires an implementation to deal with (namely, that the groupchat may use a protocol other than MUC).
This is not true. A valid client may be assuming it's a MUC (again: the XEP clearly says that client's can just assume it's a MUC, they just must be able to handle if it is not) and if it can't join the room using the MUC protocol, it must assume it's a chat room that uses any other groupchat protocol. If we don't specify that traditional direct XMPP IM is a groupchat protocol (which again, I strongly think it isn't and if we do want to understand it as such, we should make it explicit), this means a valid client that only supports MUC and direct XMPP IM must assume that it doesn't support interaction with that JID at all, if it fails to join using the MUC protocol and may validly stop the user from sending direct XMPP IM messages to that JID.
On Wed, 29 May 2024 at 19:41, Marvin W <xmpp@larma.de> wrote:
On Wed, 2024-05-29 at 08:57 -0500, Stephen Paul Weber wrote:
I disagree. I think it is a chatroom.
A user is not a chatroom. A chatroom is something where users join and leave and send messages to that are received by other currently joined users in the room.
I have never heard of someone suggesting that a user is a chatroom or a user's personal JID is a chatroom JID or anything like this. In no other context we have previously understood user JIDs as groupchat chatrooms.
This is only tangentially related to the topic of bookmarks, but in our group chat protocol we made a groupchat have a regular JID, and it does wonders. Among other advantages and ease of use on multiple platforms and syncing devices, etc, it also provides seamless fallback for legacy client apps, who's users can participate in group chat and do it on all their multiple devices entirely without issues, message carbons and all. Joining and leaving is done entirely via subscriptions.
I am not entirely sure about the real life use-case for muting notifications from a contact when you can just block them via other ways, but maybe I'm just not imaginative enough. :)
The use case is that it might be desirable to have noisy notifications from specific contacts and muted notifications from other non-urgent or annoying contacts. - Avid Seeker On Wednesday, May 29th, 2024 at 10:31, Nicolas Cedilnik <nicoco@nicoco.fr> wrote:
I agree that it would be nice to have fine-grained notifications synchronization across clients.
While looking to see if XMPP have such XEP, I found these extensions from Tigase that might be helpful in writing an official XEP:
I think this covers the specific use case of a push server, which unfortunately limits its scope.
For MUCs, it is a perfect fit for XEP-0402: PEP Native Bookmarks <extension>, in the spirit of XEP-0469: Bookmark Pinning? eg:
<item id='theplay@conference.shakespeare.lit'> <conference xmlns='urn:xmpp:bookmarks:1' name='The Play's the Thing' autojoin='true'> <nick>JC</nick> <extensions> <notify xmlns='urn:xmpp:filter-notifications:0' when='always'/> </extensions> </conference> </item>
with when= taking 3 possible values "always", "never" and "on-mention".
For contacts, a PEP (XEP-0163: Personal Eventing Protocol) node would work. wouldn't it?
<publish node='urn:xmpp:filter-notifications:0'> <item id='that-damn-guy@annoying.server'> <notify when='never'/> </item> </publish>
I am not entirely sure about the real life use-case for muting notifications from a contact when you can just block them via other ways, but maybe I'm just not imaginative enough. :)
List, any feedback on these ideas?
-- Nicolas
Hi all, I gave an attempt at this, you can read a built version here: <https://nicoco.fr/xep-notification-filter.html> I made it so it can be a bookmarks <extensions> child, but did not make that a requirement, to leave the door open for use in other places, possibly best suited for 1:1 chats. I opened a PR on github: <https://github.com/xsf/xeps/pull/1347>. Feedback welcome! -- nicoco
participants (6)
-
Andrew Nenakhov -
Avid Seeker -
avidseeker7＠protonmail.com
-
Marvin W -
Nicolas Cedilnik -
Stephen Paul Weber