Status update on mod_mam

Hello users!

Last night I performed maintenance to disable mod_mam archives by default (along with the few other things).

This means that messages are not archived by default on the server, and are only archived if your XMPP client specifies that they should be. The MAM module has one major flaw right now. It cannot purge archives fast enough. It seems to get stuck and it kept the messages for much longer than it was supposed to. Due to this, during the maintenance I have purged all MAM archives from the server. Security, privacy and transparency are all my number one priorities when it comes to the server. When I enabled MAM on the server I had to consider the benefits vs the trade-offs. I believe we’ll be better off with MAM disabled by default, because a lot of clients don’t even support it yet.

If you can have any questions, feel free to reach out!

~ Lunar

New Years Announcement

Hello users!

I haven’t made a post in a while, so I figured I’d make one about what’s going on with XMPP.is. First of all, Happy New Year! 2018 has been a great year for the server and I’ve received $135 USD in donations via PayPal. Thank you to all the donors, you are what helps keep this server running. Thank you to the few who donated cryptocurrency as well! Since there hasn’t been many posts, here are some things I’ve accomplished last year…

  • I made numerous improvements to the server’s configuration, adding support for many new XEPs and becoming 100% compliant according to this compliance tester. I’ve made several improvements to the server’s scripts and even added a few. You can see every change I’ve made on GitHub. Open source is the best 🙂
  • I’ve updated a lot of pages on the site, adding more info and descriptions.
  • I’ve tried to keep downtime to a bare-minimum. With the new hypervisor things have been more stable than ever. I’ve also improved on scheduling maintenance windows and giving notice beforehand.

Now onto 2019…

Recently I’ve been working on cleaning up registered users. We currently have over 37,000 registered users. Many years ago before I had web registrations and captchas in place, a nefarious individual/group registered over 35,000 accounts en-masse. A lot of the accounts follow a pattern (which I won’t disclose). I am working on cleaning up these users and deleting them, as they’ve never been used (as far as I know). This is a long and drawn out process as I have to make sure the accounts I’m deleting are not legitimate.

I’ve made a couple one-liner scripts in bash to find these accounts based on the pattern in their usernames that I’ve noticed. While it work 95% of the time, it also picks up legitimate users and I have to manually filter them out from the deletion lists. I’ve been going through the lists when I make them and taking out any users that look legitimate. As this is a manual process I might miss a few here and there… If your account gets deleted and you notice you can no longer login, please let me know. I can restore it from encrypted, off-site backups. Keep in mind that these usernames are very uncommon. They are probably taken from a word list and random numbers are added to them.

If you have any questions, feel free to reach out!

~ Lunar

Why We DO NOT Fully Support “The Jabber Spam Fighting Manifesto”

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

2018 Status Update

Hello users!

A little late… but Happy New Year!

I wanted to post about some recent changes that XMPP.is underwent this past few months.

  • mod_cloud_notify (XEP-0357: Push Notifications) support has been added. twitter.com/xmpp_is/status/946592338607996928
  • The security page has been updated with more details about how we care for your data.
  • Non-standard ASCII characters in usernames are no longer allowed when registering. People could potentially impersonate other users for malicious purposes. See: twitter.com/xmpp_is/status/954729573173940224
  • We now have a fair (in my opinion) TOS/AUP.
  • The 2018 donation goal has been created. I lowered it this year to cover at least domain costs, and a little more. Thank you to all that donated USD and crypto-currency!
  • The donation page has been updated with our hard-coded crypto-currency wallet addresses. If you’d like to donate with any of those, please opt for the ones we provide (more privacy).

Offline Messages Are Back!

Hello users!

Offline messages are now back after a short maintenance window yesterday. After speaking with a user that thought offline messages are very important, and much needed for instant messaging services.. I fully agreed and decided to enable the module again after the attack we underwent a few months ago. Despite the shortcomings of the offline messages module in Prosody, I believe this to be important. Previously, if you were offline, even for a short period of time, messages could be lost. This would obviously be annoying, as pretty much any modern IM service will just store messages server-side until the user is online. So.. In the meantime hopefully things hold up. In the meantime I will have systems constantly monitor everything server-side to alert me of any potential issues.

In other news.. I’ve patched Tor packages on the server due to the recent CVE‘s. I’m also continuing to research new modules (been busy) that I can add to support more XEPs. The following are on my list for testing: