jdev - 2026-05-10

https://upload.envs.net/file_share/019e103d-29f4-7a0b-92aa-a5f25fe68db5/7e0b67a8-c05a-4ca8-9ee9-16849d88766e.png

i think it works fine now ;)

https://github.com/envs-net/muc_banbot

I can't imagine why one bot would want information from both of those lists?

I get the question. mod_muc_rtbl is great for server-side enforcement, and I’m not trying to replace it. The reason I added RTBL support to muc_banbot is that the bot is also a moderation workflow tool, not only an enforcement layer.

With RTBL in the bot, admins can: * see RTBL-sourced bans in `!banlist rtbl` * search them via `!bansearch` * get admin-room announcements when RTBL entries are applied * keep an audit trail of what was applied, when, and from which source * combine RTBL with the bot’s local ignorelist/whitelist * automatically unban RTBL-derived bans again when entries disappear from the source list * consume RTBL feeds published by other bots or communities, not only a server-local Prosody module setup

muc_banbot adds visibility, auditability, search, admin UX, and integration with the existing ban-management workflow. In my setup, I may still use `mod_muc_rtbl` for direct server-side blocking, but I also want muc_banbot to understand and expose the RTBL state so room admins can see what is happening and why.

Right. But what is it using spam source domains for? That data isn't really MUC relevant?

muc_banbot supports domain blocking because disposable accounts from the same abusive domain keep appearing in my offices. In this case, a domain-based RTBL entry can be helpful to stop a spam wave early on. If you subscribe to the list, you also have the option to whitelist individual entries so they are not banned.

Basically, I subscribed to the list first in order to build and test the bot feature. ;)

basically just doing it the matrix way

https://upload.envs.net/file_share/019e1277-9f9b-7444-a683-3ac5142055d7/d0b9d404-6649-4331-a625-9e329ab0432f.png

https://upload.envs.net/file_share/019e1278-40ff-71d6-a845-31f75d143344/df826090-bc32-482e-8ecf-faa8383890bf.png

https://upload.envs.net/file_share/019e1278-d6f5-78eb-af5b-69f1413f67e0/209e01a9-dee6-49fe-bf84-eeae178af63c.png

just to give a little insight

https://pb.envs.net/?62c23117f26bd205#93Su99evhLnnE2ssAuYZoRXjgqAKxoqko34w56AyRQfi this is an excerpt of the bot helpage.

Another nice feature is that muc_banbot imports existing bans from protected MUCs into its local/regular ban database and then sync those bans across the other protected rooms. So it is not just RTBL enforcement. It also helps keep local moderation state consistent across multiple rooms, including bans that were originally added manually by room admins.

I mean, a domain banning system makes sense of course. But that's not really what spam_source_domains is

So basically banbot is supposed to be a substitute for space-wide banning?

Honestly would just be better as a Prosody module

We have the prosody module, but some people prefer a bot. That's fine everyone is entitled to preferences 🙂

As I said, I mainly used the list to implement and test the feature. Now that it works, you can use the feature to subscribe to other domain-ban nodes with the bot or publish your own domain bans node.

https://upload.envs.net/file_share/019e1295-8a7b-74d6-a06d-9c5433646507/c63cd244-107c-4fc0-a7d0-c0bbc7928b3a.png

I also plan to build the bot itself as a Prosody module. But that will take some time before I implement. I first need to finalize how exactly I'm going to do that.

I've only been using XMPP for the envs.net project for three months now. Before that, we used Matrix for chat because I unfortunately made the wrong decision years ago. But I'm more than happy to have finally landed in the XMPP world.

I confess I haven't read all XEP-0060, but do I understand it right that affiliations can be retrieved both by the `http://jabber.org/protocol/pubsub` and `http://jabber.org/protocol/pubsub#owner` namespaces? cf https://xmpp.org/extensions/xep-0060.html#example-26 and https://xmpp.org/extensions/xep-0060.html#example-197

also, <https://xmpp.org/extensions/xep-0060.html#example-27> is broken, right? ```xml <iq type='result' from='pubsub.shakespeare.lit' to='francisco@denmark.lit' id='affil2'> <pubsub xmlns='http://jabber.org/protocol/pubsub'> <affiliations> <affiliation node='node6' affiliation='owner'/> </affiliations> </pubsub> </iq> ``` …should be ```xml <affiliations node='node6'> <affiliation jid='hamlet@denmark.lit' affiliation='owner'/> ... </affiliations> ``` instead, right?

ping edhelas and goffi I guess =)

Ralph once printed out the whole of XEP-0060 at a Summit, back when we had them at Cisco. I think that's why him and Edwin starting bringing a van.

in any case, that example 27 I printed either looks very wrong, or I don't get how anything is supposed to work xD

Sorry, what's the question?

oooooh I did not get that

Affiliations are in both namespaces because #owner can retrieve everybody"s affiliation, user its own ✏

oooh then example 27 is probably fine

At a glance, I agree. Ex27 is wrong.

ah?

Oh...

Wait.

Affiliations are in both namespaces because #owner can retrieve everybodys affiliation, user its own ✏

wait indeed

Affiliations are in both namespaces because #owner can retrieve everybody's affiliation, user its own ✏

Right, no it is correct.

Compare with Ex23.

Ex 23 looks good to me

oh ok ok I get it.

I don't see many pubsub service implement that (Libervia Pubsub does)

there is no configuration to allow non-owners to retrieve affiliation lists?

but it's really useful to see your own affiliations across the whole service

well, right now, movim for spaces issues a retrieve-affiliations with pubsub#owner for 👩‍🚀 space nodes 🌌

I've not followed the backlog here, but doing that you see (if you are owner) who is member, outcast, etc. of this node

yes, thanks, there was no more backlog :)

so, if you're not an owner, you're not supposed to be able to retrieve affiliations, but I guess it's not completely illegal to allow non-owners to retrieve all affiliations for a node, is it?

You can only retrieve your own if your are not owner (IIRC)

hmm right: > If the requesting entity is not a node owner, the service MUST return a <forbidden/> error.

I'm not sure if protocole wise it's doable, but regarding privacy it's not great anyway

What do you want to achieve here?

well that's not great. slidge will be a bit illegal here, if the bridged service lets you see who is in a space, slidge will not reply "forbidden"

You want to see who subscribed to a space right?

I'm implementing retrieving the "affiliations" of a space node, it's fine, I was just wondering if I got things right from reading the spec, which I did not, so I'm fixing that now. :) I wonder if this "MUST reply forbidden" could become a SHOULD

If so, that's what PPS is for: https://xmpp.org/extensions/xep-0465.html . It's clean, and privacy-aware (it's opt-in)

good! thanks for the pointer.

The main issue is that it's not compatible with generic pubsub, as you will need PAM (XEP-0376) to use it. For Slidge, I suppose that you can implement that as you already use delegated namespaces.

Wait, actually forget it, you can't implement PAM like that, that would hijack the normal PAM used if implemented. I need to think a bit more about that, I don't really have the time right now.

I'm going incremental and want to have something basic working with a client that has UI for it, so I'm starting simple for now.

I don't have to worry much about access control, if an action is not authorised, it is the bridged network's responsibility to return forbidden-like errors :) But ofc it's always nicer to advertise to clients in advance what they are supposed to be able to do!

Thanks a lot.

nicoco: sure. The problem if you start to do illegal stuff, is that other clients will do the same to be compatible, and it will be a mess to fix eventually.

Note that I may implement spaces sooner than later, at least with CLI.