Matrix is an open protocol for decentralised, real-time communication. Element is an application that uses Matrix.
A useful analogy is:
- Matrix is comparable to email as a system and protocol.
- A Matrix homeserver is comparable to an email provider or mail server.
- Element is comparable to Outlook, Thunderbird, or Apple Mail.
- A Matrix room is comparable to a Slack channel, group chat, or direct-message conversation.
- A Matrix Space groups related rooms, rather like a Slack workspace or Discord server.
Riot was renamed Element in July 2020. References to Riot in old documentation normally mean what is now Element.
Matrix is attractive when an organisation wants interoperability, self-hosting, federation between organisations, end-to-end encryption, or less dependence on a single communications vendor. It is not simply “open-source Slack”: its architecture is closer to federated email combined with modern encrypted messaging.
flowchart LR
A["Alice<br/>Element client"] --> H1["example.org<br/>Matrix homeserver"]
B["Bob<br/>Another Matrix client"] --> H2["partner.org<br/>Matrix homeserver"]
H1 <--> |"Matrix federation"| H2
H1 --> BR["Optional bridge<br/>Slack, IRC, Telegram, etc."]
H1 --> BOT["Bots and integrations"]
A -.-> |"End-to-end encrypted content"| B
A user runs a Matrix client, such as Element. The client connects to the user’s chosen homeserver, which handles authentication, message synchronisation, room state, media, device information, and communication with other Matrix homeservers.
When users from different homeservers participate in the same room, their homeservers maintain synchronised local copies of that room. There is no single central Matrix server through which every conversation must pass.
For example:
@alice:example.org
@bob:partner.org
These are Matrix user IDs. The portion after the colon identifies the user’s homeserver or account provider.
A human-readable room address might look like:
#engineering:example.org
The visible address is an alias pointing to an underlying room identifier. A room can have more than one alias.
| Component | Purpose |
|---|---|
| Matrix protocol | Defines how clients, homeservers, rooms, events, federation, and encryption interoperate. |
| Homeserver | Hosts accounts, synchronises messages, stores room data, and federates with other homeservers. |
| Client | The application through which a user reads and sends messages. Element is the best-known client, but it is not the only one. |
| Room | A conversation containing messages, membership changes, permissions, and other events. |
| Space | A collection or hierarchy of rooms, similar to a workspace or community. |
| Event | Matrix’s underlying unit of data: a message, reaction, membership change, room name change, permission change, and so forth. |
| Bridge | Connects a Matrix room to another communications system. |
| Bot or application service | Automates actions or integrates external systems with Matrix. |
Technically, a Matrix room is a sequence of JSON events. Messages are only one kind of event; room membership, names, permissions, reactions, edits, and administrative changes are events too.
Spaces organise rooms and are presented rather like Slack workspaces or Discord servers, although they remain part of Matrix’s decentralised room model rather than forming a completely separate server boundary.
Element is the flagship Matrix client produced by Element, the company that originated much of the Matrix ecosystem. It is available for the web, desktop operating systems, Android, and iOS. Its source code is available under open-source licences.
Element X is the newer-generation mobile client. It is a rewrite using the newer Rust-based Matrix SDK and is now the recommended mobile client for most ordinary users. Some older or specialised deployments may still use the classic Element mobile applications.
The naming history is therefore approximately:
Riot → Element
├── Element Web/Desktop
├── Element X mobile
└── Other Element products and server offerings
A Matrix account is not inherently tied to Element. The same account may be usable through other compatible Matrix clients, subject to the client and homeserver supporting the required protocol features.
Federation allows independently operated Matrix homeservers to communicate.
Suppose Alice uses example.org and Bob uses partner.org. When they join the same room:
- Alice’s client communicates with
example.org. - Bob’s client communicates with
partner.org. - The two homeservers exchange and validate room events.
- Each participating homeserver maintains the portion of room history and state it needs.
This allows organisations to retain control over their own accounts and infrastructure while communicating across organisational boundaries.
Federation is optional at the deployment-policy level. An organisation can run a restricted or isolated Matrix environment, but doing so gives up some of Matrix’s interoperability benefits.
Self-hosting does not automatically mean that every copy of the data remains on your server.
In a federated room, participating homeservers keep local copies of the room. For end-to-end encrypted rooms, message bodies and encrypted attachments remain ciphertext on those servers, but the participating servers still process information required to operate the room.
It is therefore reasonable to infer that Matrix end-to-end encryption protects conversation content, but does not conceal every item of operational metadata from the homeservers involved. Room participation, event timing, server relationships, device-key activity, IP connections, and traffic patterns may still be observable to one or more service operators.
Matrix supports end-to-end encryption using the Olm and Megolm cryptographic systems. In an encrypted room, clients encrypt message content before sending it to the homeserver. Participating homeservers store and distribute ciphertext but do not normally possess the keys needed to decrypt it.
This protects message content against:
- A compromised or curious homeserver operator.
- A database or media-store breach.
- Interception between homeservers.
- A server being compelled to disclose message contents it cannot decrypt.
It does not protect against:
- A compromised participant device.
- A participant copying or forwarding a message.
- Malware taking screenshots or reading messages after decryption.
- An authorised participant deliberately leaking information.
- All communications metadata.
- A bridge or bot that is deliberately given access to plaintext.
Encryption changes the security boundary: the user’s devices and recovery credentials become especially important.
Each login or application installation is effectively a separate Matrix session or device. Users should verify new sessions using an already verified device or their recovery key. This helps prevent an attacker who has obtained account credentials from silently introducing an untrusted device.
The recovery key is separate from the account password. It is used to recover encrypted message keys and verify new devices.
Losing both:
- Every verified device, and
- The recovery key or recovery passphrase
can make historical encrypted messages permanently unreadable. Resetting the password does not reconstruct lost encryption keys.
A sensible organisational onboarding process should therefore require users to:
- Enable secure key backup.
- Store the recovery key in an approved password manager.
- Verify each new device.
- Review and revoke obsolete sessions.
- Avoid keeping the recovery key in unencrypted email, chat, or shared documents.
Matrix permissions are represented through power levels within each room.
Typically:
- Ordinary members can send messages.
- Moderators can redact messages or remove users.
- Administrators can change room settings and grant privileges.
- The room creator initially receives the highest power level.
These permissions are part of the room’s replicated state and are evaluated by the participating homeservers.
Room administration is not identical to centralised Slack or Teams administration. A room can span multiple servers, and authority follows the room’s power-level state rather than necessarily belonging to the organisation operating a particular server.
Administrators should appoint at least two trusted room or Space owners. Accidentally removing the only administrator can make a room difficult to recover, and granting equal administrative power effectively creates a co-owner who cannot necessarily be removed unilaterally.
Public federated rooms also require active moderation and abuse controls. Decentralisation removes a central platform owner, but it does not remove spam, harassment, malicious servers, impersonation, or moderation work.
Matrix bridges can connect rooms to systems such as IRC, Slack, Telegram, WhatsApp, or other messaging platforms. Bots and application services can also connect Matrix with monitoring, ticketing, CI/CD, and automation systems.
Bridges are useful, but they weaken some of the clean security assumptions.
To relay a message into a platform that does not understand Matrix encryption, a bridge normally needs access to the decrypted content. The bridge and the destination platform therefore become part of the trusted computing base.
A bridged encrypted room should not be described simply as “end-to-end encrypted” without stating where the bridge terminates that encryption.
Questions to ask before deploying a bridge include:
- Who operates it?
- Where does it store credentials?
- Can it read message content?
- Does it retain messages or logs?
- How are external users represented?
- Can users on the other platform impersonate Matrix users?
- What happens when messages are edited or deleted?
- Does the destination service apply different retention or legal-discovery rules?
- How quickly are bridge security updates installed?
Private organisational bridges will generally need to be operated by the organisation or its provider rather than attached arbitrarily to the public matrix.org service.
Matrix separates the protocol from any particular client, server implementation, or hosting company. This reduces dependence on a single application vendor and permits communication between independently operated deployments.
Organisations can choose where accounts, databases, media, and services are hosted, and can control federation policy, identity, retention, and integrations.
Private conversations can remain unreadable to the participating homeservers, provided the clients, devices, and key management remain secure.
Matrix’s event-based model and APIs work well for bots, automation, application integrations, incident rooms, monitoring notifications, and custom communication applications.
Users are not necessarily forced to use Element. Different Matrix clients can offer different interfaces while using the same underlying network and identity.
Two organisations can each operate their own infrastructure and communicate without placing all users inside one organisation’s Slack or Teams tenant.
Running a production homeserver means operating a stateful, Internet-facing communications system. It requires disciplined handling of:
- Authentication and account lifecycle.
- TLS and DNS.
- Database and media backups.
- Key-backup availability.
- Federation security.
- Rate limiting and abuse prevention.
- Spam and moderation.
- Voice and video infrastructure.
- Monitoring, capacity planning, and upgrades.
- Privacy, retention, audit, and legal requirements.
Self-hosting should be treated as operating critical communications infrastructure, not as deploying a disposable chat container.
An account such as @alice:example.org is associated with that provider name. Communities and room ownership can be transferred to accounts on another server by changing power levels, but account migration is not as transparent as moving an email mailbox while keeping the same address.
Using an organisation-controlled domain from the beginning avoids branding and identity problems later.
Encryption protects users partly by ensuring that administrators cannot simply recover every lost key. That is desirable security behaviour, but it requires proper onboarding and recovery-key management.
Federation improves resilience and interoperability but introduces remote servers, administrators, users, policies, and abuse sources. Organisations should decide whether federation is:
- Fully open.
- Allow-listed.
- Restricted to trusted partners.
- Disabled for particular environments.
Matrix defines interoperable behaviour, but not every client exposes every feature in the same way. Newer clients may also depend on newer homeserver capabilities. Client and server compatibility should be tested against the organisation’s actual workflows.
Matrix is particularly compelling for:
- Communication between independent organisations.
- Public-sector or regulated environments concerned with sovereignty.
- Communities that do not want to depend on Discord or another central platform.
- Organisations requiring self-hosting or controlled hosting.
- Incident-response and operational collaboration.
- Encrypted communication where server operators should not read content.
- Systems requiring bots, bridges, or custom event-driven integrations.
- Environments where open standards and exit options matter.
It may be a poor fit when:
- The organisation wants a completely managed service with minimal operational ownership.
- Deep integration with one proprietary office suite is more important than interoperability.
- Users will not reliably manage device verification and recovery credentials.
- The organisation lacks capacity for moderation, identity governance, and lifecycle management.
- Compliance requires central inspection of all message content while users also expect uncompromised end-to-end encryption.
That final point is a real architectural conflict: genuine end-to-end encryption and transparent server-side content inspection cannot both be fully provided.
Before committing to a production deployment:
- Start with a small managed or test homeserver.
- Use an organisation-controlled Matrix domain.
- Test Element Web/Desktop and Element X mobile.
- Create a representative Space and several rooms.
- Test encrypted-message recovery on a new device.
- Test account suspension and device revocation.
- Invite a user from another homeserver to test federation.
- Evaluate a bridge separately from the core deployment.
- Define federation, retention, moderation, and backup policies.
- Perform a threat model before treating it as a secure production service.
The recovery exercise is especially important. A system is not operationally ready merely because users can send encrypted messages; it is ready when legitimate users can recover safely, compromised devices can be removed, administrators understand what they can and cannot access, and the organisation knows which other systems receive the data.
Matrix is an open, federated communications protocol, while Element—previously called Riot—is a client that uses it. Users have accounts on homeservers, join rooms, and communicate either locally or across federated servers. Rooms can be end-to-end encrypted so that homeservers distribute ciphertext without being able to read the message content. Matrix offers strong interoperability, self-hosting, and data-sovereignty benefits, but it also brings operational complexity around federation, moderation, bridges, device verification, and encryption-key recovery. It is best understood as an open communications infrastructure rather than merely another chat application.