Why mobile XMPP is harder than desktop

A desktop client opens its XML stream in the morning and holds it open until evening: mains power, steady link, no harm in sitting idle between messages. A phone enjoys none of this. Its streams are cut by network outages, it spends long stretches with no client online, and its owner still expects every message that arrived in between to be waiting on the screen. Mobile XMPP is not harder because the protocol changes on a phone; it is harder because the assumptions underneath it stop holding. Two extensions carry most of the extra weight.

A stream that expects to stay open

XMPP keeps an XML stream open between a client and a server and pushes small, well formed pieces of XML down it. Everything the user sees is built from three stanza types sent over that one stream. Presence is where disconnection bites first. A connected client broadcasts presence to its contacts; the moment the stream ends, that state is gone, and the next connection must rebuild it along with a fresh copy of the roster. A desktop does this once or twice a day. A phone may be asked to do it far more often.

What happens when the stream dies?

The core specification, RFC 6120, defines how a stream is established and torn down, authentication and encryption included, but it offers no tools for actively managing a live stream. XEP-0198, Stream Management, fills that gap, and its premises read like a list of mobile problems. Streams are terminated unexpectedly, with network outages given as the example, and re-establishing one the ordinary way repeats the whole ceremony of stream establishment, roster retrieval and presence broadcast, a sequence the specification itself calls tedious. Stanza acknowledgements and stream resumption answer this, running through short elements at the root stream level: not stanzas, never counted, never acknowledged themselves.

Counters, not receipts

The acknowledgement machinery is deliberately small. Either party may send an <r/> element asking the other to account for itself, and the reply is an <a/> element carrying a single attribute, h, the count of stanzas handled. The word handled carries a precise meaning: the server has accepted responsibility for the stanza, to process it directly, deliver it locally or route it towards a remote server. Until a stanza is affirmed as handled, it stays the sender’s responsibility. Each side keeps two counters, one for stanzas sent and one for stanzas handled, and a sender never has to pause for an ack. These acks are also distinct from Message Delivery Receipts, XEP-0184, whose acknowledgements travel end to end over multiple streams, a contrast the stream management specification draws in its own introduction.

Resuming instead of starting again

A client asks for resumption when it enables stream management, by setting a resume attribute. A willing server replies with an identifier, the SM-ID, an opaque token the client must not read meaning into, though the server may encode the client’s full JID inside. After a break, the client opens a new connection, negotiates TLS, authenticates, then asks to resume rather than start, quoting the old identifier and stating how many stanzas it handled. The server replies with its own count, and those figures settle exactly what must be resent, eliminating duplication through replay. If the stream is not resumed in time, the session state may be discarded, and the server treats unacknowledged stanzas like any message to an unavailable resource: an error, another connected device, or offline storage.

Why can’t the server simply wake the phone?

When no client is online at all, neither acks nor resumption help, because there is no stream left to manage. Push notifications, XEP-0357, address the other half of the problem: informing a user of new messages even when no XMPP client is running, typically as a notice on the device that invites the owner to reopen a client and continue the conversation. The extension exists because earlier arrangements by mobile client vendors carried drawbacks the specification lists bluntly. Some treated the client and the server as one unified service, so notifications worked only with the official client. Others proxied the user’s session through the provider’s backend services to monitor for and trigger pushes. The goal is the general case instead: any client against any server, with notifications travelling through services the client’s vendor controls.

Two tiers, no shared credentials

The architecture involves two hops rather than one. The user’s server publishes a notification to the push service belonging to each client application, a service the specification defines as a profile of XMPP publish-subscribe. That service then hands the notice to a third-party delivery service, the platform-dependent one that can actually reach the device. The server therefore reaches clients it has never heard of, and each client uses the delivery mechanism its platform expects without sharing private keys or other credentials with the XMPP server. Notification nodes use a whitelist access model, with a publish-only affiliation reserved for the user’s server and bare JID.

Two questions for any mobile client

Neither extension shows its face on a phone screen, which is why both belong in the questions worth asking before you install a client. Does it enable stream management with resumption, so a dropped connection costs one short exchange instead of a full rebuild? Does its notification story follow the push extension, or does it tie the account to one vendor’s client? The two pages carry different statuses on xmpp.org, and the gap tells its own story: stream management at Stable, push notifications at Deferred. Open both, read the section on unacknowledged stanzas and the one on whitelists, and judge the client against the source rather than the screenshot.

xmpp.org

The XMPP Standards Foundation publishes the numbered extensions on xmpp.org. Each page names its authors, states a status from Experimental to Final, and carries the full specification text; the two pages this article draws on sit there together.