Introduction

Ever since signing Peter Saint-Andre’s excellent manifesto on ubiquitous encryption on the XMPP network, I’ve been wondering what to do about the vast majority of my contacts who are still using the broken “Google Talk” implementation of XMPP. Among the stipulations of the manifesto is a 2014-05-19 cutoff date for permanently upgrading to an encrypted network. Unfortunately, I was on the trail at this time and wasn’t able to properly test / upgrade my personal XMPP server. Now that I’m back, I decided to arbitrarily set my own upgrade date for this Friday (2014-10-24). However, my roster comprises mostly non-technical people who don’t want to host their own server, download confusing clients with a million options, etc. making the job of finding an XMPP server which I can recommend to them difficult. They want something that will “just work”. They don’t care about all the encryption mumbo-jumbo I just mentioned, they don’t care about OTR and PGP private keys, and they certainly don’t care about client/server authentication mechanism agreements and what XEPs are supported by each. These sorts of things are good to implement, but the layman doesn’t need (or want) to know about them. Below are some criteria which I think a major XMPP node needs to adopt to make XMPP usable by the general public.

Layman

XMPP. Even if you don’t know what it is, you probably use it in your day to day life. Whether you use Facebook Chat, Google Talk (not Hangouts), or DuckDuckGo’s chat platform, you’re actually using an XMPP account (sometimes called Jabber) to chat.

The nice thing about XMPP over other chat networks such as Google Hangouts, Skype, AIM, etc. is that XMPP is federated. This means that you can use it to talk to your friends on other networks. If you have a GMail, it doesn’t mean you can’t send email to your friend with an account at Yahoo, or Outlook. Similarly, with XMPP, you can add your friends no matter what network they use¹.

XMPP isn’t complicated to use, but it could be easier. There follows a list of features which I think all XMPP service providers who are aimed at lay users should implement. Some providers already implement one or more of these features, and some providers implement next to none of them.

• Clients should be able to add and chat with friends from any other network
• Sent messages should show up on all of your connected devices (phone, tablet, web interface etc.)
• Users should be able to temporarily block individual contacts (without removing them from their roster)
• Service providers should provide a web client (possibly integrated with any other service they provide, think GMail with Google Talk)
• Contacts should be able to send files back and forth
• Avatars should be synced between all connected devices
• Connections should save bandwidth on expensive wireless internet plans (but always receive your messages, even when the phone is asleep)
• Connections should not fail when switching between networks (eg. Wi-Fi to mobile data)
• When you’re on your laptop, notifications should not appear on your phone (though the messages should still be delivered to both devices)
• Chat rooms should be supported

Technical

When Google announced that they were discontinuing XMPP support in favor of their new proprietary system, “Hangouts”, they cited many of the issues mentioned above as reasons for developing their own proprietary messaging system. What they failed to address is that all of the above features are already part of the XMPP standard. The problem isn’t that mechanisms for implementing these features don’t exist, the problem is that server operators just don’t turn them on, and clients just don’t implement them. With that in mind, I make the following minimal suggestions for server operators and client implementers:

• Enable TLSv1, 1.1, and 1.2 using a trusted certificate (disable legacy SSL)
• Accept several secure cipher suites (preferably with perfect forward secrecy) for both s2s and c2s connections. For server to server connections I currently support:
  • ECDHE-RSA-AES256-GCM-SHA384 FS
  • ECDHE-RSA-AES256-SHA384 FS
  • ECDHE-RSA-AES256-SHA FS
  • DHE-RSA-AES256-GCM-SHA384 FS
  • DHE-RSA-AES256-SHA256 FS
  • DHE-RSA-AES256-SHA FS
  • DHE-RSA-CAMELLIA256-SHA FS
  • ECDHE-RSA-AES128-GCM-SHA256 FS
  • ECDHE-RSA-AES128-SHA256 FS
  • ECDHE-RSA-AES128-SHA FS
  • DHE-RSA-AES128-GCM-SHA256 FS
  • DHE-RSA-AES128-SHA256 FS
  • DHE-RSA-AES128-SHA FS
  • AES256-GCM-SHA384
  • AES256-SHA256
  • AES256-SHA
  • CAMELLIA256-SHA
  • AES128-GCM-SHA256
  • AES128-SHA256
  • AES128-SHA
  • CAMELLIA128-SHA
• Enable federation with other servers in the network
• Support message carbons (XEP-0280)
• Support blocking contacts (XEP-0191)
• Support (and provide) a web based client
• Support PEP for syncing avatars (XEP-0163)
• Support stream management (XEP-0198)
• Support sending files both in-band and out-of-band (XEP-0047, XEP-0065, XEP-0066)
• Support roster versioning to save bandwidth on mobile connections (XEP-0237)
• Support client state indication to save more bandwidth on mobile connections (XEP-0352)
• Support MUC (XEP-0045) and ensure client implementations are easy to use
• Support SCRAM-SHA1 and SCRAM-SHA1-PLUS for authentication

And that’s it. It may sound like a lot, but keep in mind some of these are the responsibility of the server while others are in the client’s domain. Not to mention that most of these features are already available in popular XMPP libraries.

If you know a public server that supports a decent subset of these, I’d love to hear about it. As for clients, I especially like Gajim on the desktop, and Conversations (source) on Android².

UPDATE: As far as public servers go, wtfismyip.com seems to be decent. Its in-band registration was broken for me, but it has web-based registration as well. It supports publishing avatars via PEP, and stream management, but no message carbons (sadly).

UPDATE 2014-10-22: I’ve just discovered jabber.zone (a property of jabber.at This is hands down the best public server I’ve found (note that I have not been testing it long enough yet to know if the uptime is good). It supports almost all of the important things I mentioned above (CSI excepted). It even has a webchat implementation (though it’s currently difficult to use unless you have a normal jabber.at account). Passwords are also stored in the clear, but they’re very upfront about this and a patch to enable SCRAM is currently being tested at one of their other properties, jabber.wien .

All this means that jabber.at (or jabber.zone if you need DNSSEC, or jabber.wien if you want better password security right away) is hands down my recommendation for a public XMPP server at the current time.

CORRECTION 2014-11-09: An earlier update said that jabber.wien did not store passwords as plaintext. The folks behind this server have just let me know that passwords are currently still stored as plaintext there due to an issue with the protocol and the way that Ejabberd handles VHOSTS.

UPDATE 2014-11-26: jabber.at and jabber.zone have now fixed the password storage issues and are no longer storing plaintext passwords. See their blog post for details.

UPDATE 2017-07-17: DuckDuckGo and wtfismyip.com have shut down their public XMPP servers. jabber.wien is also being shut down, but jabber.at now has the patches that jabber.wien was testing. jabber.at remains my recommendation.