The DMCN Protocol · dmcn.dev

DMCNP · an open protocol · Apache-2.0

Cryptographic identity replaces SMTP-style trust.

An open protocol for end-to-end-encrypted mail. Your address is a keypair. Your domain serves its own records, found through DNS. There's no global directory to censor, and no server in the middle that can read mail sent between DMCN addresses.

Read the spec The schema Try it

What it is

In traditional email a sender can claim to be anyone, and there is no reliable way to know they aren't. Believing them is a best guess the receiver makes after the mail has already arrived — which is what spam filters are for, and why phishing works at all.

DMCNP does what SMTP cannot. It moves a message from one person to another with verifiable proof of who sent it, because the address is bound to a key. alice@example.com names one specific public key, published by example.com and signed so anyone can check it. A message either verifies against that key or it doesn't.

Everything else follows from that. If the address is a key, mail can be sealed to it before it leaves your device — so the servers in between carry bytes they cannot read, and authenticity stops being something anyone has to guess at.

Look it up

Your client reads a DNS record for the recipient's domain, fetches their signed identity record from that domain's own servers, and checks it against the fingerprint the DNS record published.

Seal it to their key

The message is encrypted on your device, to that key. Header and body are sealed separately and padded to fixed sizes, so neither the contents nor the shape gives anything away.

Leave it at their relay

The sealed envelope goes to a relay the recipient nominated. They collect it by signing a challenge the relay sends — the key never leaves their device — and the relay hands back bytes it cannot read, for them to verify and open.

Two names, because they mean different things. DMCN is the network — the deployments that actually exchange mail. DMCNP is the protocol they speak, and that is what this site specifies. You can implement it under any name you like.

A domain joins by publishing one DNS record

_dmcn.example.com  TXT  "dmcn-verification=v1; fp=<40-hex>; seed=/ip4/…/tcp/7400/p2p/<peerID>"

fp= is the trust anchor. seed= is where to dial. Records sign themselves, so a hostile server can refuse to answer you — it can't lie to you.

What you'd implement

Seven layers. Speak all of them and you interoperate with the network.

User identity

An Ed25519 signing key and an X25519 key-exchange key. The address is local@domain, and its record signs itself.

Resolution

A _dmcn.<domain> TXT record gives you a fingerprint to trust and a few nodes to dial. You fetch signed records from that domain's own nodes and check them against the fingerprint.

Message model

PlaintextMessage → SignedMessage → EncryptedEnvelope. One AES-256-GCM key per message, wrapped to each recipient over X25519. Header and body seal separately, and both get padded to fixed size classes.

Routing

RelayHints say which relays hold a mailbox. They sit outside the owner's signature, so an operator can move a mailbox without the owner's key — and the address never changes.

Relay service

/dmcn/relay/1.0.0 — store, fetch, mailbox operations, record lookups, onion forwarding. Length-prefixed protobuf over libp2p.

Trust & federation

Each domain has an authority record, anchored in DNS, that delegates to issuers. Peers swap and verify credentials at /dmcn/join before they federate.

Transport

libp2p streams. Discovery is DNS-seeded — no DHT, on purpose.

What's in the core

What you need to interoperate: resolve an address, verify an identity, send mail, receive mail. Plus two optional capabilities — onion routing and an SMTP bridge — that you can skip entirely.

What's left out

Anything an operator wants but the network doesn't need: fleet admin, hosting permits, entitlements, quotas. Those are extensions, and they attach through surfaces the core designs for them — never through new core fields.

Ignore every extension and you're fine

That's the rule the split protects. An extension can give an operator new powers. It can never make your implementation stop interoperating. Retired field numbers stay reserved forever.

Start with the schema#

The protocol is four .proto files. They define identity records, credentials, the message envelope, and the relay wire format — and they're the contract, not the prose. If the spec and the schema ever disagree, the schema wins.

Everything else on this site exists to explain them.

Why there's no global directory#

Most decentralised messaging puts identity in a shared overlay: a DHT, a chain, a consensus set. DMCNP doesn't, and the reason is boring rather than ideological. A big enough hostile majority in a shared overlay can quietly withhold records. For something meant to replace email, that's fatal.

So resolution works like mail delivery already does. A domain publishes a _dmcn TXT record with its trust anchor and a few seed nodes. You read it, dial that domain's own nodes, fetch the signed record, and check it against the anchor from DNS.

A domain is served by the nodes its own DNS names — its own, or a host it explicitly delegates to — never by a shared pool it doesn't choose. Records sign themselves, so a server that isn't your domain's authority can refuse to answer you; it can't lie to you.

Naming and licence#

Apache-2.0 covers the code and the schema, patent grant included. It does not cover the names. Implement the protocol under whatever name you like — just don't call something DMCNP unless it really conforms, because that name is how people know what they're getting.

Where it's up to#

This is a snapshot, not a frozen standard. The schema moves with the reference implementation, and the implementation wins where they disagree. Formal versioning and a conformance suite aren't done yet.

The wire schema is the compatibility contract. Everything under internal/ is just how one implementation happens to work, and carries no stability promise.

Want to see it running first?

dmcnd is a small reference server — one domain, one process, webmail included. It's there to read alongside the spec and to check your own implementation against. It isn't the protocol.

Try it