XMPP Service Operators - 2026-04-24

I have just released version 1.4.0 of muc_banbot. https://github.com/envs-net/muc_banbot/releases/tag/v1.4.0 An excerpt from the release announcement: ### New Features * Configurable Command Prefix: All room commands now use a configurable `COMMAND_PREFIX` instead of a hardcoded `!` * GitHub Release Update Checks: Periodic background checks for newer GitHub releases with automatic admin-room notifications * Manual Update Check Command: New `checkupdate` command to manually check whether a newer release is available * Command Pagination: `banlist [page]` and `room list [page]` now support paged output for large result sets (> 10) * Extended Config Output: `config` now shows command prefix and version-check settings * Extended Status Output: `status` now shows the latest released version

https://upload.envs.net/file_share/019dbfbe-a8dd-7081-9547-dffdb8f164fa/41b6a28e-11df-4815-bb30-5557253b3ded.png

XMPP doesn't need bots, moderation can be server side

Because every channel moderator is a server operator, right?

Hmm.. contains copilot code...

> XMPP doesn't need bots, moderation can be server side Yes, but that requires you to run a server and for the MUC to be on that server. ↺

With this bot, you can control multiple MUCs at once, regardless of whether they are on your own server or not. The bot only requires admin permissions in the MUC. Another nice feature is that when the bot first enters a room, it reads all existing bans from the MUC, transfers them to the database, and then applies them to all MUCs that the bot has designated as "Protected".

This way, you have all the bans from your "Protected" mucs in the database, and no one can escape you. And if you do happen to get a user's JID, you simply ban the nickname. The bot will then automatically retrieve the JID when it finds the nickname (when the nickname enters the room).

> Hmm.. contains copilot code... Damn, I'll probably end up removing it from queer spark later today then ↺

> Because every channel moderator is a server operator, right? Well maybe the server operator could be nice and include the things the admins need? Then the admins can manage it themselves of course ↺

individually managed cross channel banlists is not something that any xmpp server supports. there isn't even a xep for that yet.

Doesn't sound like the kind of thing that would benefit from a xep. Also we already have this with eg rtbl. Just lacks options in current implementations for admins to set what lists to use etc I guess

in combination with spaces it would make sense to standardize that in a xep, IMHO.

and RTBL isn't nearly fine grained enough for that, and I say that as someone that is actually using it for that because there are no good alternatives.

Maybe. I'm pretty against writing XEPs for every single button. Can you imagine if we needed a W3C decision for every new thing a website did? But maybe after the code is written and deployed a worthwhile xep will be discovered and written

> and RTBL isn't nearly fine grained enough for that, and I say that as someone that is actually using it for that because there are no good alternatives. It's per jid. How much more fine grained could it get? ↺

sure a xep should go hand in hand with a reference implementation.

> It's per jid. How much more fine grained could it get? the problem is setting it up and managing it. I don't want to run an individual RTBL for the 20 spaces I have on my server. ↺

and adding entries to it is again a bot, so we are back at having a moderation bot with extra steps

for each of the 20 spaces I mean ✏

Better tools for setup and management would be good yeah. I wonder if people would be interested in a simple push button receive rtbl app or similar

I though you wanted to share it between the spaces just what the bot does too

I think if RTBL would allow setting a reference channel where it copies the bans from that would help already. that way you can use standard client features to ban people.

I mean rtbl is basically the database a bot uses, but on pep, and a module to apply it. The bot could even use it too and contribute to it

the moderation bot mentioned above does that btw.

> I though you wanted to share it between the spaces just what the bot does too no I want a ban list per space, cross channel, but space specific. ↺

and managed by the space admin and not the server admin

> I think if RTBL would allow setting a reference channel where it copies the bans from that would help already. that way you can use standard client features to ban people. Sure that would be easy in a couple ways ↺

For sure. Nothing should ever be managed by server admin of course. Early implementations sometimes are just because lazy

> XMPP doesn't need bots, moderation can be server side says the opposite 😅 ↺

at least as long as there isn't a much more advanced server side setup to allow doing that without the involvement of the server admin

I think a part of the issue some have with this is, one could just develop a server module with the same time one uses to develop a bot. A module that _is_ usable by all channel operators. Well I think open source devs can do what they like with their time. While I can see elegance if it were a server module

> Hmm.. contains copilot code... Thanks for the warning.