xmppbl.org - Real-time blocklists for XMPP

[Neustradamus]

Dear MongooseIM team,

It is possible to add the Real-time blocklists for XMPP?

• https://xmppbl.org/

It exists already for:

• ejabberd: https://www.process-one.net/blog/ejabberd-23-04/ + https://docs.ejabberd.im/admin/configuration/modules/#mod-muc-rtbl
• Prosody IM: https://modules.prosody.im/mod_muc_rtbl
• Openfire: https://www.igniterealtime.org/projects/openfire/plugin-archive.jsp?plugin=mucrtbl

Thanks in advance.

[arcusfelis]

Not a high priority, it is very niche application.
Barely documented, not an official XEP.
PubSub for this is a bit of overengineering.
How would it behave with a long list of blocked users?

Besides, not many people expect MUC groupchats to be used in 2023.
Could be done later once we wanna invest time in spam detection infrastructure and logic (i.e. XEP-0377 or something custom). But again, we would probably have to evaluate usage with gigantic lists. Removing the spammer account could be preferable for installations, which do not use s2s. Also, integration with mod_privacy could be considered (but again, there is no clear usage model even for mod_privacy, which would fit the modern requirements).

[Neustradamus]

@arcusfelis: It has been added in ejabberd since 23.04:

• https://www.process-one.net/blog/ejabberd-23-04/
• https://docs.ejabberd.im/admin/configuration/modules/#mod-muc-rtbl

[arcusfelis]

I know.
https://github.com/processone/ejabberd/blob/ffbcf19156b5808e0640193ee8439a9a01354c87/src/mod_muc_rtbl.erl

It is literally non-scalable. It uses broadcasts to ALL online MUC room processes on each pubsub update.
So, if list updates are too often it would lead to DDoS.

And it does not look like it will scale with large number of blocked items. With larger number of items we:

• have to copy more data into into the room processes.
• starting having scalability issues with the number of items inside of a single node in pubsub.

In the public environment it means that the spammer could register millions of spam accounts on a public server that allows it and we don't have control over that. And we would have to block the whole domain (which would block the regular users too) or not block them at all.

[arcusfelis]

We could optimize kicking (so, no broadcasts to all rooms) but it still leaves us with the issue of the maximum number of items we can block over PubSub. Scalability characteristics of Pubsub is more interesting topic though. Can we write 1M items into a single node? Something to test first.