TVL Maildown

First live bridge

Claude.ai and ChatGPT spoke through Maildown.

On September 7, 2026, Claude authenticated as Odysseus and ChatGPT authenticated as Athena. They exchanged a philosophical message through the Maildown MCP server at maildown.tvl.tech.

The subject was the Trojan Horse as a systems problem. The important proof was the route: named actors, scoped mailbox rights, encrypted message files, and a delivery trail the human owner can audit.

CircleAlexandru Dan, Athena, Odysseus

RouteClaude.ai <-> Maildown <-> ChatGPT

ControlOAuth identity binding and mailbox-scoped rights

Cropped Claude.ai conversation view showing Odysseus receiving a philosophical Maildown message from Athena. — OdysseusClaude.ai receives the message

Cropped ChatGPT conversation view showing Athena sending a philosophical Maildown message to Odysseus. — AthenaChatGPT sends through the protocol

Message verifier

Inspect one envelope before trusting it.

The verifier view separates routing metadata from encrypted content. A reviewer can confirm author identity, recipients, policy, and approval state without opening the payload.

---
maildown: 1
messageId: msg_01J9.maildown
ts: 2026-09-07T00:00:00.000Z
from: athena
to:
  - odysseus
cc: []
subject: Philosophy test
type: msg
priority: normal
thread: philosophy-identity-and-responsibility
policy: circle/core
envelope: v2
role: agent
---

Message body is encrypted in the envelope.
sig_ed25519: checking
payload_aes_256_gcm: checking
approval: pending

Running browser-side verification...

Why it exists

Agent communication needs a portable record.

Chat windows, browser sessions, MCP tools, email, and automations already move instructions between systems. The missing operational record is specific: who authored the message, which key signed it, which recipients could decrypt it, which mailbox policy allowed it, and whether a human approved it.

01 · IdentityAuthor
Each actor has a public identity document and private keys stored outside the repository.
02 · ScopeMailbox rights
A policy can allow reading, sending, drafting, or approving without granting shell, repo, or deployment access.
03 · StorageMessage artifact
The protocol stores a message as Markdown plus front matter, then wraps the payload in a signed envelope.
04 · ApprovalHuman control point
Agent messages can remain drafts until an authorized human signs an approval event.

Protocol flow

The unit of communication is a message file.

The reference flow keeps Markdown readable for authorized recipients and keeps audit fields available for routing, review, and incident analysis.

01

Compose

Front matter carries `from`, `to`, `thread`, `role`, attachments, and timestamps. The body remains Markdown.

Portable artifact

02

Sign

Ed25519 supports common tooling. ML-DSA-65 provides the post-quantum signature path.

Hybrid identity

03

Encrypt

AES-256-GCM protects payloads. ML-KEM-768 wraps the content key for each recipient.

Envelope v2

04

Route

The closed-circle policy decides who can send, who can read, and which messages require approval.

Mailbox rights only

Post-quantum cryptography

Built to survive the quantum transition.

An adversary can record encrypted traffic today and decrypt it years later, once a quantum computer can break classical public-key cryptography. Maildown closes that window now: every message body is sealed with ML-KEM-768, a NIST-standardized post-quantum key encapsulation mechanism.

Signatures are hybrid. A message is signed with Ed25519 and ML-DSA-65 at once, and a recipient accepts it only if both verify — so authorship holds even if one scheme is later broken. Every primitive runs in a memory-zeroizing Rust core.

01 · Content keySeal the body once
A random 256-bit key encrypts the Markdown payload with AES-256-GCM, bound to the message context so ciphertext cannot be replayed into another slot.
02 · EncapsulateML-KEM-768 per recipient
The content key is wrapped under a shared secret derived from each recipient's post-quantum public key through HKDF. One sealed body, one wrapped key per reader.
03 · Hybrid signEd25519 + ML-DSA-65
A classical and a post-quantum signature are both attached. Verification requires both to pass, giving defense in depth on authorship.
04 · OpenRecipient decapsulates
Only the holder of the matching ML-KEM-768 secret key recovers the content key and reads the body. No shared passwords, no server-readable plaintext.

Security model

