Rocket.Chat Labs #2: Delivering federation as a built-in standard, not a custom stack

Federation lets different organizations communicate directly, server to server, without routing data through a vendor's cloud. For customers in defense, government, and critical infrastructure, it is what makes cross-organization collaboration possible without leaving the sovereign or restricted environments they have already accredited. 

For those organizations, Rocket.Chat enables built-in Matrix federation that meets the operational, security, and compliance requirements they work under. Messaging, voice, video, AI, governance, and federation under one roof. One platform to procure, deploy, and operate. No additional homeserver to stand up. No bridge to maintain. No collaboration stack to assemble around it. That’s what makes Rocket.Chat a valuable choice for organizations looking to enable Matrix federation.

Rocket.Chat Labs is where we open up the engineering work behind our federation journey. For this edition, we will walk you through the early federation vision, the trade-offs of the previous approach, what changed when we rebuilt it inside the server, and what is coming next.

The problem federation is actually solving

A commander needs to coordinate with an allied agency in real time. A government team needs to bring a contractor into a working channel without exposing the rest of their environment. A response unit needs to share situational updates with a partner organization sitting in a different jurisdiction, on a different network, under a different set of rules.

The default fallback in every one of these scenarios is the same: email, a consumer messaging app, or a personal account on a public SaaS platform. All three move sensitive data outside the organization's control. All three sit outside the audit, retention, and access controls the organization has accredited. In high-assurance environments, that is not a usability problem. It is a compliance and mission risk that audit teams flag and procurement teams reject.

Federation closes that gap, with each side keeping its own identities, policies, retention rules, and infrastructure.

Matrix has been part of Rocket.Chat for years

Federation has been part of the Rocket.Chat vision since the very beginning. The reference point was always email: an open, decentralized network where anyone can run a server and any server can reach any other.

“Any company building a communication platform to use internally will eventually need to talk to other organizations. A company cannot exist in isolation. The vision was always a network of Rocket.Chat servers speaking the same language and sending messages between them, the same way email works.”
— Gabriel Engel, CEO

The first attempt was to build that protocol ourselves. We stopped when it became clear that a credible federation protocol needs a community around it, not a single vendor maintaining it in isolation. Around five years ago, we adopted Matrix as the federation protocol for Rocket.Chat. 

Since then, we have been running Matrix federation in production. We built and shipped bridge integrations, ran them with real customers, and learned where the protocol gives us room to customize and where the bridge architecture imposed operational cost. That experience also shaped what Rocket.Chat ships. 

Where the bridge approach stopped being enough

For years, Rocket.Chat connected to Matrix through a bridge. The bridge worked. It moved messages between a Rocket.Chat server and an external Matrix homeserver and translated between the two data models on the way through. For early customers who needed cross-organization rooms, it was the fastest path to federated communications. 

It was also a workaround, and the architectural ceiling was real.

A bridge meant running a second piece of backend software, maintained by a third party, alongside Rocket.Chat. It meant a second database (Synapse does not support MongoDB, and the upstream project was not open to contributions to add it). It meant teams needed expertise in two stacks. And it meant the federation behavior of Rocket.Chat was bound by what someone else’s homeserver was willing to do.

“We were dependent on a third-party backend. That brings a limitation for anything that company decides to do. If you talk directly to the protocol, you have the freedom to decide how you implement things, how you handle custom events, and how your data structure evolves. We always wanted to be more on the protocol and less on someone else’s software.”
— Rodrigo K. Nascimento, CTO

“We looked at lighter-weight options. The most promising was to import pieces of Dendrite, an alternate Matrix homeserver written in Go, as a library inside Rocket.Chat. That plan ended when upstream development on Dendrite was deprioritized and the project lost the maintenance trajectory we needed.”
— Guilherme Gazzo, Head of Architecture

Choosing Matrix as a federation protocol is one decision. Choosing what to deploy on top of it is a different one. For the customers we serve, that second decision is where most of the operational reality lives.

Many Matrix-based offerings focus on a homeserver, a client, or both, and the customer pieces together the rest of the collaboration platform around them. We wanted to treat it as a core capability and provide a full collaboration stack: messaging, voice, video, AI, integrations, governance, and federation, in a single platform under one operational model. 

At that point the call was clear: the bridge had to go, and so did the external homeserver behind it.

Built-in, not bolted on: owning the federation stack

The shift we made was architectural. Instead of running Matrix as a parallel stack alongside Rocket.Chat, we implemented the protocol as a library that runs inside Rocket.Chat as a single process. No second backend. No second database. No conversion layer between data models. The federation engine is part of the server, not bolted to it.

“Matrix is the federation protocol of Rocket.Chat. Rocket.Chat and the federation engine run together as a single process. No extra dependencies, no extra deployment, no second backend in the middle. We built it as a library so it stays modular, but from the operator’s point of view, it is just Rocket.Chat.”
— Guilherme Gazzo, Head of Architecture

What that looks like in deployment: three things sitting on top of each other inside one process. The Rocket.Chat service, the native federation engine running as an embedded library, and MongoDB as the shared database. The federation engine runs on the same port as the rest of Rocket.Chat. Federation traffic between two Rocket.Chat clusters moves over REST APIs that speak the Matrix protocol.

