Registration service
Phone-number registration and verification-code flow.
MATRIX CHAT Documentation
Technical information, without the guesswork.
Architecture, security boundaries, client behavior, data lifecycle, operations, and verification for the MATRIX CHAT private beta.
Overview
What MATRIX CHAT is
MATRIX CHAT is an independent secure-communication project based on Signal-origin client and server architecture. It combines client-side end-to-end encryption with MATRIX-specific registration, infrastructure, retention, branding, and release controls.
Documentation contract
Every capability is labelled by status. Planned behavior is not presented as deployed, and deployed behavior is not presented as verified until its gate has passed.
01 / PROJECT STATUS
Current implementation map
This public map describes the beta at a safe level and intentionally excludes addresses, credentials, internal topology, and operational secrets.
implemented
iOS client
Branding and client adaptation in active development.
Windows client
Private alpha 8.26.0-alpha.5 is available for invited testing; signed public release pending.
Production messaging
Activation follows infrastructure and audit gates.
RAM-disk storage
Selected short-lived server data is stored on active RAM disk.
Public developer API
No stable public API contract has been released.
02 / ARCHITECTURE
Trust is kept at the edge
Message content is encrypted by the client before it is submitted to the service. Server components coordinate registration, delivery, device state, and short-lived operational work; they are not intended to become a readable archive of private conversations.
01Sender clientEncrypts for approved recipient devices
→02MATRIX serviceRoutes encrypted envelopes
→03Recipient clientAuthenticates and decrypts locally
Service boundaries
- Client boundaryIdentity material, session state, encryption, decryption, and user-visible trust decisions.
- Registration boundaryPhone-number bootstrap, verification-code validation, and device enrollment.
- Messaging boundaryAsynchronous delivery of encrypted envelopes and device-specific queues.
- Storage boundaryExplicit separation between required durable configuration and data that should expire.
03 / ENCRYPTION MODEL
Independent keys for evolving sessions
MATRIX CHAT is designed around the Signal Protocol family. A session begins by combining published device key material into a shared secret. From that point, conversation keys evolve instead of remaining fixed, and each enrolled device maintains its own cryptographic relationship.
Identity keys
Longer-lived device identity material anchors recognition and safety verification.
Session setup
Pre-published key material allows an encrypted session to start even when the recipient is offline.
Key evolution
Ratchet-style key changes reduce the value of a single captured session key.
Multi-device
Messages are prepared for each approved device rather than protected by one shared account key.
Beta verification note
The exact algorithms and compatibility guarantees belong to a versioned client build. Before public launch, published build identifiers and reproducible checks must confirm that implementation matches the stated model.
04 / IDENTITY & REGISTRATION
Controlled account bootstrap
MATRIX CHAT registers an account with a phone number and a verification code. The phone number establishes the registration identifier; it does not replace cryptographic device identity.
- 1Phone number
The user enters the phone number that will identify the registration.
- 2Verification code
The registration is confirmed with the code delivered for that phone number.
- 3Device enrollment
The client creates or imports the material required for its device identity.
- 4Contact verification
Users verify important contacts through an independent channel when risk requires it.
05 / CLIENTS & DEVICES
One account, separately trusted devices
iOS
iPhone & iPad
Primary mobile client path for registration, conversations, calls, groups, and linked-device approval.
in progressWIN
Windows
Private alpha 8.26.0-alpha.5 is available for invited testers. Signed public release pending.
private alphaInvited testers can obtain the Windows private alpha from the MATRIX CHAT download page. Everyone else should wait for the signed public release and its verification information.
06 / RAM-DISK DATA POLICY
Temporary by design
The storage model distinguishes configuration that must survive a restart from operational data that should not. Selected short-lived data is stored in volatile memory so it does not silently become a permanent disk, snapshot, or backup record.
VolatileSelected queues, transient work, and temporary tracesExpires or disappears on restart
DurableMinimum configuration and records explicitly required for service integrityControlled, encrypted, and audited
ForbiddenPrivate message plaintext and unnecessary long-term operational residueNot an intended server dataset
Not a replacement for encryption
RAM disk reduces persistence risk. It does not replace end-to-end encryption, access control, key protection, auditability, or tested deletion behavior.
07 / OPERATIONS
Gated changes and reversible states
Production activation follows explicit gates. A command returning success is not enough; runtime state must be read back and the expected condition independently observed.
Preflight
Resolve scope, effective configuration, backup, and rollback before mutation.
Activation
Apply one bounded change with defined stop conditions and no unrelated restart.
Observation
Verify runtime behavior, authentication, trust chain, and negative controls.
Rollback
Restore the previous state and confirm that temporary identities and public traces are removed.
08 / VERIFICATION
VERIFIED has one narrow meaning
A verified artifact has a valid publisher signature and content hashes that match the published manifest. This demonstrates origin and integrity; it does not automatically prove that every claim, interpretation, or security property is correct.
verify_signatureIs this the authentic release?verify_hashesIs its content unchanged?09 / DEVELOPER INTEGRATION
Public integration is not open yet
No stable external API, SDK, bot interface, or production endpoint is currently documented for third-party use. Publishing internal addresses or inferring an API from upstream behavior would create an unsafe and unsupported contract.
01 · Versioned API contract02 · Authentication and least-privilege scopes03 · Rate limits and abuse controls04 · Signed SDK artifacts and examples05 · Security disclosure process
Contact developer supportMATRIX CHAT is an independent project and is not affiliated with Signal Messenger LLC or the Signal Technology Foundation. “Signal” and related marks belong to their respective owners. References to the Signal Protocol describe technical lineage, not product affiliation or endorsement.