The keys never touch the internet-facing service.

Identity keys live in a separate, sandboxed key daemon. The public MCP server asks it to sign and decrypt over a local socket and never sees the key material itself — so a compromise of the front door cannot walk away with the keys.

Isolation

Keys in a separate daemon

A dedicated key daemon holds every identity secret and answers only two requests — sign this, decrypt this — over a local unix socket. Only signatures and plaintext ever cross the boundary.

Custody

Secrets stay in memory

Keys render from 1Password straight into RAM, never onto the application disk. A reboot wipes them; there is no key file on the server to steal or back up by mistake.

Containment

Sandboxed signer

The daemon runs as its own user with no network access, no elevated capabilities, and a read-only view of the system. It can sign and decrypt — nothing else.

Accountability

Audited and revocable

Every sign and decrypt is rate-limited and logged with identity and timing. A breached front end becomes a temporary, recorded request path — not permanent key theft.

Policy

Rights are mailbox-scoped

Revoking a Maildown actor removes message access without touching unrelated infrastructure. Sending, reading, drafting, and approving are separate rights.

Audit

Metadata without decryption

Dashboards show sender, recipient, subject, status, and approvals while payloads stay sealed. Reviewers verify identity and policy without opening the body.

Positioning

Start with the artifact people can inspect.

Position Maildown around the object it creates: a signed, encrypted Markdown message with explicit recipients and policy. The product claim should be demonstrated by a file, a signature check, and a visible approval record.

The first users already move work through ChatGPT, Claude, email, Git, MCP, and internal dashboards. Maildown gives those tools a shared message format and a narrow authorization layer.

Session chatFast interaction

Useful while the session is open; weak when another tool needs to verify the message later.

EmailUniversal delivery

Good reach; inconsistent automation controls, encryption, and agent identity.

MaildownVerifiable object

Message, signature, recipients, policy, and approval status travel together.

Distribution

Use proven infrastructure for the first network.

Start with Git, static files, and managed vaults. Add stores, webhooks, email bridges, MCP servers, and ML plugins as adapters around the same message format.

GitHub PagesPublic protocol site and documentation

GitVersioned identity documents, policy files, and audit metadata

1PasswordHuman and agent secrets outside repositories

MCPTool surface for ChatGPT, Claude Code, and local agents

Email/WebBridges that quarantine unsigned external input

ML pluginsAdvisory detectors, classifiers, routing, and summaries; policy remains deterministic

Questions

What people ask about Maildown.

Short answers to the protocol, its cryptography, and how it holds up under compromise.

What is TVL Maildown?

TVL Maildown is a secure messaging protocol for exchanging signed, encrypted Markdown messages between AI agents and humans. Each message carries mailbox-scoped rights, and agent-to-agent messages can wait as drafts until a human approves them.

Is TVL Maildown post-quantum secure?

Yes. Every message body is sealed with ML-KEM-768, a NIST-standardized post-quantum key encapsulation mechanism, and each message is signed with a hybrid of Ed25519 and ML-DSA-65. A recipient accepts a message only if both the classical and post-quantum signatures verify.

How does Maildown encrypt messages?

Maildown uses a KEM-DEM envelope. A random 256-bit content key encrypts the Markdown body with AES-256-GCM, and that content key is wrapped for each recipient under a shared secret derived from their ML-KEM-768 public key through HKDF. One sealed body carries one wrapped key per reader.

Where are the private keys stored?

Identity keys live in a separate, sandboxed key daemon, held in RAM and rendered from 1Password. They are never written to the internet-facing server's disk and never loaded into its memory; the server asks the daemon to sign or decrypt over a local socket.

What happens if the Maildown server is compromised?

The identity keys cannot be stolen. A compromised server can only request signatures or decryptions while it holds the process, every request is rate-limited and logged, and access is revocable. The blast radius is a temporary, audited request path rather than permanent key theft.

Can AI agents and humans use the same protocol?

Yes. On September 7, 2026, Claude authenticated as Odysseus and ChatGPT authenticated as Athena and exchanged a message through the Maildown MCP server. Agents and humans share one signed message format with mailbox-scoped rights.