Lonewolf v0.3.0 adds XMPP federation and direct TLS support

The maintainers of the Lonewolf XMPP server have released version 0.3.0, a significant update that introduces server-to-server federation capabilities. Published on November 13, 2026, this release allows isolated Lonewolf instances to communicate with users on other XMPP networks, marking a major step toward interoperability for this self-hosted communication platform.

What happened

The most notable addition in this release is federation, which enables Lonewolf servers to exchange messages, presence information, IQs, and roster subscriptions with external XMPP servers. This feature activates automatically if the host possesses a valid certificate and a public DNS name, requiring no additional configuration from the administrator. The system authenticates peer servers exclusively through certificates, requiring the remote server to present a trusted certificate and support SASL EXTERNAL. Notably, Lonewolf does not support the older Server Dialback mechanism for authentication.

When both servers support it, they establish a single shared connection for bidirectional traffic, adhering to XEP-0288. Additionally, servers exchange their stanza size and idle limits upfront via XEP-0478 to optimize resource usage. To ensure security, Lonewolf checks certificate revocation lists (CRLs) published by the Certificate Authority, fetching them over plain HTTP. If a CRL cannot be downloaded, the connection proceeds regardless, though administrators can disable these downloads or point to local files using specific configuration flags.

Beyond federation, the release introduces direct TLS support for both clients and servers, allowing encrypted connections from the first byte as defined in XEP-0368. New dedicated listeners handle these connections, and outbound federation discovery now identifies both STARTTLS and direct TLS endpoints. The update also improves compatibility with desktop clients by enabling Private XML Storage for settings and bookmarks, as well as Software Version queries that identify the server without revealing the underlying operating system unless explicitly configured.

Key details

• Federation is enabled by default for hosts with a public DNS name and valid certificate, relying solely on certificate-based authentication.
• Direct TLS (XEP-0368) is supported via new dedicated listeners, allowing encryption from the initial connection byte.
• Certificate revocation lists are fetched over plain HTTP, but connections proceed even if these lists are unavailable.
• SCRAM-SHA-512 authentication is available as an opt-in feature, though it stems from an expired Internet-Draft rather than an official RFC.
• Enabling SHA-512 changes how credentials are stored, making rollback to version 0.2.0 difficult for affected accounts.
• The benchmark tool has been renamed from lonewolf-bench to lonewolfbench, requiring updates to any existing build scripts.

Background

XMPP, or Extensible Messaging and Presence Protocol, is an open standard for real-time communication that powers many self-hosted chat systems. Federation is a core concept in XMPP, allowing different servers to interoperate much like email providers do. Without federation, users on one server can only communicate with others on the same instance, creating isolated silos. Enabling federation requires robust security measures, such as mutual TLS authentication, to ensure that servers trust each other before exchanging user data.

Direct TLS differs from the traditional STARTTLS method, where a connection begins in plaintext and is later upgraded to encryption. With direct TLS, the encryption handshake occurs immediately, reducing the attack surface associated with initial unencrypted data exchange. This is particularly relevant for modern security standards that discourage any plaintext transmission, even briefly. Self-hosted administrators must manage certificates carefully to maintain these secure connections, especially when dealing with short-lived certificates from providers like Let's Encrypt.

Why it matters

For teams running their own communication infrastructure, the ability to federate breaks down isolation barriers. Previously, adopting Lonewolf meant committing to a closed group of users within a single server. Now, organizations can maintain control over their data while still collaborating with partners, clients, or community members on different XMPP servers. This flexibility is crucial for small and mid-sized companies that want sovereignty over their tools without sacrificing connectivity.

However, the security model relies heavily on proper certificate management. Since Lonewolf authenticates peers only via certificates and fetches revocation lists over plain HTTP, administrators must ensure their TLS infrastructure is robust. The change in credential storage for SCRAM-SHA-512 also introduces a migration risk. Teams experimenting with stronger authentication methods must be aware that rolling back is not straightforward, potentially locking them into the new version for affected user accounts.

What you can do

• Verify that your server has a valid public DNS name and trusted TLS certificate to enable federation automatically.
• Review your configuration to decide whether to disable CRL fetching or use local files if plain HTTP downloads are a concern.
• Update any build or deployment scripts to reference lonewolfbench instead of the previous lonewolf-bench name.
• Test desktop client compatibility by ensuring Private XML Storage and Software Version queries are functioning as expected.
• Exercise caution when enabling SCRAM-SHA-512, noting that it changes password storage formats and prevents easy rollback.
• Monitor certificate expiry closely, especially if using short-lived profiles, as Lonewolf will renew early when profiles change.