search

esl / MongooseIM

MongooseIM is Erlang Solutions' robust, scalable and efficient XMPP server, aimed at large installations. Specifically designed for enterprise purposes, it is fault-tolerant and can utilise the resources of multiple clustered machines.
Other
1.67k stars 428 forks source link

xmppbl.org - Real-time blocklists for XMPP #3997

Open Neustradamus opened 1 year ago

Neustradamus commented 1 year ago

Dear MongooseIM team,

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

It exists already for:

Thanks in advance.

arcusfelis commented 1 year ago

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 commented 1 year ago

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

arcusfelis commented 1 year ago

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:

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 commented 1 year ago

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.