An open network for secure, decentralized communication

Learn More

An open network for secure, decentralized communication

Get started
  • Imagine a world...
  • ...where it is as simple to message or call anyone as it is to send them an email.
  • ...where you can communicate without being forced to install the same app.
  • ...where you can choose who hosts your communication.
  • ...where your conversations are secured by E2E encryption.
  • ...where there’s a simple standard HTTP API for sharing real-time data on the web.

This is Matrix.

Matrix is an open source project that publishes the
Matrix open standard for secure, decentralised, real-time communication, and its Apache licensed
reference implementations.

Maintained by the non-profit Matrix.org Foundation, we aim
to create an open platform which is as independent, vibrant and evolving as the Web itself... but for communication.

As of June 2019, Matrix is out of beta, and the protocol is fully suitable for production usage.

Messaging

Matrix gives you simple HTTP APIs and SDKs (iOS, Android, Web) to create chatrooms, direct chats and chat bots, complete with end-to-end encryption, file transfer, synchronised conversation history, formatted messages, read receipts and more.

Conversations are replicated over all the servers participating in them, meaning there are no single point of control or failure. You can reach any other user in the global Matrix ecosystem of over 9M users, even including those on other networks via bridges.

Learn more

End-to-End Encryption

Matrix provides state-of-the-art end-to-end-encryption via the Olm and Megolm cryptographic ratchets. This ensures that only the intended recipients can ever decrypt your messages, while warning if any unexpected devices are added to the conversation.

Matrix’s encryption is based on the Double Ratchet Algorithm popularised by Signal, but extended to support encryption to rooms containing thousands of devices. Olm and Megolm are specified as an open standard and implementations are released under the Apache license, independently audited by NCC Group.

Learn more

VoIP

With the advent of WebRTC, developers gained the ability to exchange high quality voice and video calls – but no standard way to actually route the calls.

Matrix is the missing signalling layer for WebRTC. If you are building VoIP into your app, or want to expose your existing VoIP app to a wider audience, building on Matrix’s SDKs and bridges should be a no-brainer.

Learn more

Bridging

Matrix owes its name to its ability to bridge existing platforms into a global open matrix of communication. Bridges are core to Matrix and designed to be as easy to write as possible, with Matrix providing the highest common denominator language to link the networks together.

The core Matrix team maintains bridges to Slack, IRC, XMPP and Gitter, and meanwhile the wider Matrix community provides bridges for Telegram, Discord, WhatsApp, Facebook, Hangouts, Signal and many more.

Learn more

IOT, VR and more...

Matrix can handle any type of real-time data, not only messaging and VoIP.

By building bridges to as many IoT silos as possible, data can be securely published on the Matrix network. IoT solutions built on Matrix are unified, rather than locked to specific vendors, and can even publish or consume Matrix data directly from devices via ultra-low bandwidth transports (100bps or less)

Meanwhile AR and VR vendors are recreating the silos we’ve seen in instant messaging rather than working together towards an open ecosystem. Matrix can be the unifying layer for both communication and world data in AR and VR.

How does it work?

Matrix is really a decentralised conversation store rather than a messaging protocol. When you send a message in Matrix, it is replicated over all the servers whose users are participating in a given conversation - similarly to how commits are replicated between Git repositories. There is no single point of control or failure in a Matrix conversation which spans multiple servers: the act of communication with someone elsewhere in Matrix shares ownership of the conversation equally with them. Even if your server goes offline, the conversation can continue uninterrupted elsewhere until it returns.

This means that every server has total self-sovereignty over its users data - and anyone can choose or run their own server and participate in the wider Matrix network. This is how Matrix democratises control over communication.

By default, Matrix uses simple HTTPS+JSON APIs as its baseline transport, but also embraces more sophisticated transports such as WebSockets or ultra-low-bandwidth Matrix via CoAP+Noise.

Next
Here are three Matrix homeservers, each with one client connected.

The clients are all participating in the same Matrix room, which is synchronised across the three participating servers.
Alice sends a JSON message to a room on her homeserver.
curl -XPOST
 -d '{"msgtype":"m.text", "body":"hello"}'
 "https://matrix.alice.com/_matrix/client
 /v2/rooms/ROOM_ID/send/m.room.message
 ?access_token=ACCESS_TOKEN"

{
  "event_id": "$YUwRidLecu:alice.com"
}
Alice's homeserver adds the JSON to its graph of history, linking it to the most recent unlinked object(s) in the graph.

The server then signs the JSON including the signatures of the parent objects to calculate a tamper-resistent signature for the history.
The server then sends the signed JSON over HTTPS to any other servers which are participating in the room.
curl –XPOST –H 'Authorization: X-Matrix origin=alice.com,...' –d '{
  "ts": 1413414391521,
  "origin": "alice.com",
  "destination": "bob.com",
  "pdus": [{
      "event_id": "$YUwRidLecu:alice.com",
      "content": {
      "body": "hello world",
      "msgtype": "m.text"
    },
    ...
    "pdu_type": "m.room.message",
    "signatures": {
      "matrix.org": {
        "ed25519:auto": "jZXTwAH/7EZ..."
      }
    },
    "sender": "@alice:alice.com"
  }]
}' https://matrix.bob.com:8448/_matrix/federation/v1/send/916d...
The destination servers perform a series of checks on the message:
  • Validate the message signature to protect against tampering with history
  • Validate the HTTP request's auth signature to protect against identity spoofing
  • Validate whether Alice's historical permissions allow her to send this particular message
