Comparison
RVNT vs Matrix / Element
RVNT: A peer-to-peer, post-quantum, end-to-end-encrypted messenger with no phone number and no servers. · Matrix / Element: An open, federated messaging protocol with strong Olm/Megolm end-to-end encryption and no phone-number requirement — but you hold an account on a homeserver that sees rich metadata, and there is no post-quantum crypto or Tor-by-default.
Bottom line: For almost everyone who wants a private, open, self-hostable messenger they can rely on today — especially teams, communities, and organisations — Matrix/Element is the more responsible choice: it's audited, mature, cross-platform, federated, and battle-tested, and it has shown it engages with and fixes security findings when researchers raise them. Choose RVNT only if your specific priorities are metadata minimisation and anonymity that Matrix's account-on-a-homeserver model can't match — no server holding your identity, no email-on-signup, post-quantum key exchange, Tor-by-default routing, and on-device duress protection — and you accept that RVNT is young, unaudited, smaller, and less reliable.
Matrix/Element and RVNT both refuse to require a phone number and both encrypt messages with a Double-Ratchet-derived design, but they answer different questions. Matrix wins clearly on maturity and trust: it's a decade-old open standard with audited cryptography (NCC Group on Olm/Megolm, Least Authority on vodozemac), formal academic analysis, a large user base, government/enterprise deployments, polished multi-platform clients, federation and self-hosting, and reliable offline delivery through homeservers. RVNT has none of that track record and is unaudited and pre-release. Where RVNT aims further is the threat model Matrix's architecture can't fully address: RVNT is fully peer-to-peer with no homeserver holding an account or relaying content, identity is a local proof-of-work key (no @user:server handle and no email-on-signup), the handshake is hybrid post-quantum (X25519 + ML-KEM-768) while Matrix has no post-quantum crypto in its message layer yet, RVNT routes over Tor by default with a mixnet and sealed sender, ships on-device duress defenses, and collects no telemetry. Matrix, by contrast, is federated (homeservers and every participating server in a room see membership, device IDs and timestamps), is classical-crypto-only, has no Tor-by-default or duress feature, and Element offers opt-in analytics. Encryption is also always-on per-session in RVNT, whereas in Matrix it is per-room and can be left off.
The facts, side by side
| RVNT | Matrix / Element | |
|---|---|---|
| End-to-end encrypted by default | Yes | Partial Matrix end-to-end encryption (Olm/Megolm) is available everywhere and modern Element / Element X clients encrypt new direct messages by default and pre-select 'Enable end-to-end encryption' when you create a private room (you can still untick it). But encryption is a per-room property: unencrypted rooms can be created, large public rooms are commonly left unencrypted, and a room cannot be retroactively encrypted. Because coverage depends on the room and the operator, this is 'partial' rather than always-on like Signal. (Separately, Element is making verified-device-only E2EE mandatory from October 2026, tightening encryption hygiene going forward.) |
| Encryption protocol | Hybrid post-quantum X3DH (X25519 + ML-KEM-768) + Double Ratchet, AES-256-GCM | Olm (a Double Ratchet implementation) for 1:1 device-to-device sessions + Megolm group ratchet for rooms; Curve25519/Ed25519 keys, with Megolm message encryption using AES-256-CBC + HMAC-SHA256. Reference implementation is vodozemac (Rust). Olm is Matrix's implementation of the Signal-style Double Ratchet for device-to-device sessions; Megolm is a group ratchet layered on top so one sender key can fan out to many recipients/devices, with each Megolm message encrypted under a derived AES-256-CBC key and authenticated with HMAC-SHA256. Historic implementations used the C library libolm; the current reference implementation is vodozemac, a pure-Rust rewrite shipped as the default in the matrix-rust-sdk. In February 2026 a researcher (Soatok) reported that vodozemac's Olm 3DH path does not reject all-zero (non-contributory) X25519 outputs and defaults the MAC to a 64-bit (V1) length; Matrix.org confirmed the missing check but argued it is not practically exploitable because identity/pre-keys are signed and verified before session setup, and committed to adding the check in a future release. |
| Post-quantum key exchange | Yes | No Matrix E2EE has NO deployed post-quantum cryptography as of mid-2026. Quantum resistance is tracked only as an open discussion in the spec (matrix-spec issue #975, still open); Curve25519/Ed25519 remain in use. Some experimental deployments (e.g. Cloudflare's January 2026 serverless homeserver on Workers) wrap traffic in post-quantum TLS (X25519MLKEM768) at the transport layer, but that does not make the E2EE message layer post-quantum. |
| Requires a phone number | No | No |
| Requires an email address | No | Partial Whether an email (or other third-party identifier) is required to register depends entirely on the homeserver's policy. The flagship matrix.org homeserver requires email verification for sign-up; many community and self-hosted homeservers require none. There is no protocol-level email requirement. |
| How you’re identified | Local Ed25519 keypair, username claimed by proof-of-work | A Matrix ID (@user:homeserver) tied to an account registered on a homeserver; per-device Curve25519/Ed25519 keys are generated on each client. Your identity is an account on a specific homeserver, expressed as @username:homeserver.tld. This is a persistent, human-readable, federated identifier rather than a phone number or a local-only key, which makes you discoverable and links your activity to a hosting operator. |
| Architecture | peer-to-peer | federated |
| Metadata protection | Sealed sender + Tor by default + mixnet (cover traffic, fixed-size padding) | Weak: homeservers can see room membership, sender/device IDs, timestamps, reactions and (in unencrypted rooms) content; for federated rooms this metadata is mirrored to every participating homeserver. E2EE protects message bodies, but Matrix's federated design is metadata-rich: a homeserver stores room state, membership, sender and device IDs, and timestamps, and in a federated encrypted room that data is replicated to every server whose users are present. Element has researched 'hiding room metadata from servers' (e.g. Pinecone/P2P experiments), but standard deployments expose substantial metadata to operators. |
| Routes over Tor by default | Yes | No Matrix/Element does not route over Tor by default and has no built-in mixnet. Clients connect directly to a homeserver over HTTPS; a user can manually run a client through Tor, but that does not anonymize the metadata the homeserver still collects. |
| Open-source client | Yes | Yes |
| Independently audited | No RVNT is pre-release and has not yet completed a formal third-party security audit — the code is open source so it can be reviewed, but treat it as not-yet-audited. | Yes Matrix's cryptography has real, published audit and academic-analysis history: NCC Group reviewed the Olm/Megolm library (libolm v1.3.0) in 2016, and Least Authority audited the vodozemac Rust implementation in 2022 (10 issues raised, 8 fixed during the audit). Academic researchers (Albrecht, Celi, Dowling, Jones) published 'practically-exploitable' vulnerabilities in matrix-js-sdk / matrix-react-sdk in September 2022, largely patched at disclosure, and a 2024 formal symbolic analysis followed. Most recently, a February 2026 disclosure flagged a missing all-zero-key check in vodozemac; Matrix.org acknowledged the gap, disputed that it is practically exploitable, and is patching it. So Matrix is genuinely and repeatedly scrutinised, with a track record of fixing serious findings — far more than pre-release, never-audited RVNT — though it is not flawless. |
| Jurisdiction / who can be subpoenaed | Peer-to-peer (no central operator to subpoena) There is no company-run server that relays or stores message content, so there is no inbox in a data center to subpoena. A small bootstrap server only holds public prekeys + peer-discovery data. | United Kingdom — the Matrix.org Foundation C.I.C. stewards the open standard; Element is built by Element (New Vector Ltd), also UK-based. Each homeserver operator has its own jurisdiction. |
| On-device duress / panic defenses | Yes | No Element offers screen/app lock (PIN/biometric) but no duress or decoy PIN that opens a fake vault, and no coercion panic-wipe equivalent to RVNT's on-device duress feature. |
| Max attachment size | No limit on a direct link (P2P streaming) No size limit on a direct peer-to-peer connection (segmented streaming with resume-on-disconnect). Transfers that fall back to a relay are currently capped at 256 MB until resumable relay ships. | Set per homeserver; Synapse's default max_upload_size is 50 MB There is no single network-wide limit; the sender's (and recipient's) homeserver each enforce a max upload size. Synapse, the reference homeserver (now maintained under the element-hq GitHub org), defaults to 50 MB (max_upload_size), and operators routinely raise or lower it. Files are uploaded to and stored on the homeserver's media repository (encrypted in E2EE rooms), not sent over a direct peer link. |
| Collects telemetry / analytics | No | Partial The Matrix protocol itself collects no analytics. The Element client offers opt-in anonymised usage analytics — per Element's privacy policy a self-hosted Matomo instance in London (some newer Matrix clients use PostHog); it is off unless the user explicitly opts in, and the app works without it. Homeserver operators may separately keep server logs (IP, request metadata). Marked 'partial' to reflect the opt-in client analytics plus operator-side logging, versus RVNT's no-telemetry stance. |
The verdict
For almost everyone who wants a private, open, self-hostable messenger they can rely on today — especially teams, communities, and organisations — Matrix/Element is the more responsible choice: it's audited, mature, cross-platform, federated, and battle-tested, and it has shown it engages with and fixes security findings when researchers raise them. Choose RVNT only if your specific priorities are metadata minimisation and anonymity that Matrix's account-on-a-homeserver model can't match — no server holding your identity, no email-on-signup, post-quantum key exchange, Tor-by-default routing, and on-device duress protection — and you accept that RVNT is young, unaudited, smaller, and less reliable. In short: Matrix protects your messages and gives you ownership of the server; RVNT additionally tries to hide who you are and that you're talking at all, but still has to earn the trust Matrix's audits, scale and history already provide.
Frequently asked questions
Is Matrix/Element end-to-end encrypted by default?
Mostly, but with an asterisk. Element and the newer Element X turn on end-to-end encryption (the Olm/Megolm ratchets) by default for new direct messages and pre-select it when you create a private room. However, encryption in Matrix is a per-room setting: you can untick it when creating a room, many large public rooms are left unencrypted, and a room can't be switched to encrypted after the fact. So it's not the blanket always-on encryption you get from a tool like Signal or RVNT, where every conversation is encrypted with no off switch.
Does Matrix/Element need my phone number or email?
No phone number is ever required. Whether an email is required depends on the homeserver: the flagship matrix.org server asks for email verification at sign-up, while many community or self-hosted homeservers require nothing. Either way you end up with a federated @username:homeserver identity hosted by an operator. RVNT requires neither phone nor email and has no hosted account at all — identity is a local key claimed by proof-of-work.
Who can see my metadata on Matrix?
Your homeserver can. Even when message bodies are end-to-end encrypted, the homeserver stores room membership, device IDs, timestamps and reactions, and in a federated room that metadata is mirrored to every other homeserver whose users are present. Element does not route over Tor by default and has no built-in mixnet, so your IP is also visible to your homeserver. This is the main privacy gap versus a serverless, Tor-by-default design like RVNT, which has no homeserver holding your account and anonymises connections by default.
Has Matrix been security audited, and is it post-quantum?
Audited: yes. NCC Group reviewed the Olm/Megolm library in 2016 and Least Authority audited the vodozemac Rust implementation in 2022, and academics have formally analysed the protocol — including a 2022 disclosure of exploitable flaws in Element's SDKs that were patched at disclosure, and a February 2026 vodozemac report that Matrix acknowledged, disputed as practically exploitable, and is fixing. That's a real, responsive security track record. Post-quantum: no. Matrix's message-layer encryption still uses classical Curve25519/Ed25519; post-quantum support is only an open discussion in the spec. RVNT's handshake is already hybrid post-quantum (X25519 + ML-KEM-768), but RVNT itself has had no independent audit yet.
Comparisons here are kept honest and dated — we name where the other app wins. RVNT is the post-quantum, peer-to-peer option with no phone number and no servers.