Skip to content
Comma Compliance

Matrix / Element - Early access

Your homeserver is sovereign. Your compliance archive should run inside it.

Matrix and Element archiving, built for self-hosted deployments.

Governments and regulated enterprises are moving to self-hosted Matrix as a sovereign alternative to Signal and WhatsApp. Comma is building compliance archiving for those deployments - capture that runs inside your own infrastructure, handles end-to-end encryption the technically credible way, and brings WORM retention, legal hold, and supervision to Matrix. This is a planned capability. Request access to join the design-partner program.

Not generally available yet. We are opening a design-partner pipeline ahead of build.

Request Access

Why Matrix, why now

Matrix is an open protocol for secure, decentralized communication. Unlike Signal or WhatsApp, organizations run their own homeserver - they own the infrastructure, the data, and the governance. That sovereignty is exactly why the public sector and regulated enterprises are adopting it at scale.

Germany’s armed forces run BwMessenger, France’s public administration runs Tchap, and Element Server Suite deployments are spreading across European government and enterprise. These are regulated environments with the same supervision and recordkeeping obligations as any bank or broker-dealer. We reference them here only as evidence that Matrix adoption is real and growing - not as customers, partners, or endorsements of Comma.

The organizations standing up sovereign Matrix homeservers still need an immutable, searchable archive with supervision and legal hold. That is the gap Comma is building to close.

Three things we get right

Built for the way Matrix actually works

Sovereignty-native

  • Runs inside your infrastructure

    You run your own homeserver, and our capture runs inside it. Nothing about compliance forces your regulated conversations onto someone else's cloud. For this buyer, that is a feature, not a concession.

  • Auditable by design

    We plan to open-source the capture agent and the Synapse enforcement module so your security team can read the code and verify exactly what is captured and how. Open source, coming soon.

Supervision and WORM over Matrix

  • The same archive you already trust

    Everything our other connectors provide - immutable WORM retention, legal hold, review and supervision workflows, search, and reporting - extended to Matrix rooms.

  • Exam-ready records

    Room events, edits, redactions, membership and state changes, and media are preserved as immutable records to support SEC Rule 17a-4, FINRA Rule 4511, and similar obligations.

Handles E2EE the credible way

  • A trusted participant device, not a decrypting server

    Matrix encrypted rooms use Megolm, so the homeserver never holds plaintext. We do not pretend a server can read ciphertext. Capture uses a dedicated, cross-signed compliance device that is admitted as a trusted room participant and decrypts locally - the same way any verified device in the room does.

  • Honest about the boundary

    The compliance device can only archive rooms it is admitted to, from the point it holds room keys forward. We tell you plainly where that boundary sits rather than claiming coverage we cannot deliver.

How the capture works

Because the customer controls their own homeserver, capture is a participant on that homeserver rather than an interception in transit. Four parts work together.

  1. Application Service journal

    We register as a Matrix Application Service in your Synapse config. Synapse pushes the appservice-interested room events for your local regulated users and configured namespaces to us in retried, idempotent transactions. AS interest is namespace-based and scoped to local users - it is not global capture. This stream journals Matrix events and ciphertext; decryption of encrypted rooms happens on the device path below, not in the AS stream.

  2. Trusted participant compliance device

    A dedicated Matrix user (for example @compliance-archive:customer.example) with verified, cross-signed compliance devices receives Megolm room keys when it is admitted as a trusted room participant, and decrypts locally. Matrix and Element clients may withhold room keys from unverified devices by default, so the compliance device must be trusted under your device-verification policy.

  3. Synapse enforcement module

    For locally created rooms and local-user actions, the module enforces that the compliance participant is admitted before encryption begins, blocks local attempts to remove the compliance user or device, and can enforce room-creation policy. It makes prospective capture enforceable for governed rooms under your homeserver's control. This module is planned to be open-sourced. Open source, coming soon.

  4. Synapse Admin API

    Room and user inventory, membership and state reconciliation, and backfill of unencrypted history round out the picture, so the archive reflects the rooms your homeserver participates in.

What we can and cannot do

We would rather over-communicate the limits than let a Matrix-literate team discover them later. Encrypted-room capture is participant-based and prospective, on a homeserver you control.

Straight talk on scope

What we can archive

  • Governed rooms for local regulated users

    Prospective, immutable archiving of Matrix / Element rooms for local regulated users on a homeserver you control - room events, edits, redactions (original and replacement both preserved), membership and state, and media when it is available and decryptable.

  • Encrypted rooms, with a device present first

    Encrypted-room capture requires a trusted compliance participant and device present in the room before messages are encrypted, plus our standard supervision, WORM, legal hold, search, and reporting.

What we cannot do

  • No pre-admission encrypted history

    We cannot decrypt encrypted history from before the compliance device held room keys - no keys exist for it. This is a property of Matrix E2EE, not something we can engineer around.

  • No forced capture of third-party or federated rooms

    We archive rooms your homeserver participates in, and only to the extent the compliance user can be admitted and trusted. Where remote servers or room admins can exclude the compliance participant, we cannot guarantee coverage.

  • Redactions and media have limits

    We cannot recover original redacted content that was not captured before the redaction, and media capture depends on fetching and decrypting media while it is still available from the media repository.

  • Calls and deployment

    Matrix voice and video call signaling can be archived as events, but live call audio and video recording is not promised unless separately built. Deployment requires homeserver admin cooperation - it is not a self-serve OAuth click.

FAQ about Matrix / Element Compliance Archiving

Is Matrix archiving available today?
No. It is an early-access, planned capability. We are announcing it ahead of build to open a design-partner program with regulated organizations already running self-hosted Matrix. Request access and we will bring you into the program.
How do you archive end-to-end encrypted Matrix rooms?
As a trusted participant, not as a server that reads ciphertext. Matrix encrypted rooms use Megolm, so the homeserver never holds plaintext. Capture uses a dedicated, cross-signed compliance device that is admitted to the room and receives Megolm room keys the same way any verified device does, then decrypts locally. There is no server-side decryption.
Can you archive messages sent before we deployed the compliance device?
Not for encrypted rooms. The compliance device can only decrypt messages sent after it holds the room keys - no keys exist for earlier encrypted history. Unencrypted history can be backfilled through the Synapse Admin API.
What about federated rooms hosted on other homeservers?
We archive rooms your homeserver participates in, and only to the extent the compliance user can be admitted and trusted. A Synapse module cannot reliably control state changes that originate on remote servers without risking federation divergence, so we do not claim to force capture of arbitrary third-party or federated rooms.
Do we have to trust the compliance device?
Yes. Matrix and Element clients may withhold room keys from unverified devices by default, so the compliance device has to be verified and cross-signed under your device-verification policy. That trust step is deliberate - it is what makes credible encrypted-room capture possible.
Will the capture agent be open source?
That is the plan. The capture agent and the Synapse enforcement module are intended to be open source and auditable so your security team can inspect them before running them inside your infrastructure. The repository is not published yet, so we are not linking one - design partners will get access as it lands.
What do our homeserver admins need to do?
Register our Application Service in Synapse and provide the AS token, provision the @compliance-archive bot account, install our enforcement module, and provide a network path to the homeserver. The Matrix Archiving requirements page in our docs walks through each prerequisite.

Running Matrix in a regulated environment?

Join the design-partner program. Request access and we will scope Matrix archiving against your homeserver, your rooms, and your supervision obligations.

Get in Touch Pricing

Where to go next