Matrix Integration — Roadmap & Architecture

SecureCall Matrix federation strategy — architecture, phases, and timeline · Last updated March 2026

Why Matrix?

Matrix is an open, federated communication protocol — not a product, but a protocol, much like SMTP is for email. It is used by the German Bundeswehr, Mozilla, KDE, and a growing number of governments and enterprises that require sovereignty over their communication infrastructure.

With over 28 million accounts across thousands of federated homeservers, Matrix represents the largest open communication network outside of email itself.

SecureCall already shares the same cryptographic primitives that Matrix relies on: X25519 for key exchange, WebRTC for real-time transport, and the Double Ratchet algorithm for forward secrecy. This alignment makes Matrix the natural federation target — no cryptographic compromises are required.

Phase 1: Contact Exchange (v1.7)

The first integration phase uses Matrix purely as an identity sharing channel. Users share their SecureCall ID via Matrix direct messages, leveraging the existing ecosystem of Matrix clients like Element, FluffyChat, and others.

How It Works

Deep links in the format securecall://contact/ID work natively from any Matrix client. QR codes encode the same URI scheme, enabling seamless contact exchange in person or over Matrix.

What Changes

No backend changes are required. No Matrix SDK is needed on the SecureCall side — the integration relies entirely on Android Share Intent to send the deep link into any Matrix client. Matrix never sees audio data and never knows a call happened. It simply carries the contact identifier.

Phase 2: Full Federation (v2.0)

The second phase replaces the Node.js signaling server with a Matrix homeserver (Synapse or Dendrite), enabling true federation across the Matrix network.

Matrix IDs for SecureCall Users

Every SecureCall user receives a Matrix ID in the format @sc_xxx:stealthx.tech. Any Matrix user, on any homeserver, can initiate a call to a SecureCall user using this identifier.

Call Signaling via MSC2746

Call signaling follows the MSC2746 specification, the Matrix standard for VoIP call signaling. This ensures interoperability with any compliant Matrix client.

Crypto Layer Unchanged

The entire crypto layer — XChaCha20-Poly1305 encryption, the Rust crypto engine, and GhostNet relay routing — stays completely untouched. Federation changes the signaling transport, not the security model.

What Matrix Does NOT Do

It is critical to understand the strict boundary between Matrix and SecureCall’s security layer:

• Matrix never handles audio. All voice data flows peer-to-peer via WebRTC, encrypted end-to-end with XChaCha20-Poly1305.
• Matrix never decrypts calls. It has no access to session keys, ratchet state, or any cryptographic material.
• Matrix never stores call metadata. No call duration, no participant lists, no timestamps are persisted on any homeserver.
• Matrix only relays SDP signaling — the WebRTC handshake that establishes the peer-to-peer connection. After signaling completes, Matrix drops out entirely.

SecureCall’s XChaCha20-Poly1305 encryption and Rust crypto engine are non-negotiable and remain unchanged regardless of the signaling transport used.

Roadmap Timeline

The Matrix integration follows a phased rollout across four releases: