Matrix chat is an open, federated messaging standard: independent servers exchange messages over a shared protocol, so people on different providers can talk in the same rooms. No single company owns the network, and anyone can run a server.
Matrix sits within the wider community platform landscape of open protocols that let groups own their communication tools instead of renting them.
How Matrix chat works
Matrix is a protocol, not a single app. The protocol defines how servers, clients and bridges talk to each other, and many different programs implement those roles. The official Matrix documentation describes the main building blocks as the homeserver, the client, and the application service, which covers bridges and some bots.
A homeserver stores the accounts and message history of its users. A client, such as a phone or desktop chat app, connects to a homeserver over a web API. When a user sends a message, the client posts a JSON event to a room on that user’s homeserver. In the project’s own walkthrough, the homeserver then adds that event to its graph of history, linking it to the most recent unlinked object in the graph (Matrix.org, Elements of Matrix).
Rooms are not owned by one server. Every homeserver with a member in a room keeps a copy of the room’s history, and servers pass events to each other directly. That is what “federated” means in practice: if one server goes offline, the room carries on elsewhere, and the offline server catches up when it returns.
Users are identified by an address made of a username and a server name, written like @alice:example.org. The server name in the address shows which homeserver holds the account, much as the domain in an email address does. A person can move to a different provider later, but the account address changes with the server, so moving means rebuilding contacts and room memberships. Community groups that expect to last should therefore pick a server name they control.
Why rooms do not break when servers disagree
Because several servers can accept messages at the same moment, their views of a conversation can briefly differ. The Matrix documentation says so openly in its example of three users on three servers: their homeservers have different views of the message history at one point, but Matrix is designed to handle this inconsistency (Matrix.org, Elements of Matrix).
The design that makes this work is a graph of events rather than a single numbered list. Each new event points back to the latest events the sending server knew about. When two people post at once, the next message links to both, and every server converges on the same history. This trade-off favours availability over strict ordering, which suits group chat.
A short history of the protocol
Matrix was released in December 2014 and is now stewarded by the Matrix.org Foundation, a community interest company. Early development was funded by the telecom software company Amdocs: according to the project’s history, Amdocs funded most of the development work from 2014 to October 2017 (Wikipedia, Matrix (protocol)).
The reference homeserver implementation is Synapse, and the best-known client began life as Riot before being renamed Element. Other server and client projects exist, which is the point of an open standard: the specification is what matters, and no one program is required.
Who uses it in practice
Governments and open-source communities were among the earliest large adopters. In April 2018, the French Government announced plans to create its own instant messaging tool, which became Tchap and was built on Matrix (Wikipedia, Matrix (protocol)). A later pilot followed in Germany: in December 2019, the German Federal Ministry of Defense began a pilot project named BwMessenger, based on the Matrix protocol, a Synapse server, and the Riot application modeled after France’s Tchap project.
Open-source projects moved too. In the same month, Mozilla announced it would replace its IRC infrastructure with Matrix (Wikipedia, Matrix (protocol)). These examples show the main appeal: an organisation can run its own server, keep its data under its own control, and still use mature client apps.
Bridges: connecting Matrix to other networks
Few communities can persuade everyone to switch at once, so Matrix includes bridges. The Matrix.org bridge directory puts it simply: bridges allow users to connect Matrix to a third-party platform and interact seamlessly (Matrix.org, Bridges). The directory lists bridges for services such as Discord, Slack, Signal, Telegram, WhatsApp, IRC and email.
Bridges vary in quality. Some relay plain text reliably, while others struggle with reactions, edits, threads or encrypted rooms. A bridge also has to hold credentials or relay messages through a server, which affects privacy. Groups considering a bridge should read the bridge’s own documentation and test it with a small room first.
For a fuller comparison of the most common migration path, see this look at matrix vs discord, which covers how the two differ in ownership, moderation and features.
Matrix and other open protocols
Matrix is often mentioned beside other decentralised standards, but they solve different problems. activitypub is a protocol for federated social networking, such as microblogs and feeds, while Matrix focuses on real-time rooms, direct messages and calls. The bridge directory itself lists ActivityPub as having no bridge, so the two ecosystems remain separate (Matrix.org, Bridges).
Matrix also differs from older open chat standards such as IRC and XMPP. It keeps persistent, synchronised history across servers, supports end-to-end encryption in private rooms, and treats bridging as a core feature instead of an add-on.
The same openness shapes how projects use Matrix day to day. Because the specification is public, a community can choose a client that suits its members, from a full-featured desktop app to a lightweight mobile one, and mix them freely in one room. A volunteer group can start on a hosted server, then migrate to its own hardware when it has the skills and time. A school, a co-operative or a neighbourhood association can keep its conversation history on infrastructure it chooses, rather than accepting whatever policy a single platform sets.
That freedom has costs. The ecosystem is a collection of independent projects, so documentation, polish and release schedules differ. Newcomers sometimes find the idea of a homeserver, an account address and encryption keys harder to grasp than signing up to a single branded app. Communities adopting Matrix do best when one or two members take responsibility for onboarding, written guides and moderation.
Practical things to weigh before adopting it
- Choose a homeserver deliberately. A hosted account is the easiest start; self-hosting gives control but means handling updates, backups and moderation.
- Expect uneven clients. Features such as threads, voice and video differ between apps, so test the clients your group will actually use.
- Plan moderation. Federation means rooms can include users from servers you do not control, so set clear room rules and permissions.
- Treat encryption as a setting to check. Confirm which rooms are encrypted and how members verify devices.
Frequently asked questions
Is Matrix a chat app?
No. Matrix is an open protocol. Apps such as Element are clients that use it, and many other clients and servers can implement the same standard.
Do both people need to use the same server?
No. Federation lets users on different homeservers join the same rooms, because the servers exchange events with each other directly.
Can Matrix connect to Discord or Slack?
Yes, through bridges. The Matrix.org bridge directory lists bridges for both platforms, though feature support depends on the specific bridge.
Who runs Matrix?
The Matrix.org Foundation oversees the protocol specification. Individual servers are run by many separate organisations, companies and individuals.
