Jabber routes messages and presence between servers run by different parties, with no central authority and without forcing clients to speak the same proprietary protocol. The reference server, jabberd, is at version 1.x and has run on jabber.org since 1999; release 1.2, from October 2000, introduced dialback, the mechanism that now holds the network of independent servers together (https://xmpp.org/about/history/). I am collecting here the notes I took while reading the protocol, with one question in mind: can you build a service on top of it?
Context
In 2001, instant messaging is a collection of silos. AIM, ICQ (both AOL), MSN Messenger and Yahoo! Messenger use closed, undocumented protocols, and each one demands its own client. Interoperability, where it exists, is a by-product of reverse engineering that the vendor breaks at the first server update. Anyone wanting to offer presence and messaging as a service — a portal, a carrier, a corporate intranet — has to pick a closed platform and accept its terms.
Jabber goes the other way: an open protocol, in XML, with a free server (jabberd, under a Jabber Open Source License / GPL arrangement) and several independent clients and libraries. Jeremie Miller announced the project in early 1999; the 1.0 server release of May 2000 stabilised XML streaming, messages, presence and contact lists (https://xmpp.org/about/history/).
Architecture
The client opens a single long-lived XML stream to its server, and the fragments — stanzas — flow inside it. The stream opens with a root <stream:stream> tag, and from then on each top-level element stands on its own: <message/>, <presence/>, <iq/> (info/query). The stream stays open for the whole session; there is no HTTP request/response per event, and that is what makes real-time presence notification cheap.
A user’s address takes the form node@domain/resource. The domain identifies the server, exactly like the right-hand side of an e-mail @; the resource distinguishes simultaneous connections of the same account (say work and home). It is a name resolved over DNS against the server’s domain, not an opaque handle assigned by a vendor: anyone who controls a domain can host their own users.
Presence is information the server propagates. When I connect, the server sends a <presence/> to every contact who holds a subscription to me; each state change (away, dnd, chat) is a fresh <presence/>. The contact list — the roster — lives on the server, under the jabber:iq:roster namespace, so it follows me to any client: it is not a local file.
The critical part
What makes Jabber a network rather than an archipelago of islands is server dialback, which arrived with jabberd 1.2. When a.example receives, from one of its users, a message addressed to someone@b.example, it opens a server-to-server connection to b.example and has to prove it really is a.example — otherwise anyone could inject messages while claiming any domain.
Dialback solves this by leaning on DNS. In outline: a.example sends b.example a key derived from a secret and from the two streams’ identifiers; b.example does not trust that connection, but opens its own one to the domain a.example resolved over DNS and asks it to confirm the key. If the confirmation arrives on the channel b.example opened itself, then the sender really does control DNS for a.example. It is weak authentication — it ties server identity to DNS security rather than to a certificate chain — but it needs neither a certificate authority nor bilateral agreements, and that is what grew the server network without a central registry (https://xmpp.org/about/history/).
Gateways to the closed networks
Jabber does not pretend the proprietary networks are not there: it wraps them. A transport (or gateway) is a component that connects to the Jabber server on one side and speaks the legacy protocol on the other — there are transports for AIM, ICQ, MSN, Yahoo! and for non-IM services such as IRC and e-mail. From my client, an MSN contact shows up as an ordinary Jabber address on the gateway’s domain (say 12345@msn.gateway.example), and messages reach it through the same stream I use for everything else.
Registration runs through jabber:iq:gateway and jabber:iq:register: I lodge my legacy-network credentials with the transport, and from then on the gateway keeps the proprietary session open on my behalf and translates presence and messages in both directions (https://jabber.org/). The cost is structural: the gateway is a point of concentration, it has to hold other people’s credentials, and it chases the same undocumented protocols by reverse engineering — when AOL changes its server, the transport breaks until someone updates it.
Implications for building a service
For a carrier or a portal wanting to offer messaging, Jabber shifts the question. It is no longer “whose platform is it”, but “who runs my domain”. I can run jabberd on my own infrastructure, hand out addresses on my domain, federate with the rest of the network via dialback, and meanwhile give my users gateways into the networks where their contacts already are. Streaming XML also lends itself to extension — a custom iq namespace carries arbitrary application data inside the same channel — and opens the way to integrations such as notifications or SMS bridges, built as server components without touching the core. It is on exactly this pattern — jabberd plus an SMS module towards the mobile networks — that noze is building Community with SARITEL, and describes the design in an insight (https://www.noze.it/en/insights/community-jabber-saritel/).
Limits
Three cautions, given the project’s current state. First: dialback authenticates the server, it does not encrypt traffic — confidentiality between servers is not guaranteed by the mechanism, it must be layered on top. Second: the specification lives as protocol documentation and jabberd source, not as a standard ratified by a third party; adopting today means accepting that some details may change once standardisation matures. Third: gateways inherit the fragility of the networks they wrap, and depend on the goodwill — or the tolerance — of the proprietary vendors, who have no interest at all in being interoperated with.
What holds up, and is why I keep following it, is the model: addresses anchored to DNS, independent servers that federate, presence propagated by the server, extensions carried in the same stream. The same choices that made e-mail a network rather than a product.
https://xmpp.org/about/history/ https://jabber.org/
Cover image: Official Jabber project logo: a stylized red and yellow light bulb icon — logo by Jabber Software Foundation, CC BY 2.5 — https://commons.wikimedia.org/wiki/File:Jabber-bulb.svg