A protocol for human correspondence in the age of AI.
Marque is a cryptographically signed, federated messaging protocol proposed as the successor to SMTP and IMAP. It replaces email over a 10–20 year transition while bridging bidirectionally to legacy mail from day one — so no correspondent is ever left behind.
Marque treats identity as a portable W3C DID the user owns, not an address the provider rents. Content is wrapped in MLS (RFC 9420) for end-to-end encryption by default. Legal proof is a tiered option that maps to eIDAS 2.0 QERDS. HTML's frozen 2005 subset is replaced with a typed, signed block format. Non-repudiable timestamps are anchored in Bitcoin via OpenTimestamps at zero marginal cost while keeping message content, routing, and identity entirely off-chain.
Warning
Active draft — expect breaking changes. This repository is the v0 founding specification and is under active modification toward a v1 proposal. Wire formats, identifiers, normative requirements, terminology, repository layout, and even the protocol's externally-visible commitments may change substantially before the first WG draft. Do not treat any commit on master as stable. Pin to a tagged release (none yet — first tag will be v0-founding) before depending on anything here.
Note
Status — pre-RFC founding specification. Target track: IETF Standards Track with ETSI ESI and W3C DID WG liaisons. Target IETF submission: Q3 2026. Spec v1.0 target: 2028. The repository CHANGELOG tracks every revision.
Important
Reserved names — none of this exists yet. During the pre-charter phase, every reference in this repository to the marqueproto.org domain, the marque-protocol GitHub organization, the editors@/security@/conduct@marqueproto.org mailboxes, the marque-discuss mailing list, and the Internet Mail Identity Foundation (IMIF) describes the proposed end-state, not a current entity. None of those names is registered, hosted, or resolvable. JSON-Schema $id and JSON-LD @context URIs under marqueproto.org are stable identifier URIs by design and do not need to resolve. Pre-charter contact channels: security reports go through a private GitHub Security Advisory; conduct concerns and general questions go through GitHub Discussions.
Tip
If any acronym below (KERI, QERDS, FROST, ML-DSA, OTS, …) is unfamiliar, the glossary and citation hub defines every term with a one-line meaning and a link to the authoritative source.
Start at spec/00-overview.md — ten minutes, three reading paths.
| Audience | Reading path | Time |
|---|---|---|
| Executive / funder | docs/whitepaper.md |
15 minutes |
| Product person | overview/01, 02, 03, 04 |
30 minutes |
| Implementer | overview/02, then overview/05 for the implementation-sequencing plan, then protocol/01–10 in order |
4 hours |
| IETF reviewer | drafts/draft-tamim-marque-arch-00, then protocol/02, 03, 05, 07, then context/05 |
2 hours |
| QTSP / trust-list operator | docs/compliance/eidas-mapping.md, then protocol/07-legal-proof.md |
1 hour |
The specification is organized in three tracks:
spec/
├── 00-overview.md Marque in 10 minutes
├── overview/ Product, UX, adoption
├── protocol/ Normative wire formats, identity, crypto, content, legal proof
└── context/ Blockchain scope, commerce, migration, naming, risks, related work
| Commitment | What Marque commits to |
|---|---|
| Portable identity | A did:mail the user owns — a long-lived keypair with a KERI-style signed rotation log. Provider change is an entry edit; no correspondent updates anything. |
| End-to-end encryption | Encrypted by default via MLS, with a per-message deniability-vs-non-repudiation choice and a post-quantum hybrid cipher suite. |
| Legal proof | Native and tiered: see the ProofEnvelope. Maps to eIDAS Article 43 / 44 (ERDS / QERDS). Anchored in Bitcoin via OpenTimestamps. |
| Commodity providers | Dumb encrypted mailboxes. Store envelopes, not conversations. Never read content. Never own conversation state. See provider-role.mmd. |
| Typed content | The Marque Block Spec (MBS) — typed, signed, schema-validated blocks. Not HTML tables. Deterministic rendering, native accessibility. |
| Anti-spam | Economic and cryptographic: verified identity, Argon2id proof-of-work, refundable bonds, gossip reputation. Content filtering has hit its ceiling. |
| Fair competition | Providers compete on features, not address lock-in. Portable identity forces it. See spec/context/02-commercial-model.md. |
| SMTP interop | Bidirectional SMTP bridge, opportunistic, clearly labeled, for 10–20 years. See smtp-bridge.mmd. |
Marque is a composition of components that work in production today — Bluesky AT, MLS, Sigstore, OpenTimestamps, PEC, Hyperswarm, SimpleX, MIMI, FROST, Argon2id, BLAKE3, QUIC — wrapped in an opinionated architecture with firm red lines against on-chain content, per-message gas, wallet-only identity, single-provider capture, server-owned conversation state, and spec-optional extensions. Every component above is defined and linked in the glossary and citation hub.
marque/
├── spec/ Specification (overview / protocol / context)
├── drafts/ IETF Internet-Draft source (2 complete, 1 informational, 6 stubs)
├── mips/ Marque Improvement Proposals — process and template
├── schemas/ JSON Schema + CDDL for envelopes, DIDs, blocks
│ ├── cddl/ Normative CBOR wire format
│ ├── _defs/ Shared schema fragments
│ └── blocks/ One file per core.* MBS block type
├── examples/ Worked envelopes, DID documents, ProofEnvelopes, MBS messages
├── docs/ Whitepaper, FAQ, glossary, architecture overview, roadmap, editors
│ ├── compliance/ eIDAS ↔ Marque mapping for QTSPs and trust-list operators
│ └── diagrams/ Mermaid sources
└── .github/ Issue templates, PR template, CODEOWNERS
- Identity stack — three-tier key hierarchy and the DID document.
- Message path — P2P, store-and-forward, and mixnet delivery.
- Provider role — what the dumb encrypted mailbox does and refuses to do.
- ProofEnvelope — how Casual, Attested, and Certified compose.
- SMTP bridge — inbound discovery and encryption upgrade.
- MIP lifecycle — Idea → Draft → Review → Last Call → Final.
All six are rendered inline in docs/architecture-overview.md and MIP-0001.
- Read the spec overview first — ten minutes, three audience-specific reading paths.
- Read the FAQ — most recurring questions have short answers.
- Propose a change via a Marque Improvement Proposal. Start from
mips/mip-template.md. - File an issue using one of the issue templates — bug report, spec clarification, or MIP stub.
- Contribute per CONTRIBUTING.md.
- Report a security issue privately per SECURITY.md.
- Governance is documented in GOVERNANCE.md.
Marque composes from proven systems. Each reference below is a debt we acknowledge, detailed in spec/context/06-related-work.md:
- Bluesky AT Protocol — data-provider separation, account migration at scale.
- MLS / RFC 9420 — end-to-end group key agreement.
- KERI — append-only key-event-log discipline for portable identity rotation.
- Sigstore Rekor and OpenTimestamps — transparency and Bitcoin anchoring.
- Italian PEC — legal-tier registered electronic mail at scale.
- Hyperswarm — P2P UDP holepunching.
- SimpleX — metadata-private message queues.
- MIMI WG — async MLS transport.
- FROST / RFC 9591 — threshold Schnorr signatures.
- Argon2id / RFC 9106 — memory-hard PoW.
- BLAKE3 — content-addressed hashing.
- QUIC / RFC 9000 — modern transport.
The Mailroom MTA (Documents 1–2 of this research series) is an example AI-native implementation of the provider role. It is not privileged; no implementation in the Marque ecosystem is. Implementers are unrestrained in how they differentiate — AI triage, UX, search, discovery, storage strategy, compliance posture — subject only to passing the conformance suite at the wire. Every implementation that passes the suite is a peer.
Marque defines the wire protocol; Mailroom is one of many expected provider implementations — the HTTP / nginx relationship, not HTTP / Chrome. A second, third, and Nth provider implementation, each from an unaffiliated group, is explicit charter-level policy.
Marque — the specification, the Internet-Drafts, the schemas, the whitepaper, the eIDAS compliance mapping, the architecture diagrams, the MIP process, and the supporting prose — was researched and written by Tamim Bin Hakim in collaboration with Claude (Anthropic). The human is the author, architect, and decider; Claude was research partner, drafter, reviewer, and foil.
We credit Claude plainly — in commit Co-Authored-By: footers, in Acknowledgments sections, and here — because:
- A specification of this ambition is not research a single human completes in a reasonable window without capable tools. Using a capable AI is not a shortcut; it is how current work gets done.
- Pretending a document was wholly human-written when it wasn't is dishonest, and hiding AI contribution to avoid reviewer bias is a form of reviewer manipulation.
- Marque exists partly because of AI-created pressures on email (LLM-generated phishing, prompt injection into inbox assistants, AI-scale reputation-gating). Using an LLM to reason about the protocol that defends against those pressures is neither ironic nor contradictory — it is the honest division of labor.
- Responsibility for every normative MUST and every regulatory citation remains the author's. Claude is acknowledged; Claude is not a co-editor of record.
This convention is open to contributors who prefer to work without AI assistance and to those who prefer to credit their AI collaborator similarly. Either way, the Co-Authored-By: footer is the place to say so.
Dual-licensed:
- Specification text under Creative Commons Attribution 4.0 (CC-BY 4.0).
- Reference code and schemas under Apache-2.0.
See LICENSE for the full text.