What to check before you install a client

Two clients can speak the same core protocol and still feel a decade apart. The RFCs hand every client the same stanzas and addresses; what separates a current client from a dated one is the extensions it speaks with its server. Before you install anything, one extension name is worth more than a feature list: Message Archive Management, XEP-0313, the mechanism that decides whether your conversations follow your account or stay on whichever device happened to be open.

Why does one client feel older than another?

XEP-0313, written by Matthew Wild and Kevin Smith, holds the Stable status on the ladder from Experimental to Final that every extension climbs. Three scenarios shaped the design, all serving one desire: messages kept in a central archive on the server. Automatic history synchronisation between multiple clients comes first, so a new device opens on your past conversations instead of an empty log. Next is calendar based, on demand display of history in a client that keeps none of its own. Last comes what the specification calls "infinite" scrollback, older messages arriving naturally as the log is scrolled back in time. A client that supports none of this still conforms to the RFCs, and behaves as though the account had no memory.

What the server keeps

An archive, as the XEP-0313 text defines it, is the set of messages tied to one XMPP address, most often a user, sometimes a MUC room. For users it lives on the bare JID, where a server must expose it; a room’s archive sits on the room’s bare JID. What gets in is deployment policy, with one stated expectation: meaningful content is kept, state changes such as Chat State Notifications are not. Each stored message holds at least a timestamp, the remote JID, the stanza itself, and a server assigned identifier that must be unpredictable and unique within the archive. The whole stanza should be kept; the minimum is the body element with the standard attributes.

How a client asks for its history

The query travels as an iq stanza of type set, the request shape among the three stanzas, with a query payload inside. The server answers by pushing matching messages in chronological order, then closes with a fin element naming the first and last identifiers of the batch, the anchor a client uses to page through a long history. Paging rests on Result Set Management, XEP-0059, which both sides must support. An optional queryid attribute ties each arriving message back to the query that asked for it.

Six filters and one form

Filters travel in a data form with a hidden FORM_TYPE field naming the extension’s namespace. Six fields are defined, and servers must support all six: start and end bound a timespan, with picks a correspondent, while before-id, after-id and ids work from identifiers the client has already seen. A server offering those last three must advertise an extended feature, which dependent clients must check for first. In a user archive the with field matches either the to or the from address, and a bare JID also matches its resources. Ask for an identifier the archive does not hold, and the answer is an item-not-found error.

What happened to the older archiving extension?

An earlier extension, Message Archiving, XEP-0136, covered the same ground. Implementation experience showed it carried rather more functionality than the usual needs and cost significantly more effort to build, so the newer protocol was written to be simpler and modular. Four features were dropped on purpose: collections, upload into the archive, per-session configuration, and an off the record mode, unrelated to the encryption algorithm of that name. The last is the telling one. The old mode let a user ask a contact’s server to bypass the archive, but nothing could enforce the request; the other server could archive the messages anyway. The newer specification declines to regulate what it cannot enforce, an honest drawing of where a protocol’s power ends.

The identifier that follows a message

When a message is archived the server must stamp it with a stanza-id element, defined in XEP-0359, whose by attribute names the archive: the account’s bare JID, or the room’s for MUC. Servers must not place it on messages addressed to JIDs with no right to read the archive, an outgoing message to a contact, say, but should place it inside messages forwarded through Message Carbons, XEP-0280. A version caveat separates the letter of the specification from older software: earlier versions said nothing about stanza identifiers, and a client must not treat a XEP-0359 identifier as an archive identifier unless the server advertises urn:xmpp:mam:2 specifically.

Deletion, and what no protocol can promise

A server may cap an archive and discard messages, and whatever it deletes must be the oldest: holes in the middle are forbidden, and a deleted message’s identifier is never reused. To pull sensitive material out of the middle, a server may blank out the stanza in its answers, but must keep the identifier, timestamp and JID internally so every query stays consistent. The specification then states its own limit: it offers no mechanism for forcing a message out of a local copy a client keeps. A server can hide a stanza from its answers; what a device already holds stays out of reach.

The check before installing is small. Find the client’s supported extensions and look for urn:xmpp:mam:2, then the server’s advertised features for the same string. When both sides speak it, history travels with the account and a new device opens on your past conversations. When either side is silent, every device keeps a log of its own from the first day, and no polish in the interface will join them up.

xmpp.org publishes the numbered XMPP extensions. Each page carries the title and abstract, the authors, the status on the ladder from Experimental to Final, and the full text: the requirements behind the protocol, the rules servers and clients must follow, and worked examples of the stanzas.