Proposed XMPP Extension: Occupant Mute Synchronization
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.
URL: https://xmpp.org/extensions/inbox/xep-occupant-mute-sync.html
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.
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@xmpp.org To unsubscribe send an email to standards-leave@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
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?
Le mardi 7 avril 2026, 17:08:42 heure d’été d’Europe centrale Stephen Paul Weber a écrit :
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?
- 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.
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?
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.
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
On Tue, 7 Apr 2026 at 16:42, Daniel Gultsch <daniel@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.
On Tue, 7 Apr 2026, 16:42 Daniel Gultsch, <daniel@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
participants (5)
-
Daniel Gultsch -
Dave Cridland -
Goffi -
Matthew Wild -
Stephen Paul Weber