XMPP federation: verify interoperability and deployment end to end

Current status — 18 September 2026

The server-to-server implementation now exists in service/chat/xmpp_s2s.go, including inbound/outbound streams, dialback and TLS handling. The original claim that there is no jabber:server implementation is obsolete. End-to-end interoperability with an independent server and production DNS/TLS/listener configuration remain unverified, so this issue stays open. No protocol traffic was sent during cleanup.

What is true today

service/chat speaks jabber:client and nothing else. There is no
jabber:server, no dialback, nothing listening on 5269. Conversations, Dino,
Gajim and the web client can all connect to a Mu account — that part works, and
scripts/xmpp-check.sh passes 11/11 against micro.mu.

But two Mu instances cannot talk to each other, and neither can Mu and any other
XMPP server. asim@micro.mu cannot message someone@anotherserver.org. Chat is
a single island.

This was overclaimed in conversation as nearly-federated. It is not. The XMPP
work shipped a good server for clients, which is a different thing from a node
on a network.

Why it matters

Mail already federates. Anyone on earth can write to an agent here and the agent
writes back, with no account on either side — that is a real network, running
today. So the product is already "a network for humans and agents" through SMTP,
and XMPP is the half that does not join in.

One identity, you@yourdomain, reachable two ways, with the agent reachable at
the same address, is the thing nobody else has: every federated network has only
human participants, and every network with agents in it is a silo.

What it takes

• jabber:server streams on 5269, alongside the existing client streams
• Dialback (XEP-0220) or SASL
  EXTERNAL with real certificates — how two servers prove who they are
• TLS between servers, and outbound connection management per remote domain
• _xmpp-server._tcp SRV records — which is #1470. Federation is what makes
  that issue worth doing rather than a convenience.

Well-trodden work; not small.

Ordering

Federation, then DNS (#1470), then the connect pages. The connect pages should
describe a network rather than an island, and written today they would document
the island.

Not in scope

Server-to-server is not the same as the web client being a general XMPP client.
That is a separate question — the PWA speaking RFC 7395 to other servers as a
client — and it does not give you@micro.mu an address anyone else can reach.

Start with service/chat/xmpp_s2s.go and review the existing inbound/outbound stream, dialback, and TLS handling, then inspect scripts/xmpp-check.sh and issue #1470. Done means successful end-to-end interoperability with an independent XMPP server and verified production DNS, TLS, and listener configuration.