27 May
2024
27 May
'24
5:26 p.m.
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
29 May
29 May
4:31 a.m.
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:
<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
5:27 a.m.
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(a)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(a)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(a)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(a)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(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
5:32 a.m.
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.
6:58 a.m.
On Wed, 2024-05-29 at 11:32 +0000, Stephen Paul Weber wrote:
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).
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. 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.
7:02 a.m.
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.
7:52 a.m.
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.
7:57 a.m.
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).
8:41 a.m.
New subject: XEP-0402: PEP Native bookmarks and defintion of a groupchat chatroom (was: XEP proposal: filtering chat notifications)
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.
11:24 a.m.
New subject: XEP-0402: PEP Native bookmarks and defintion of a groupchat chatroom (was: XEP proposal: filtering chat notifications)
On Wed, 29 May 2024 at 19:41, Marvin W <xmpp(a)larma.de> wrote:
On Wed, 2024-05-29 at 08:57 -0500, Stephen Paul Weber
wrote:
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 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.
10:05 a.m.
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(a)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(a)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(a)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
4 Jun
4 Jun
2:02 p.m.
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
96
days inactive
104
days old
11 comments
6 participants
participants (6)
-
Andrew Nenakhov -
Avid Seeker -
avidseeker7＠protonmail.com
-
Marvin W -
Nicolas Cedilnik -
Stephen Paul Weber