Skip to content
Presence & ProtocolAn independent guide to Jabber and XMPP

Layer 03 · Servers

Servers: running a federated node

Choosing between ejabberd, Prosody and Openfire, publishing the right DNS records and getting both encrypted hops, client to server and server to server, on.

A small rack-mounted server in a home office, status lights on, network cable plugged in.

A federated network has no centre, which means the interesting decisions belong to whoever runs a server. Which implementation to install, what to publish in DNS so other servers can find yours, and what is actually encrypted on each of the two hops a message takes. This layer is written for the person doing that work, and it is deliberately specific about the places where a small mistake produces a server that looks fine and federates with nobody.

In this layer

  1. Three small servers lined up on a workbench, each with a different handwritten label taped on.

    ejabberd, Prosody, Openfire: how they differ

    All three speak the same protocol. Choosing between them is a question of what you are willing to operate.

  2. A terminal window on a dark screen showing a short list of DNS lookup results, keyboard in shot.

    The DNS records a federated server needs

    Most federation failures are DNS failures. The records are short, the rules are written down, and the order matters.

  3. Two patch cables crossing on a grey panel, connectors in focus, port numbers printed beneath.

    Encryption on the wire: c2s, s2s and TLS

    A message crosses at least two connections. They are secured separately, and only one of them is under your control.

Every essay in this layer is written against the reference page on the three stanza types, and two neighbouring layers extend it: Protocol and History.