The What and Why of Open IM

David Chisnall explains how and why you should use XMPP to “jabber” with your online pals.

About 10 years ago, several of my friends started talking about a new thing
that was like email, only faster and better suited to short messages. Like the
telephone system, it assigned everyone a unique number. The system was developed
by a company called Mirabilis, and was called ICQ (I Seek You).

There were a few problems with ICQ. The biggest was the fact that it stored
your contact list on the client, so if you used multiple machines (or
reinstalled your operating system), then you lost your contacts. There were also
a lot of issues with early versions of the client. But it was clear from the
start that this new method of communication was likely to catch on quickly.
While email gave you an electronic version of a letter, ICQ provided something
closer to an electronic multiplayer Post-it note.

Soon other suppliers, most notably Microsoft, AOL, and Yahoo!, began
releasing their own ICQ clones, and the generic term of "instant
messaging" became popular. Because ICQ used a proprietary protocol,
however, there were a growing number of incompatible networks. Imagine a world
in which users of Hotmail could send email only to other people using Hotmail,
Yahoo! Mail users could send email only to other Yahoo! users, and so on. This
scenario is somewhat similar to the situation before the Internet, when bulletin
board systems had their own mail systems. Gradually, interoperability among
systems was added, and finally standards such as SMTP emerged, easing this
interoperability.

In 1998, a project began to provide an open source IM transport layer—a
transparent interconnect between IM systems. Very quickly, the idea evolved into
building a complete IM system with support for gateways to proprietary services.
The project, known as Jabber, produced its first major release in 2000,
with the 1.0 version of the server.

Jabber was based around the same network topology as email, and Jabber IDs
look very much like email addresses. Each user of the Jabber network connects to
his or her own server, just as users of the email network connect to their own
mail servers. This server forwards messages to the recipient’s server, if
required, just as a mail server does. This setup makes the Jabber network quite
resilient; a single server failure affects only the users of that particular
server. I’ve seen the MSN network go down a few times in the last year or
so, but I’ve never heard anyone talk about the email network breaking,
because for that to happen would require every mail server in the world to
fail.

Standard and Support

The Jabber protocol was standardized by the IETF as the Extensible Messaging
and Presence Protocol (XMPP) in 2004. In addition to the core standard are a
number of XMPP Enhancement Proposals (XEPs), which define extensions for
services such as file transfer, VoIP session initiation, sharing vCards,
etc.

One of the first large companies to support XMPP was Apple, which introduced
iChat, an IM client that worked with AOL’s proprietary network. With OS X
10.4, Apple also added support for communicating with a Jabber server. Perhaps
more interestingly, the server version of OS X bundled a Jabber server, allowing
a Mac-using company to deploy an IM network easily for internal use.

Apple is a relatively small player, and its support for XMPP wasn’t
very enthusiastic. In 2006, however, the protocol gained a much more dynamic
backer—Google. The Google Talk IM platform was based around XMPP, using a
client and server written by Google. While a number of open source server
implementations are available, none of these met Google’s requirements.
These requirements were never stated explicitly, but I imagine that supporting a
few million users on a single domain was fairly high up on the list.

At the time of Google Talk’s release, no real consensus existed about
the best way to handle features such as voice chat on the XMPP network. A few
proposals were presented, some suggesting a simple ad hoc stream negotiation
system, some suggesting wrapping SIP. Google Talk implemented its own protocol
for this purpose.

Although the protocol was designed to be extensible, adding proprietary
extensions on public servers isn’t encouraged. Google chose not to do
this, releasing its stream-negotiation protocol, JINGLE, to the community, where
it was approved by the standards group. Google also released libjingle, the
library used to set up these connections, under a (three-clause) BSD license to
encourage adoption.