Matrix is the decentralised, open protocol that underpins the entire AMVLET stack — letting organisations own their infrastructure, federate on their terms, and communicate without a single point of control.
Matrix defines a set of open APIs for decentralised communication — suitable for securely publishing, persisting, and subscribing to data over a global open federation of servers with no single point of control.
Like email, users on different independently operated servers communicate seamlessly. Unlike email, every message can be end-to-end encrypted, the protocol is defined by a neutral foundation rather than a single company, and organisations can run entirely isolated deployments that never touch the public internet.
The specification is published at spec.matrix.org under the Apache 2.0 licence. Any organisation can read it, implement it, and deploy it — no licensing fees, no vendor lock-in.
Anyone can participate in the global Matrix network. Servers interoperate by design, not by permission.
Olm and Megolm cryptographic protocols — both now part of the official specification — provide forward secrecy for 1:1 and group communications.
Your data stays on your servers. No third-party vendor access, no cloud dependency — just the infrastructure you control.
Patent-encumbered IP is strictly prohibited from the standard. The spec is free to implement without licensing constraints.
AMVLET is built on Matrix end-to-end — from the open protocol at the base to the sovereign-facing interface at the top.
The sovereign communication interface. Purpose-built for classified and sensitive environments, with jurisdiction-aware controls, custom identity management, and air-gap support. Zero dependency on the public cloud.
Enterprise-grade Matrix homeserver infrastructure — high-availability, horizontally scalable, and operated within the customer's own environment. Handles federation, key management, and message routing. Built on Synapse Pro (Python + Rust hybrid).
The open, patent-free specification defined at spec.matrix.org and maintained by the Matrix.org Foundation C.I.C. — a UK-registered non-profit (Company #11648710). No single entity controls the protocol. Any compliant implementation can interoperate.
The Matrix specification defines a complete set of independently versioned APIs. Each endpoint can evolve without breaking the others.
Defines how Matrix clients (messaging apps, bots, IoT devices) authenticate, send events, sync state, and manage rooms with their homeserver.
The federation protocol. Homeservers use this to exchange signed Persistent Data Units (PDUs), synchronise room state, and validate each other's event graphs.
Enables integration with external networks — IRC, Slack, WhatsApp, Teams — and powers automated services and bots inside a Matrix deployment.
Maps third-party identifiers (email, phone numbers) to Matrix user IDs. Usage is optional — deployments can operate without any external identity service.
Standardises how homeservers push notifications to mobile clients via external push gateways, without exposing message content to the gateway.
Olm implements the Double Ratchet algorithm for 1:1 channels (full forward secrecy). Megolm uses a hash ratchet for group encryption without O(n²) peer sessions.
Matrix federation works like email: users on different, independently operated homeservers communicate seamlessly over HTTPS. No central routing server, no single point of failure.
When a user sends a message, their homeserver signs it with an Ed25519 key, adds it to a Directed Acyclic Graph (DAG) that references prior events, and forwards it as a signed Persistent Data Unit to every homeserver participating in that room.
Receiving servers validate signatures and authorisation rules independently. The DAG provides eventual consistency — during network partitions, servers continue operating and merge histories once reconnected. State resolution algorithms ensure all servers converge on identical room state.
For sovereign deployments, federation can be restricted to a closed set of known homeservers — or disabled entirely for fully air-gapped operation.
The Spec Core Team has confirmed all core 2.0 MSCs are extremely close to completion. These four capabilities define Matrix 2.0.
Instant room loading — clients receive only the data they need for the current view, eliminating the full-sync lag that has historically made Matrix clients feel slow on first load.
Native, federated voice and video conferencing built into the protocol — no third-party conference server required. Calls can span homeservers with the same security guarantees as messages.
OAuth 2.0 and OIDC replace the legacy Matrix password flow, enabling SSO integration, delegated authorisation, and compatibility with enterprise identity providers out of the box.
Seamless end-to-end encryption without user friction — no manual key verification popups, no "unable to decrypt" errors. Encryption becomes an invisible default, not an optional feature.
The Matrix.org Foundation C.I.C. (Company #11648710) is a UK non-profit whose legal structure prevents acquisition or repurposing. Three independent governance pillars protect the protocol.
Independent directors who ensure the Foundation stays true to its mission. Governance changes require a 75% supermajority — no single Guardian, and no single company, can override the group.
Technical custodians who review and approve all protocol changes via the Matrix Spec Change (MSC) process. Spec changes require 75% SCT approval after a public 5-day Final Comment Period.
Elected representatives from nine constituency groups across the ecosystem, established in 2024. Broadens governance beyond any single commercial player.
The most common technical and governance questions about the Matrix protocol and how it underpins AMVLET.
AMVLET gives you the full Matrix stack — sovereign infrastructure, enterprise support, and a team that understands both the protocol and your compliance requirements.