Jabber and XMPP: a protocol you can read
A plain reading of Jabber and XMPP: opening a session, the three stanzas, how a JID is built, and how presence and rosters hold a contact list together.
- Published: 10 September 2026
- Editorial guide
- By Editorial Desk
Jabber, now called XMPP, is an open messaging protocol built on XML streams, and you can read it as a sequence of small, named events rather than as a product. A client opens a session by negotiating a stream with a server, then sends three kinds of stanzas: message, presence and IQ. Everything else, your contact list, your online status, your subscriptions, is built from those three pieces and from the address format called a JID.
The protocol is documented in the RFCs, and a guide such as the Presence & Protocol guide walks through the same material from the client and server side. What follows is a reading of the mechanics, in the order a session actually happens.
What happens when a client opens a session?
A client starts by opening a TCP connection to its server, usually on port 5222, and sending an opening stream tag that names the domain it wants to reach. The server answers with its own stream tag and a list of features it supports. From there the two sides negotiate what they will use: TLS for the transport, then SASL for authentication, then a fresh stream once the encrypted channel is up.
After authentication the client binds a resource. A resource is the specific connection, so the same account can be logged in from a phone and a laptop at once. The server assigns or accepts a resource string, and the full address becomes something like [email protected]/phone. Only then does the client ask for its roster, the stored contact list, and begin sending presence.
This order matters when you are debugging. A stream error before authentication is a transport or TLS problem. A failure after binding is usually about the roster or about a stanza the server did not expect. Reading the session as a fixed sequence of steps turns a vague connection problem into a specific one.
The three stanzas: message, presence and IQ
XMPP keeps its traffic to three top level elements, and each has a different job.
A message stanza carries content meant for a person or a room. It has a type, such as chat or groupchat, a to address, and a body. The protocol does not guarantee delivery or ordering, and it does not require a reply. If you want to know whether something arrived, that is a separate mechanism.
A presence stanza announces availability. It says whether you are online, away, or unavailable, and it can carry a short status text. Presence is broadcast to the contacts who are subscribed to you, which is why a status change is visible to others without anyone asking.
An IQ stanza, short for info/query, is a request and response pair. It has an id so the reply can be matched, a type of get, set, result or error, and a payload defined by a namespace. Roster management, version queries and many extensions ride on IQ. Because it expects an answer, IQ is where most protocol extensions do their work.
Once you can tell these three apart, a raw XML log stops looking like noise. Message is content, presence is state, IQ is a question with an answer.
How is a JID built?
A JID, or Jabber ID, looks like an email address and is put together from up to three parts: a localpart, a domainpart, and an optional resource.
The localpart is the account name, the part before the @. The domainpart is the server, the part after it. The resource comes after a slash and identifies a particular connected client. So in [email protected]/phone, user is the localpart, example.org is the domain, and phone is the resource.
A bare JID has no resource, and it refers to the account as a whole. A full JID includes the resource and refers to one specific session. This distinction is practical: a message to a bare JID may be delivered to whichever resource the server chooses, while a message to a full JID goes to that exact connection. Presence is usually sent from a full JID and stored against the bare one.
Domains are compared case insensitively, and the localpart is normally treated the same way in practice, though the specification leaves room for case sensitive handling. When an address fails, check the three parts separately rather than retyping the whole thing.
How do presence, rosters and subscriptions hold a contact list together?
Your contact list in XMPP is not stored on your device alone. It lives on the server as a roster, and each entry in it has a subscription state that describes the relationship between you and that contact.
The subscription states are none, to, from, and both. If you are subscribed to a contact, you receive their presence. If they are subscribed to you, they receive yours. Both means the exchange goes in each direction, which is the normal state for two people who have accepted each other.
Getting to that state takes a handshake. You send a subscription request, the other person approves it, and the server updates both rosters. Until that approval happens, you may see the contact in your list but not their availability. This is why a contact can appear offline for a long time without anything being broken: the subscription was never completed, or it was later revoked.
Presence itself is not stored forever. The server keeps the last known presence for each connected resource and passes changes to subscribed contacts. When you disconnect, your resources go unavailable and that change is broadcast. The roster, by contrast, persists, because it is account data rather than session state.
What changes when you run your own server?
Running a server such as ejabberd, Prosody or Openfire means you own the domain part of every JID you hand out, and you are responsible for the DNS records and the TLS certificate that make federation work. Other servers reach yours by looking up the domain, so a missing or wrong record shows up as a contact who can never connect, not as an error message on your side.
Federation is the point of the design. Your server talks to other servers directly, without a central service in the middle, which is why the same protocol has carried public chat, private messaging and extensions such as OMEMO encryption and multi user chat rooms. The trade is that you now maintain the pieces a hosted service would have maintained for you.
Why read the protocol at all?
Most people never need to. A client hides the stanzas, and that is fine. But when something does not work, the difference between a message that was never delivered and a presence subscription that was never approved is the difference between two completely different fixes.
Reading XMPP as a protocol also makes the vocabulary clearer. A JID is an address with three parts. A stanza is one of three kinds of event. A roster is server side data with a subscription state attached. None of this requires memorizing the RFCs, only knowing which layer you are looking at.
If you type for a living, the same habit applies here as in a drill: work at the level of the smallest unit, and let the larger behavior follow. In typing that unit is the keystroke. In XMPP it is the stanza.
The details above follow the published source directly: opening a session, the three stanzas, how a JID is built, and how presence and rosters hold a contact list together. If you want to check the wording yourself, the primary reference is the XMPP core specification (RFC 6120), which sets out the session opening, the stanza types, and the address format in the protocol's own terms. Reading it slowly, one section at a time, is a good habit for anyone learning to read technical documents with care.