A privacy policy is words on a page; an architecture is a structure of impossibilities. DevoraX2 is built so that even if I wanted to read Your messages — I could not. The pages below describe, openly, every layer that makes that statement true.
I do not ask You to trust my intentions. I ask You to trust the structure — and I publish every part of it, so that the trust is verifiable.
DevoraX2 is built in five layers, stacked so that each one only touches the layer immediately adjacent to it. No layer can read above its own. A breach of one layer does not propagate up. That is the entire point of the stack.
The personalized defense profile You set up at install. Knows what factors apply to You, in what order, with what thresholds. Never leaves Your two devices. Wraps everything below it.
The messenger itself: chats, calls, Worlds, settings. Touches Personality above and Cross-Guard below. Never sees raw cryptographic material. Talks only in opaque tokens.
And the structure inside is Yours. What I call “Worlds” You can rename to anything — the levels, the depth, the nesting logic are Yours to draw. That schema is encrypted on Your device, like keys. My relay only ever sees opaque UUIDs and sealed blobs; it never learns that one blob is a “World” and another a “Topic.” The meaning lives only on Your device. I call this layer the Personal Structure Schema (PSS) — security through diversity, because no two structures are alike, and an exploit shaped for one user finds nothing on another.
Signs every sensitive action between Device A and Device B. Lives between the application and the cryptographic core — it cannot decrypt what it signs, and it cannot sign what it decrypts. A different key for every action.
PQXDH key exchange + ML-KEM-1024 (post-quantum), Double Ratchet (forward and future secrecy), ChaCha20-Poly1305 (authenticated symmetric encryption), Sealed Sender (metadata privacy). The only layer that touches plaintext. Everything above it is opaque to itself.
Sealed packets between devices and my relay. WebSocket, QUIC, fallback to HTTPS. The transport layer cannot read the cryptographic core above it — it sees only ciphertext addressed to opaque session tokens.
The runtime topology has three live participants — Device A, Device B, and a relay (which I call "the server"). Each node has a precise scope of what it knows, and an explicit boundary of what it cannot.
All Your messages, contacts, keys, settings. Decrypts incoming and encrypts outgoing. Holds the runtime.
Change passwords, pair devices, disable modes, export archives, or remove Cross-Guard alone.
Sealed packets, opaque session tokens, presence pings. Routes encrypted blobs from one opaque address to another.
Read message contents, see who is talking to whom (sender identity is sealed), forge signatures, or alter Cross-Guard handshakes. Not "will not." Cannot.
Sensitive-action requests from A. Their signatures, contexts, timestamps. Approves, denies, freezes, wipes, reissues.
Hold a permanent copy of all messages, act in real-time chat. It is the authority, not the runtime.
The vault is not a live participant — it sleeps, waiting. It receives continuous and panic backups from Device A, sealed end-to-end with keys only You can derive. My server cannot read the vault; the vault provider cannot read the contents. You choose its location at install (see Section V below).
The core is built from four standard, well-audited cryptographic primitives. None of them is novel. Novelty in cryptography is the most expensive feature there is — and I will not pay that bill on Your data.
Hybrid: classical and post-quantum at the same time. An adversary must defeat both to derive a session key — one of which has no known quantum attack.
A new key for every message; the previous is destroyed on use. Compromising one message's key reveals only that message.
The same cipher trusted by Signal, WireGuard, and TLS 1.3 worldwide. A single bit flipped in transit causes a loud failure.
My relay does not learn who is talking to whom — only that two opaque session tokens are exchanging packets. The relationship graph never exists on my side.
Every device carries one long-term identity key. The private half never leaves the device; the public half is what other devices verify against when a session opens.
Used for content addressing of encrypted blobs and integrity commitments on the audit log. Fast, parallel, and modern — the successor to BLAKE2 in the same family of vetted hash designs.
The vault unlock and GraphPIN material run through Argon2id before they ever touch a symmetric key. A guessing attacker pays full memory cost per attempt — brute force scales with hardware, not patience.
Glues the hybrid KEM output into the session key, with a separate label per ratchet step. The same primitive that derives session keys in TLS 1.3. Simple, audited, hard to misuse when the labels are written down.
For the full breakdown, the four-layer crypto deep dive lives in Security · 01 · Encryption →
Most messengers are honest about what they do and quiet about what they could. I do the opposite: I say loudly what is impossible by design. If my entire infrastructure were breached tomorrow, here is what an attacker would walk away with.
The vault is where Your continuous backups and panic-snapshots live. It is never decrypted outside Your devices — which means I can offer five different vault locations without losing anything from the security model. The location is convenience. The encryption is the constant.
Hosted by me, on infrastructure I operate. Sealed end-to-end — I host opaque blobs. Easiest setup, no dependencies.
Available · Phase IIA small daemon You run on Your own VPS, NAS, or homeserver. The opaque blobs never leave infrastructure You control.
Next · Phase IVBackups pinned to IPFS via Pinata, Filebase, or Your own node. Content-addressed, replicated, censorship-resistant.
Next · Phase IXPeriodic offline writes to a hardware-backed device (USB enclave, dedicated SSD). Air-gapped during attack windows.
Future · Phase XIVA vault hosted by an organization You belong to (a company, a publisher, a coalition). Same protocol, governed locally.
Future · Phase XVEvery secure system has a trust model — a list of things that, if compromised, the system assumes are not. Most companies blur this list. I list it explicitly: what I trust, what I do not, and why.
Signal Protocol. ML-KEM-1024. ChaCha20-Poly1305. Standard, peer-reviewed, audited for decades. If the math fails, the entire field fails before me.
Every line of cryptographic implementation is published, audited, and reproducibly built. I trust what You can verify, not what I promise.
The pair You set up. I trust them by design — they are the only places where plaintext ever lives. If both are compromised simultaneously, the model breaks; that is why Cross-Guard exists, that is why Modes exist.
The words You wrote on paper at install. I trust You to keep them somewhere I cannot reach. The system that needs no master key delegates all sovereignty to You.
I do not need to be trustworthy for this to work. I could be malicious, careless, subpoenaed, or insolvent — the architecture means I cannot read Your messages either way. The point of the design is to remove ourselves from Your trust list.
Whoever hosts my relay sees only sealed packets. They cannot read content, cannot identify who is talking to whom. A breach of my hosting provider yields encrypted noise.
I cannot hand over what I do not have. Subpoenas yield ciphertext. Gag orders cannot force me to read a file I have no key for. The architecture is the legal answer.
A privacy product that ignores its own failure modes is a product that has not thought about them. I have. Here are the three most consequential breaks — and what survives them.
What if DevoraX2 the company disappears tomorrow?
→ The answerThe messenger keeps working between paired devices. Your vault remains accessible — if You self-host, indefinitely; if You used my cloud, until my hosting bill defaults (and the open-source migrator lets You move it before that). I am not a single point of failure for Your past. I am at most a single point of failure for my future updates — which is why the code is open and reproducible.
What if the relay goes down?
→ The answerDevices buffer outgoing messages locally and retry. Cross-Guard handshakes are queued and resume on reconnect. Federated relays (Phase XV) provide alternates; until then, a regional outage causes delays, never data loss. Notifications fall back to SMS channels where opted in. The pause is the worst case.
What if an audit finds a flaw?
→ The answerPublic pause. Versioned migration. I will not ship a fix that hides the original flaw — both the report and the remediation become part of the audit trail. Trust is rebuilt by transparency, not silence. If I cannot rebuild it, I say so — and tell users to migrate to whatever survives the failure. I will not pretend that bad news did not happen.
I could have built a simpler messenger. I chose not to, three times over. Here are the three decisions that made DevoraX2 what it is — and why each tradeoff was the right one.
A single device is a single point of failure — and a single point of coercion. With one phone, one PIN, one biometric, You and an attacker who holds Your phone are functionally indistinguishable to the lock. Two devices give the lock a second voice to ask before it opens. The cost is owning a second phone. The benefit is that the first phone alone does not end You.
A privacy product whose code is closed is a product asking for trust on words. I do not want that kind of trust — it does not survive a single bad week of news. So I publish the code, the protocols, the audits, the architecture. If I ever ship a backdoor, the open-source community will see it before my investors do.
A consumer messenger ships a feature in a sprint and apologises later. I cannot apologise my way out of broken encryption. So I ship slowly, and only when the math is ready. Investors who want hockey-stick growth tend to leave me. That is part of the design too.
If You want to read the cryptographic deep dive, the dual-device protocol, or the modes that protect You under pressure — the Security pages go layer by layer.