The What and Why of Open IM
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.