FIELD GUIDE
Jabber and XMPP: Open Messaging Explained
Jabber, now XMPP, is an open XML streaming protocol for messaging. Its stanzas, JIDs, servers and history, explained for observers and tinkerers.
Start with the useful answer
Jabber is an open messaging protocol built on XML streams, standardised since 2004 under the name XMPP. It defines how a client opens a session, exchanges three kinds of stanzas, and addresses users through a JID. Anyone can run a server, and any server can federate with any other, which is the property that separates it from closed messaging platforms.
What is Jabber, and what is XMPP?
Jabber is the original name of the protocol, and XMPP is the name it took when the IETF published it as an open standard. The two words refer to the same system. The core is documented in RFC 6120 for the XML streams and RFC 6121 for instant messaging and presence. A session begins with a stream to the server, a TLS handshake, and SASL authentication. After that, the client and server exchange three stanza types: message, presence, and IQ. A message carries content, a presence stanza announces availability, and an IQ stanza handles requests and responses, such as a roster fetch or a version query. Addresses are JIDs, written in the form user@domain/resource. The domain part identifies the server, and the resource distinguishes two connections of the same account, for example a phone and a laptop. Presence is not a side feature. It is the mechanism by which contacts learn who is online, and it is governed by subscription states: none, to, from, and both. A roster is the contact list stored on the server, and each entry carries one of those states. This design is old and stable, and it is why a client written in 2005 can still talk to a server deployed last week. A guide such as Presence & Protocol covers the same ground from the protocol side, including the three stanzas and the JID construction, at the Jabber protocol guide.
How does a message travel from one client to another?
A message travels in three hops. The sending client writes a message stanza into its XML stream to its own server. That server resolves the domain of the recipient JID, opens a server-to-server stream if one is not already open, and forwards the stanza. The receiving server delivers it to whichever resource is connected, or stores it if the account has offline storage enabled. Each hop is a separate stream, and each stream is authenticated. Server-to-server links use dialback or SASL, and TLS is expected on both client-to-server and server-to-server connections. The DNS records that make this work are SRV records, specifically _xmpp-client._tcp and _xmpp-server._tcp, plus A and AAAA records for the host. Without correct SRV records, a server cannot be found by other domains, and federation fails silently from the user's point of view. This is the part that most often breaks in a self-hosted deployment. A message stanza can carry a body, a subject, a thread identifier, and extensions. Extensions are defined as XEPs, the protocol's extension documents, and they are how features such as delivery receipts, chat state notifications, and file transfer are added without changing the core. The core stays small on purpose. Everything optional lives in a XEP, and clients negotiate what they support through service discovery, which is itself an IQ exchange.
Which servers and clients are used in practice?
The server side has three long-standing implementations. ejabberd is written in Erlang and is common in larger deployments. Prosody is written in Lua and is known for a small configuration file. Openfire is written in Java and ships with an administrative web interface. All three implement the core RFCs and a large set of XEPs, and all three require a domain name, a TLS certificate, and the SRV records mentioned above. The client side is broader. Desktop clients exist for Linux, macOS, and Windows, and mobile clients exist for Android and iOS. Mobile constraints matter: a phone cannot hold a persistent TCP connection indefinitely, so mobile clients rely on push notifications, which requires a server-side component to wake the application. This is the single largest practical difference between XMPP and a closed platform, where the push path is handled by the platform owner. Encryption is handled by OMEMO, an extension that provides end-to-end encryption across multiple devices using the double ratchet. OMEMO is not part of the core protocol. It is a XEP, and both ends must support it for a conversation to be encrypted. Group chat is handled by MUC, the multi-user chat extension, and by MIX, a newer design that separates the group from the individual presence of its members.
What is the history of the Jabber name and the standards?
The protocol began as jabberd, a server written in the late 1990s, and the name Jabber was a trademark held by a company. The IETF working group produced the first XMPP specifications in 2004, and the name XMPP was adopted for the standard while Jabber remained in use for the community and the older software. The XSF, the XMPP Standards Foundation, manages the XEP process. A XEP starts as a proposal, goes through review, and reaches a status such as Draft, Active, or Final. Some XEPs are deprecated, and clients are expected to drop them. The JabberPowered badge dates from 2003. It was a small graphic that a server operator could place on a website to indicate that the server was open for registration. The badge carried a licence and conditions of use, and it is now a historical marker rather than an active programme. The protocol itself has not changed its core since 2004. What has changed is the set of extensions around it, and the number of servers that federate by default.
Is open messaging still relevant?
Yes, and for a specific reason: federation. A user on one server can message a user on another server without either party creating an account with a third company. That property is rare in consumer messaging, and it is the reason the protocol survives in public administration, in some universities, and in communities that prefer to run their own infrastructure. The trade-offs are real. Federation means that server operators are responsible for their own uptime, their own certificates, and their own spam handling. Mobile push requires extra components. End-to-end encryption requires both clients to support the same extension. None of this is hidden, and none of it is new. The protocol's documentation is public, its extensions are public, and its reference texts are the RFCs. For a reader who wants to verify a detail, the primary sources are RFC 6120, RFC 6121, and the XEP index maintained by the XSF.
How does this fit an observing log?
An observing log records conditions, instruments, and results. A messaging setup can be recorded the same way: the domain, the server software and version, the TLS certificate expiry, the SRV records, the client and its version, and the extensions in use on each side. When a message fails to arrive, the log narrows the fault to one hop. When a certificate expires, the log shows the date before it happens. This is the same discipline as noting seeing, transparency, and the instrument used. The subject differs, the method does not. Both XMPP and watercolor reward the same habit: build in layers and let each one dry before the next. A stanza arrives, the server routes it, the client renders it. A wash goes down, the paper dries, the glaze goes over it. Rushing either step produces the same result, a muddy surface that hides what you meant to show. Observers who keep a fieldbook for protocol traces often keep one for pigment too. The notes on watercolor washes and glazing cover flat and graded washes, layering, and fixes for blooms, which is the same discipline of patience applied to paper.
Source note. Practical context is checked against the primary and specialist records in our source register, then bounded by the methods recorded on the methodology page.