1 Apr
2026
1 Apr
'26
12:30 a.m.
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: Occupant Mute Synchronization
Abstract:
Allows synchronizing a list of muted group chat participants between
multiple clients.
URL: https://xmpp.org/extensions/inbox/xep-occupant-mute-sync.html
The Council will decide in the next two weeks whether to accept this
proposal as an official XEP.
1 Apr
1 Apr
10:05 a.m.
This is great and I like it. One idea based on the other protoxep I just
read would be to change the syntax to:
<muted xmlns='urn:xmpp:mute:0'>
<occupant-id xmlns="urn:xmpp:occupant-id:0"
id="dd72603deec90a38ba552f7c68cbcc61bca202cd" />
</muted>
For better re-use of existing namespaces.
7 Apr
7 Apr
8:06 a.m.
Le mercredi 1 avril 2026, 09:30:42 heure d’été d’Europe centrale Daniel
Gultsch a écrit :
The XMPP Extensions Editor has received a proposal for
a new XEP.
Title: Occupant Mute Synchronization
Abstract:
Allows synchronizing a list of muted group chat participants between
multiple clients.
URL: https://xmpp.org/extensions/inbox/xep-occupant-mute-sync.html
The Council will decide in the next two weeks whether to accept this
proposal as an official XEP.
_______________________________________________
Standards mailing list -- standards(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
Hi, thanks for the contribution,
My main concern with storing a list of <mute> in bookmarks2 is the risk of
race condition. Also, what if user is in a very huge room and mute dozen of
participants? The later is probably niche, the former can be mitigated by
XEP-0395 but it's AFAIK not supported anywhere so far (note that I plan to
implement it in my Pubsub component). In practice the risk is very low, as one
user is probably muting on a single device at a time, but I can imagine cases
where it happens (e.g. delayed notification).
Best,
Goffi
8:08 a.m.
My main concern with storing a list of <mute> in
bookmarks2 is the risk of
race condition.
If they mute two different users in two different apps at exactly the same
moment? Is this realistic with human users?
Also, what if user is in a very huge room and mute
dozen of
participants?
Then you have a few dozen ids in a list. Is this a problem?
8:45 a.m.
Le mardi 7 avril 2026, 17:08:42 heure d’été d’Europe centrale Stephen Paul
Weber a écrit :
- user changes device (or has several client on same device), and one
notification arrives late for some reason.
- a client is offline, takes time to process MAM and so pubsub notifications, and
the user mute an entity before it's done.
But I agree that the risk is very low.
Probably not with realistic numbers. I'm just raising a potential issue that
may never happen. However, if other extensions are used and added to the room
item, we may reach pubsub item size limit at some point.
My main concern
with storing a list of <mute> in bookmarks2 is the risk of
race condition.
If they mute two different users in two different apps at exactly the same
moment? Is this realistic with human users? Also, what if user is in a very huge room and mute
dozen of
participants?
Then you have a few dozen ids in a list. Is this a problem?
8:41 a.m.
Council has voted to accept that and it had my +1. (Editor will do his
job shortly)
I just want to state for the record that my vision for fixing this
problem has always been to make a MUC mode where messages are coming
from room/occupant-id which I kinda want for multiple reasons anyway
and then we could just reuse 0191.
That would mean that we can do server side blocking and not even have
the messages delivered that we don’t want to show anyway.
cheers
Daniel
10:26 a.m.
On Tue, 7 Apr 2026 at 16:42, Daniel Gultsch <daniel(a)gultsch.de> wrote:
I just want to state for the record that my vision for
fixing this
problem has always been to make a MUC mode where messages are coming
from room/occupant-id which I kinda want for multiple reasons anyway
and then we could just reuse 0191.
Quite so.
https://github.com/xsf/xeps/pull/1527
Dave.
8 Apr
8 Apr
9 a.m.
On Tue, 7 Apr 2026, 16:42 Daniel Gultsch, <daniel(a)gultsch.de> wrote:
Council has voted to accept that and it had my +1.
(Editor will do his
job shortly)
I just want to state for the record that my vision for fixing this
problem has always been to make a MUC mode where messages are coming
from room/occupant-id which I kinda want for multiple reasons anyway
and then we could just reuse 0191.
That would mean that we can do server side blocking and not even have
the messages delivered that we don’t want to show anyway.
While I also find the potential for protocol use attractive, the XEP cites
many reasons that client-side works better than server-side for this
feature.
Personally I never use mute/ignore in clients these days, largely because
no matter how annoying someone is, there are inevitably conversations where
I need to see their messages in order to piece together a conversation.
In other words, the XEP was designed this way on purpose, not purely
because of the lack of occupant IDs in JIDs.
Regards,
Matthew
20
days inactive
27
days old
8 comments
5 participants
participants (5)
-
Daniel Gultsch -
Dave Cridland -
Goffi -
Matthew Wild -
Stephen Paul Weber