If these checks pass, the JSON is added to the destination servers' graphs.
Destination clients receive Alice's message with a long-lived GET request. (Clients are free to implement more efficient transports than polling as desired).
curl "https://matrix.bob.com/_matrix/client
 /v2/sync?access_token=ACCESS_TOKEN"
{
  "next_batch": "s72595_4483_1934",
  "rooms": [{
    "room_id": "!KrLWMLDnZAyTapqLWW:alice.com",
    "events": {
      "batch": [{
        "event_id": "$YUwRidLecu:alice.com",
        "type": "m.room.message",
        "content": {
          "body": "I am a fish",
          "msgtype": "m.text",
        },
        "origin_server_ts": 1417731086797,
        "sender": "@alice:alice.com"
      }],
    },
  }]
}
Bob sends a response to Alice's message, and his server adds his message into his copy of the room's history, linking it to the most recent unlinked object in the graph - Alice's last message.
Meanwhile, Charlie also responds to Alice's message - racing with Bob's message.

Alice, Bob and Charlie's homeservers all have different views of the message history at this point - but Matrix is designed to handle this inconsistency.
Bob's homeserver relays his message through to Alice and Charlie's servers, who accept it.

At this point Alice and Bob are in sync, but Charlie's room history has split - both messages 2 and 3 follow on from message 1. This is not a problem; Charlie's client will be told about Bob's message and can handle it however it chooses.
Charlie's homeserver relays his message through as well, at which point all 3 servers have a consistent view of history again (including the race between Bob and Charlie). All three clients have seen all three messages, and the room history is now back in sync across the participating servers.
Later on, Alice sends another message - her homeserver adds it to her history, and links it to the most recent unlinked objects in the graph: Bob and Charlie's messages.

This effectively merges the split in history and asserts the integrity of the room (or at least her view of it).
Alice's message is then relayed to the other participating servers, which accept it and update their own history with the same rules, ensuring eventual consistency and integrity of the distributed room history.

An Open Standard

Simple pragmatic RESTful HTTP/JSON APIs by default

Open specification of the Matrix standard

Fully decentralised conversations with no single points of control or failure

End-to-end encryption via Olm and Megolm

WebRTC VoIP/Video calling using Matrix signalling

Real-time synchronised history and state across all clients

Integrates with existing 3rd party IDs to authenticate and discover users

Maintained by the non-profit Matrix.org Foundation

Group conversations, read receipts, typing notifications, presence...

Latest News

This Week in Matrix 2020-10-16

Matrix Live 🎙 In which I chat with Kitsune about the work done to get a Matrix URI schema agreed, and the state of the work. See also…

Read more

Synapse 1.21.2 released, and security advisory.

Hi folks, Today we have released Synapse 1.21.2, which fixes a couple of minor bugs that crept into the previous release. Full details are…

Read more

Synapse 1.21.1 released

Synapse 1.21.1 has landed! Highlights of 1.21.1 include:- Add experimental support for sharding event persister. ( # 8294 , # 838…

Read more

This Week in Matrix 2020-10-09

Matrix Live 🎙 Dept of Status of Matrix 🌡️ Matrix in use at IETF and TeamSpeak Matthew said: IETF is trialling Matrix as a replacement…

Read more
View all posts

SDKs

Native SDKs for multiple platforms, including:

View all SDKs

Open Source

Join thousands of other developers in our open source repositories, including:

Synapse

JavaScript SDK

Android SDK

iOS SDK

View all on GitHub

The Matrix Foundation

Matrix is managed through an open governance process, looked after by The Matrix.org Foundation - a non-profit UK Community Interest Company.

It acts as a neutral guardian of the Matrix spec, nurturing and growing Matrix for the benefit of the whole ecosystem.

The Guardians are the legal directors of the Foundation, responsible for ensuring that it keeps on mission and neutrally protects the development of Matrix.

What people are saying

Support Matrix

If you share our vision, or are building on top of Matrix, please consider donating...

Support us on Patreon for great rewards including access to the supporters-only podcast, and even a voice at our weekly meetings.
Find out more at our Patreon page.

Patreon

Patreon

Liberapay

Liberapay

Cryptocurrency

You can also send us cryptocurrency:
BTC 1LxowEgsquZ3UPZ68wHf8v2MDZw82dVmAE
ETH 0xA5f9a4f9E024F6D727f7afdA9257e22329A97485

If you share our vision, or are building on top of Matrix, please consider donating. See our current Elliptic supporters!

Thank you to our incredible sponsors

Status

A Mobile OS, Built for Ethereum.

Learn more

UpCloud

Matrix.org is generously hosted by UpCloud! Host your homeserver via UpCloud and get a $25 credit.

Learn more

Private Internet Access

Private Internet Access™ VPN Service encrypts your connection and provides you with an anonymous IP to protect your privacy.

Learn more

InBlockchain

INBlockchain is a full-service firm focusing on consulting, incubating and facilitating crowdsales for promising blockchain startups.

Learn more

Omisego

OmiseGO is a public Ethereum-based financial technology for use in mainstream digital wallets.

Learn more

Tendermint

Byzantine fault-tolerant replicated state machines in any programming language.

Learn more