I’ve got the suggestion several times that we should ‘force the use of OTR!’ I don’t like the practice by other servers such as riseup.net (sends you warnings over and over) and calyxinstitute.org (specifies that they force it) for several reasons. Whether you can’t send messages if you don’t use OTR or get notices from the server every time you send a message without OTR, I believe it’s bad practice.

• It forces users into adhering to a specific plugin.

I feel like this is a bad idea. I believe the choice should be left up to the user like most things. If there are better alternatives than OTR already (OMEMO) or ones that come out in the future, it’s silly to force users to use something specific. It’s not built into every client by default like TLS is. And many users may want to use their own plugin that they develop, PGP or OMEMO.

• It’s annoying.

Who wants to get spammed with messages from the server like, “you aren’t using OTR!!!!” or to just get their outgoing messages blocked simply because they don’t fit the OTR format? Being forced to use OTR, and when you don’t, getting punished via spam for it is annoying. Rather, users should be nudged to use end-to-end encryption through announcements or blog posts.

• OTR currently has some annoying downsides.

OTR, unlike OMEMO doesn’t seem to work well when you have multiple devices and doesn’t work with offline messages. Below is a great comparison of different plugins.

Source: conversations.im/omemo/

As it stands, XMPP.is does not support “The Jabber Spam Fighting Manifesto” for various reasons. It stands in the way of those looking for anonymity/privacy, and spam can be easily mitigated client-side. Certain measures should NOT be applied server-side. The decision to block incoming requests, messages, notices should be left entirely up to the user. Push development for more anti-spam plugins! The notion of blocking all servers that do not comply with the policy is silly. XMPP should not function like email, and there is no need to build RBLs like mail servers commonly use. If you do not want to receive spam, simply do not accept all incoming messages from people that you do not authorize to communicate with. Blocking servers and users server-side is dangerous and breaks XMPP federation. It centralizes. And it creates the potential for censorship.

In the next part of this post we’ll go over the different policies for this manifesto.

Provide an abuse contact according to XEP-0157: Contact Addresses for XMPP Services and react to incoming abuse reports in a timely fashion.

— We will fully abide by this and support for XEP-0157 has been added in our config in the latest commit.

Limit the number of new user registrations per IP address and hour.

— We may support this in some fashion, at least the per hour part.. Although this seems too strict, it could hinder those using Tor or VPNs from registering (assuming multiple users use the same exit point). Limiting the amount of registrations per IP would prevent many from signing up.

Monitor and review registrations from IP addresses with bad reputation (open proxy servers, Tor exit nodes), or enforce additional checks on those users, like a CAPTCHA or a valid phone number.

— We absolutely do not support the first part. We do not restrict registration based on an IP addresses reputation, and will not. Ever.. A CAPTCHA is necessary however, and we have implemented this (a simple one) some time ago. We will never ask for or require a phone number, that’s just silly..

Throttle the traffic from local clients, especially unsolicited subscription requests and messages.

— We already do this in some fashion with mod_limits. It’s 100% necessary to stop huge DDoS by spam attacks. We’ve witnessed several cases where offline messages can be abused, and mod_limits has helped a lot. However, unsolicited actions can be mitigated client-side.

Example of plugin to mitigate spam: github.com/cockroach/pidgin-privacy-please

Archived link of the manifesto: archive.fo/kVobO