SamWhited|blog

XMPP logo

In search of XMPP perfection

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 use1.

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.

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:

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 Android2.

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.


  1. Facebook is a notable exception to this that refuses to federate with the public network. ↩︎

  2. The Conversations logo was used for the thumbnail on this post and was designed by Diego Turtulici↩︎