DMTAP reference client · MIT · pre-alpha
Your key is your identity. Your node is your provider.
Envoir is the open-source reference implementation of DMTAP — mail, chat, and files reachable at one name@domain, all bound to a single keypair identity held on a node you run, moving through a peer mesh and mixnet designed so that watching the wires never reveals who's talking to whom.
§0 the problem
Email was never really yours
Every inbox today is a courtesy, extended by whoever's server it lives on. DMTAP starts from a different premise: the identity is yours before any provider is involved.
Your address is a lease
It lives on someone else's domain, on someone else's server — and it can be suspended, sold, or shut down without your consent.
The provider can read it
Centralized inboxes mean centralized reading, whatever the assurances. The operator of the mailbox is, by construction, able to see the mail.
Metadata is the whole graph
Even where content is protected, who emailed whom, when, and how often is usually sitting in the clear — a complete social graph, timestamped forever.
§0.3 – §0.4 how it works
Three layers of indirection free your address from any server
A name resolves to a key once. After that, contacts route by key through the mesh — no domain, registrar, or server sits in the middle of an existing relationship again.
A message between two DMTAP identities never touches a mail server. It's built, sealed, and routed hop-by-hop by the sender's own node:
§3.9 naming
One key. One recommended address. A couple of optional pointers.
The identity is always the key — that never changes. name@domain is the address you actually give people: human, and federated so there's no single namespace to squat or fight over. A few other pointers exist for specific jobs; none of them outrank the key.
Both flavours are one format, reachable from Gmail and Outlook on day one, and survive key rotation and even a future post-quantum migration — the name binds to your identity's stable anchor, not to whichever key happens to be signing today (§1.5–§1.6, §3.9.1).
not an address · §3.4.1
Safety numbers — verifying a key, not naming one
Every key has a fingerprint. Rendered as words from a small, pronounceable list, it's easier to read aloud or scan as a QR code than a string of hex:
maple · heron · otter · cabin · river · slate · amber · quill
Two people compare this out loud, in person, or over a channel they trust, to confirm they both pinned the same key for each other — closing the one gap first-contact pinning leaves open. It is never typed to reach anyone: it doesn't route mail, isn't listed among your names, and can't be sent to like an address.
§2 · §5 · §8 · §13 one identity
Mail, chat, files, and login — one key, no central provider
Everything below is kind of the same object — a MOTE — rendered differently by the client. One identity, one mailbox, one set of devices, no separate service to trust per feature.
Three-pane inbox, threading, folders and color labels, star/archive/snooze, scheduled and undo send, rich compose — over the same MOTE substrate as everything else, sealed and mixnet-routed by default.
- Real client protocols: JMAP natively, plus a genuinely complete IMAP/POP3/SMTP-submission surface (CONDSTORE, SEARCHRES, SORT/THREAD…) so existing mail apps just work.
- A verified ✓ badge once you've checked a sender's safety number, and a plain legacy-origin marker on anything that crossed the gateway.
- Calendar and contacts ride the same node as JSCalendar/JSContact MOTEs, with CalDAV/CardDAV compatibility.
Chat
DMs and channels on the same substrate as mail — just a faster default tier. Every conversation states plainly which cryptographic mode it's using, because the two available modes make genuinely different tradeoffs.
- MLS group · signed — the default for channels and any group of three or more; strong forward secrecy and post-compromise security, but non-repudiable by design (RFC 9420).
- Deniable 1:1 — an explicit, opt-in X3DH/PQXDH + Double Ratchet mode for conversations that need cryptographic repudiation; never a silent default.
- Presence and typing indicators are opt-in and off by default — metadata Envoir doesn't turn on unless you ask.
Files
A BLAKE3 Merkle-DAG manifest over encrypted chunks — resumable, deduplicated, swarmed BitTorrent-style, and self-verifying. A shared folder is a group: drop a file, and everyone with membership can read it.
- The file's key travels only inside the sealed MOTE that announces it — holders relay encrypted chunks blind, never able to read what they're serving.
- Small and normal attachments keep the full mixnet privacy guarantee; only very large bulk transfers trade some of that for bandwidth — disclosed, not hidden.
- Removing someone from a shared folder re-keys everything they had access to, by default.
Identity
A safety number is a deterministic fingerprint of your whole keyset, rendered as words or a scannable grid so two people can verify each other's key out-of-band. The same keypair signs you into the web — no password, no central identity provider.
- Root key held cold; each device carries its own signed subkey, so compromising one device never hands over the root, and revoking it is cheap and targeted.
- Recovery is a first-class, versioned policy (phrase / devices / social guardians) with two deliberately asymmetric thresholds.
- DMTAP-Auth: an origin-bound challenge signed by your key — phishing-resistant like a passkey, because a passkey is what gates it.
§7 transport-path provenance
Know which trust boundaries a message crossed — without weakening the mixnet
Every message you receive carries a recipient-only, verifiable record of what it crossed on the way to you: which privacy tier, and whether it ever touched a legacy gateway. That record never leaves your own devices.
What you can learn about a message
- Which tier it arrived on — the metadata-private private tier (mixnet + cover traffic) or the faster, direct fast tier — something your own node observed at receipt, not a claim the sender made.
- Whether it's pure-mesh or gateway-touched. A gateway-touched message carries that gateway's cryptographic attestation, sealed inside the encrypted payload. A native message carries no such attestation — proof it was never plaintext at any gateway.
- A coarse hop-count floor for the private tier (≥3 hops standard, ≥5 high-security) — never an exact path.
What it deliberately withholds: no individual mix node, no exact hop count beyond the profile floor, no per-hop timing — a record that could reveal more would be leaking the exact thing the mixnet exists to hide. This is also the same attestation an operator would bill against, so a gateway charge is independently checkable, never taken on faith.
§17 feature parity
We checked, feature by feature, against the email you use today
52 mail, contacts, and calendar features, audited one at a time against the legacy inbox — a sense-check, not a pitch. Where DMTAP genuinely loses a capability, this says so.
same or better
works, changed shape
legacy premise doesn't survive — correctly
disclosed, not hidden
Contact verification is the real upgrade
Legacy contacts are unauthenticated names. Here every contact is a key, audited by transparency logs and verifiable out-of-band — the one place parity wasn't the goal, improvement was.
Search stays on your device
No provider ever builds a searchable index of your mail. Your always-on node indexes everything locally — the same capability as a server, just held by you instead of them.
What's still open
Full-fidelity encrypted export/backup and a zero-setup org directory aren't fully specified yet — real gaps, tracked in the open spec rather than glossed over.
§6 privacy, honestly
Metadata-private by architecture, not by promise
Content privacy is table stakes. DMTAP also treats the social graph itself — who talks to whom, when, how much — as something to protect.
-
Sealed sender
Intermediaries relay a MOTE without ever learning who sent it.
-
Mixnet + cover traffic
Onion-routed hops, mixing delays, and padding hide timing and size — email's tolerance for latency is what makes this affordable.
-
Push, not poll
Your always-on node receives through the mixnet — there's no store-and-poll step for an observer to time.
-
Private lookups
Name→key resolution is routed through the mixnet too, so the directory never learns who's asking about whom.
honest boundary · §6.6
DMTAP targets a global passive adversary — one that can watch traffic everywhere, but not inject, drop, or delay it at will.
- A global active adversary with unlimited resources can still degrade anonymity — cover traffic and mixing approach a perfect defense asymptotically, never for free.
- Large-file bulk transfer trades some of that protection for speed (the fast/onion tier, not the full mixnet) — a disclosed tradeoff, not a hidden one.
- A seized or keylogged device exposes its whole synced mailbox, not a slice — mitigated by at-rest encryption and recovery, not eliminated.
- v0 key transparency is tamper-evident, not yet equivocation-proof across multiple logs — a real, stated tension while KT gossip matures.
Messages default to private (full mixnet, minutes); fast (fewer hops, seconds) is opt-in and costs some of that protection. Honest, disclosed limits beat a marketing promise of "perfectly anonymous."
§12 operators
Free to self-host, forever. Paid is optional — for not running it yourself.
Envoir is MIT-licensed end to end: protocol, node, gateway, and client. Nothing that matters is held back for a paid tier.
Self-host
$0 · your hardware- Run the node on a Pi, NAS, old laptop, or $2 VPS
- Full protocol: mesh, mixnet, MLS, DMTAP-Auth — nothing gated
- Unlimited by default — the operator seam's self-host implementation is a no-op
- MIT license, auditable top to bottom
Hosted operator
optional · e.g. Envoir Cloud- Someone else runs the always-on node for you
- Billing, quotas, and multi-tenant management
- Same protocol, same client, same privacy guarantees
- Never a crippled feature set — the paid thing is only running it
Both modes are the same code, talking through one documented contract — the dmtap-seam: metering, provisioning, policy, and gateway authorization. Self-host gets the unlimited defaults; a hosted operator implements the same seam without forking or gating the protocol.
§0.5 where state lives
Your key, not our servers
The middle of the network — mesh, mixnet, gateway — is built to hold no durable user data at all. Durability always lives at an edge you control.
| State | Lives on | Notes |
|---|---|---|
| Keys, mailbox, files, retry queue | your node | All durable state — the edge, not the middle |
| Name → key | DNS + key transparency | Stable; small; auditable for silent key swaps |
| Key → location | mesh DHT | Dynamic, signed, TTL'd, self-republished |
| In-flight ciphertext | mixnet / relay | Held only until delivered — content-blind |
| Legacy reputation | gateway | The one real operational cost, if you bridge legacy mail |
start here
Run your own front door.
Two pieces of software, plus DNS you already have. The node holds the mailbox; the gateway is optional and only needed if you correspond with the legacy world.