Rocket.Chat native federation across three clusters. The federation homeserver runs as an embedded library inside each Rocket.Chat process, against the same MongoDB. Server-to-server traffic flows over the Matrix protocol.

What changed once the protocol moved inside the stack?

We own the deployment shape

A Rocket.Chat server with federation is one piece of software with one database, deployed the way every Rocket.Chat customer already deploys. Air-gapped, on-premises, sovereign cloud: the federation layer inherits the deployment posture of the platform, instead of adding a parallel stack with its own operational requirements.

We own the roadmap

When a customer asks for a behavior the upstream protocol does not cover, we can decide how to handle it. Contribute back to the protocol. Use a custom event. Add a server-side capability that lives on top of federation. 

Scalability was an early input, not a late patch

The architecture is built for the customers driving the requirements: defense organizations, government agencies, and critical infrastructure operators running federated rooms across coalitions, agencies, primes, and partners. Mission-critical communication is the deployment profile that shaped the design.

“The first features we built into the federation engine were not protocol features, but queues and throttling. Cross-server message flow under load is the most common way federation deployments fall over, and we wanted that resilience on day one rather than added under pressure later.”
— Guilherme Gazzo, Head of Architecture

One engine, one platform

The same Rocket.Chat process that delivers messaging, voice, video, AI, integrations, and governance also delivers federation. There is no second service to operate alongside it, no second database to maintain, and no integration layer between the federation engine and the rest of the platform. That matters for the customers driving this architecture. In their environments, a second stack means a second accreditation, a second operations team, and a second failure mode.

Native federation supports two deployment patterns from the same engine. The most common is Rocket.Chat to Rocket.Chat: two organizations both running the platform, federating directly server to server. The same engine also supports federation with other Matrix homeservers and clients, including any standards-compliant Matrix implementation. Organizations can federate within their Rocket.Chat estate and across the broader Matrix ecosystem from a single deployment, without running separate stacks or changing platforms.

The journey from the first demo to production 

Alpha: the architecture stood up

The alpha validated that the new architecture could stand. 

The hardest part during alpha was protocol state. Matrix events arrive in a chain, and each event carries a state that validates who can do what. If a single event lands in the wrong order or a field is built incorrectly, the room can enter a state it cannot recover from. The room becomes unusable. We spent two days during alpha hardening chasing exactly that class of bug and refactoring the engine so it could not accept an invalid sequence in the first place.

“We had to ensure events were processed in the correct order, with the right field validation, every time. A risk of two clients silently dropping out of sync was high. The alpha had to give us minimum confidence that this would not happen in front of an audience.”
— Rodrigo K. Nascimento, CTO

A related honesty point. The existing Matrix test suite is written in Python. Our implementation is not. We could not lift the upstream tests, so we built our own from scratch. The protocol is strict enough that you need roughly 30 to 40 percent of the engine working before integration tests are even useful. Until then, you are testing event signing, event construction, and state validation by hand. That work is not visible in a feature list, and it is most of what the alpha actually was.

Beta: hardening on a five-week clock

Beta was the pre-commercialization phase, and the timeline was tight. The goal was a product that early adopters could pick up with confidence, even knowing it was not yet at general availability.

Three things moved the most in beta. We implemented the invitation handling flow to be fully compliant with the protocol. We removed Rocket.Chat features that were not yet compatible with federation, because a degraded experience is worse than a missing one. And we added more than 100 test cases against the engine. Removing capabilities was a deliberate call. A federated room that silently breaks a feature is more damaging than a federated room that does not offer it yet.

General availability: hardening for production

GA hardened the engine with those guard rails. We rebuilt how the incoming and outgoing queues handle load. We brought back features that had been removed in beta, including read receipts. We added new capabilities the protocol supports but our earlier implementation did not, including the ability to ban users from federated rooms. We ran load tests against the GA build that we did not have the engine maturity to run during alpha.

“Organizations comparing options can deploy a production-grade Rocket.Chat Matrix-native federation platform now, instead of carrying years of custom build and ongoing maintenance to get there.”
— Renato Becker, Federation Product Manager 

What is next

Native federation architecture is the foundation. The roadmap is built on top of it.

Protocol breadth. Matrix is the federation protocol of Rocket.Chat, and it stays that way, but the homeserver also bridges to other federation protocols, including XMPP, with broader protocol coverage on the roadmap. Customers working in environments where Matrix is not the local standard still need to federate. Our job is to meet that requirement, not to insist on one protocol.

Federation governance. The Matrix protocol does not cover policy enforcement at the layer where organizations actually operate. We are building the capability for organizations to establish and enforce shared policy frameworks across federated rooms: secure communication, controlled interoperability, compliance with organizational requirements, and trusted collaboration across the ecosystem.

The approach for these is the same one we used when moving off the bridge. Contribute upstream where it makes sense. Ship server-side capability where the protocol cannot move at the pace our customers need.

“Federation is the future. Communication needs to be distributed, because the only way for organizations to have real data sovereignty is to not depend on someone else’s centralized system. If you have to use someone else’s cloud to talk to anyone outside your walls, you do not have sovereignty. You have a dependency.”
— Gabriel Engel, CEO

Rocket.Chat Labs is a series exploring how we build, test, and evolve Rocket.Chat Secure CommsOS®. The next edition is in progress.