The Matrix ecosystem #

Matrix is used by governments, defense forces, open-source communities and Fortune-500 companies. It's not a hobby project that almost works — it's a running network carrying real traffic across thousands of homeservers. This page is a quick tour of who's running Matrix, what server software powers their homeservers, and how the spec evolves.

Matrix.org Foundation #

Matrix is stewarded by the Matrix.org Foundation, a UK non-profit that owns the spec and runs matrix.org (the community flagship homeserver). The foundation doesn't control the network — its job is to keep the spec open and to publish official reference implementations. Anyone can build on the spec without asking permission.

The foundation is funded by donations and by corporate members (Element, Automattic, Famedly, Gematik, others). Spec proposals go through a public MSC process — anyone can write one, and the Spec Core Team decides what merges. The spec is versioned; homeservers and clients advertise supported versions and degrade gracefully when talking to older peers.

Homeserver implementations #

Multiple independent server implementations exist, and they're all federation-compatible:

Synapse #

The original Python reference implementation. Most widely deployed. Powers matrix.org itself, KDE, Mozilla, Wikimedia and many corporate deployments. Mature, battle-tested, feature-complete.

  • Language: Python (Twisted async runtime)
  • Storage: PostgreSQL
  • Strengths: every spec feature, massive community, first to get new MSCs
  • Weaknesses: memory-heavy at large scale; Python's GIL makes CPU scaling tricky

Dendrite #

Second-generation Go implementation from the Matrix core team. Modular architecture (component servers that can run together or separately), better scaling characteristics, reduced memory footprint. In production at several deployments.

  • Language: Go
  • Storage: PostgreSQL or SQLite
  • Strengths: horizontal scalability, lower memory floor
  • Weaknesses: lagged on some newer spec features; still catching up with Synapse on app-service ergonomics

Conduit / Conduwuit #

Lightweight Rust implementations designed to run on a Raspberry Pi or a cheap VPS. Single-binary deployment, RocksDB storage, very low resource floor. Conduwuit is an actively maintained community fork with a faster release cadence.

  • Language: Rust
  • Storage: RocksDB (embedded)
  • Strengths: single-binary, hobbyist-friendly, fast
  • Weaknesses: smaller feature surface than Synapse

Palpo #

The Rust homeserver Meldry runs under the hood. Modern async architecture, tight integration with our multi-tenant orchestrator, per-tenant database isolation. Built to run many small homeservers cheaply on shared infrastructure — the opposite of Synapse's "one server, one big deployment" model.

  • Language: Rust
  • Storage: PostgreSQL with per-tenant schemas
  • Strengths: low per-tenant overhead, fast cold-start, multi-tenant first
  • Weaknesses: younger than Synapse; feature parity is still landing

All four speak the same client-server and server-server APIs, so a Matrix client doesn't care which one you pick.

Bridges and appservices #

A huge practical reason Matrix is used as a "unified inbox" is that bridges exist for almost every major chat network: Telegram, Slack, Discord, WhatsApp, Signal, IRC, XMPP, Google Chat, Microsoft Teams (community), WeChat, LINE, iMessage (community), SMS via Android Gateway, email (via SMTP bridge), and more. Most are maintained by the mautrix project — a Go-based family of bridges that all share a common framework.

See Bridges for the ones shipped in Meldry, and Appservices for writing your own.

Notable deployments #

  • Tchap — the French government's internal messenger. A whole-of-government Matrix deployment replacing WhatsApp and Telegram for civil servants. Built on Synapse + a custom identity provider. Hundreds of thousands of users.
  • BwMessenger — the German federal armed forces (Bundeswehr) messenger. Matrix-based, E2EE-only, independently security-audited.
  • Gematik TI-Messenger — the German healthcare interoperability platform. Every hospital and doctor's office that wants to exchange patient data uses a Matrix client against a certified homeserver. Compliance-first Matrix.
  • KDE — the KDE community chat runs on a self-hosted Matrix homeserver, with IRC bridge to the historical #kde channels.
  • Mozilla — Mozilla's community chat (chat.mozilla.org) runs on Matrix, having replaced IRC as the canonical community venue.
  • Wikimedia — uses Matrix for some community channels, bridged to the historical IRC network.
  • GNOME — similar Matrix + IRC-bridge setup.
  • Element enterprise customers — many governments, defense primes and Fortune-500 companies run private Matrix deployments for internal comms. Most stay private; a few are publicly listed on element.io.

Spec versions #

The Matrix spec is versioned. Rooms declare a room version (1 through 11 at the time of writing) controlling state-resolution algorithm, event format and auth rules. New rooms on modern homeservers default to version 11; older rooms can be "upgraded" by room admins to bring them up to date, which creates a new room and links the old one as a predecessor.

Homeservers advertise supported spec versions at GET /_matrix/client/versions. Clients handshake against this list and degrade gracefully for older servers. You'll occasionally see an "unsupported room version" error when joining a very old room on a very new server (or vice versa) — the fix is usually to upgrade the room.

The current spec lives at spec.matrix.org and is versioned by release date (e.g. v1.11, v1.12). Homeservers target whichever versions they've implemented; spec churn is intentionally conservative — breaking changes are rare.

Where to next #