Lonewolf 0.3 adds certificate-authenticated federation to Rust XMPP server

Federation built on certificates

Lonewolf, a standalone XMPP server written in Rust, has shipped version 0.3.0 with certificate-authenticated server-to-server federation, direct TLS support and a batch of new XMPP extensions. According to the release notes published on GitHub, a link that is currently on Hacker News' front page, the project remains pre-1.0 and single-node, with full XMPP compliance and clustering still on the roadmap.

The headline change is federation. Lonewolf can now exchange messages, IQs, presence and roster subscriptions with other XMPP servers, and hosts with configured certificates and public DNS names federate by default.

Authentication takes a strict path: peers must present trusted certificates and authenticate with SASL EXTERNAL, while the older Server Dialback mechanism is not supported. Bidirectional connections (XEP-0288) let compatible servers share a single connection, and Stream Limits Advertisement (XEP-0478) lets federation peers exchange stanza and idle limits up front.

Direct TLS and client-side extensions

Direct TLS (XEP-0368) adds dedicated client and server listeners and combines STARTTLS and direct-TLS discovery for federation. On the client side, Private XML Storage (XEP-0049) now stores private client settings and legacy bookmarks, and Software Version (XEP-0092) answers domain-level software queries, with operating system disclosure off by default. Both extensions ship enabled by default.

Authentication gets one notable addition: opt-in SCRAM-SHA-512 and SCRAM-SHA-512-PLUS. The release notes are candid that these implement an expired Internet-Draft rather than an RFC or IANA-registered mechanism. There is an upgrade caveat as well: account creation and password changes write credentials that older Lonewolf binaries cannot read, even when SHA-512 login is disabled.

Operational changes

Several defaults and tools changed with operators in mind:

• Federation checks CA-published certificate revocation lists over plain HTTP by default. Downloaded CRLs tolerate unknown revocation status; operators can disable fetching with s2s.tls.fetch_crls = false, or point s2s.tls.crls_path at a local file, which is then used exclusively.
• A letsencrypt.certificate_profile setting selects a CA-advertised profile, including short-lived certificates, and profile changes trigger early renewal.
• The default client stanza limit drops from 512 KiB to 256 KiB.
• Traffic byte counters now include TLS handshake and record overhead.
• The benchmark executable and crate have been renamed from lonewolf-bench to lonewolfbench.

Building and maturity

The project builds on Linux or macOS with a stable Rust toolchain and a system linker, via cargo build --release --locked -p lonewolf -p lonewolfctl -p lonewolfbench. It is licensed under Apache-2.0. The maintainers describe it as a pre-1.0, single-node server for now; a standards reference documents supported roles and limits, and full compliance plus clustering remain roadmap items.

Why it matters

Self-hosters who want to run their own chat infrastructure have a short list of realistic XMPP servers, and the long-standing options such as Prosody, ejabberd and Openfire are large codebases in Lua, Erlang and Java respectively. A compact Rust server offering memory safety, direct TLS and working federation is a meaningful alternative for a small VPS, especially now that federation is enabled by default if you have a certificate and a public DNS name.

The choices are opinionated in ways operators should understand before deploying. Dropping Server Dialback means interoperability rests on peers supporting certificate-based SASL EXTERNAL, the SHA-512 mechanisms are draft-grade, and the plain-HTTP CRL default is worth reviewing against local security requirements. As a pre-1.0 project it is best treated as promising rather than production-ready, but this release moves it quickly toward the feature set self-hosters actually need.