Modern email can be built from borrowed parts

Overview

The article shows how a complete email system can be assembled from existing, battle‑tested components rather than inventing new technology, proposing HMTP (Hypertext Mail Transfer Protocol) as a clean‑slate redesign that keeps only the user@domain address shape.

Design Principles

The goal is to replace every SMTP element with a standardized HTTP‑based counterpart while preserving the familiar address format.

Bill of Materials

Each problem in traditional email maps to an already deployed standard:

• Transport and status codes → HTTP (used by the whole web)
• Transport encryption → TLS + Let's Encrypt
• User discovery → WebFinger (RFC 7033, used by Mastodon)
• Message delivery → POST to an inbox (ActivityPub)
• Sender verification → Webmention/DKIM pattern (IndieWeb, email)
• Signatures → Ed25519 (SSH, Signal)
• Content encryption → HPKE (RFC 9180, MLS, TLS ECH)
• Identity surviving key rotation → Sigchains (ATProto/Bluesky, Keybase)
• Reading and synchronization → JMAP (RFC 8620, Fastmail)
• Push notifications → SSE / WebPush (browsers)
• First‑contact consent → Message requests (Signal, Instagram)
• Attachments by reference → Content addressing (Git, IPFS, Matrix) All of these are standardized, deployed and battle‑tested at scale; the only novelty is their assembly.

Discovery and Delegation (a better MX)

Discovery is handled by a static JSON document at /.well-known/hmtp/<user> that lists the inbox URL, keys and devices, allowing per‑user delegation without touching DNS. This mirrors what WebFinger already provides for Mastodon, proving the approach scales.

Identity that Survives Key Rotation

Identity is anchored to a cryptographic chain (sigchain) where each new key is signed by the previous one, letting anyone who knew an old key verify a new one without third‑party trust. If the chain is broken, the domain can publish a new key after an announcement period, though the article notes that domain control is a rented asset and can be lost, reproducing the same squatting problem that DIDs aim to solve.

Delivery with a Queue (store‑and‑forward)

Messages are sent via an authenticated POST to the sender’s own outbox; the sender’s server queues, retries with exponential backoff and honors Retry‑After. Each message carries a content‑hash ID, making retries idempotent and eliminating duplicate deliveries caused by missing ACKs.

Signing and Encrypting with the Keys We Already Have

The message is a signed JSON object that includes:

• A content‑hash id
• from, to, date, optional in_reply_to and subject
• An encrypted body sealed with HPKE using the recipient’s X25519 key from the discovery document
• A signature over the object using the sender’s Ed25519 key This construction provides authenticity at rest, source‑based verification (fetching the sender’s .well‑known key), end‑to‑end encryption of the content while keeping headers visible, verifiable threads via in_reply_to by hash, and attachments represented as {hash, url, size} pairs downloaded on demand.

Layered Anti‑Spam

Three layers are proposed:

1. Identity cost – signing as user@domain requires serving the key document at that domain, imposing a financial sybil cost.
2. First‑contact consent – unknown senders land in a requests folder; the recipient must accept before future messages appear in the main mailbox.
3. Optional postage – the server can reply with 402 Payment Required for first contacts, configurable per mailbox, making cold spamming costly.

Reading Gets Specified Too

Reading, synchronizing and searching are delegated to JMAP over HTTP/JSON, with push notifications via SSE or WebPush, keeping the entire send‑deliver‑read‑sync cycle on the same HTTP infrastructure.

Community Feedback

Commenters raised several points:

• @amelius asked whether the design could replace direct‑messaging apps like WhatsApp.
• @syhol disagreed with relying on domain control as a fallback, preferring to start fresh after key loss and criticizing the authority given to domains.
• @8organicbits noted the difficulty of displacing email due to network effects and suggested a migration path with SMTP backward compatibility.
• @wuschel warned that first‑contact consent might merely move the spam problem elsewhere.
• @AKSF_Ackermann pointed out that content‑addressed messages break traditional mailing lists that need to add headers.
• @ccamrobertson preferred keeping email’s mailbox feel and doubted large providers would adopt changes that threaten their models.
• @thesuitonym objected to building everything on HTTP, stating “not everything is hypertext.”
• @aboardRat4 argued that the GUI, not the protocol, is the main barrier to better email.
• @philipwhiuk questioned the benefit of per‑user delegation over traditional MX records.
• @jfb appreciated the postage idea as a real spam solution.
• @zdw suggested the opposite direction: making HTTP more like SMTP for scale.
• @dinkelberg criticized leaving metadata unencrypted, a mistake also present in PGP.
• @bellowsgulch said discarding existing mail stacks makes the proposal unattractive.
• @teddyh likened the idea to 1990s spam‑solution proposals that were ultimately unworkable.
• @jerf warned that embedding entire emails in JSON could force large in‑memory parsing and suggested keeping MIME parts with a JSON header.
• @RajT88 considered email less urgent than improving phone‑call protocols.
• @BeetleB advocated a pricing model where sending email becomes costly with volume, letting recipients charge fees.
• @mlhpdx wondered if CoAP would be a better fit than HTTP and questioned the “modern” label given reliance on stateful JMAP.
• @TeeMassive noted that asymmetric signatures and DHTs are long‑solved, attributing email’s persistence to vested interests of big providers.
• @astrodust highlighted the historical link: HTTP headers descend from RFC822 email headers.
• @rbanffy argued that the lack of email reinvention indicates the current stack is not as broken as claimed.
• @1saadcodes liked the standards‑reuse approach but stressed the challenge of achieving universal interoperability.
• @inigyou observed that ActivityPub is essentially SMTP over HTTP.
• @Keywordstat posted a self‑promotional link (not relevant to the technical discussion).

These comments reflect excitement about reusing existing standards, concerns about domain‑based identity, the practical hurdles of migration and user experience, and differing views on how best to combat spam and preserve useful email features such as mailing lists.

Conclusion

The article demonstrates that every major flaw of SMTP—spam, key management, duplication, lack of encryption, and brittle identity—has a corresponding solution already deployed elsewhere on the web. By combining WebFinger, ActivityPub, Ed25519, HPKE, Sigchains, JMAP and related standards into HMTP, the author shows a plausible, standards‑based path forward. The HN discussion validates the technical appeal while highlighting real‑world obstacles such as network effects, domain reliance, GUI challenges, and the need for backward compatibility, suggesting that any successful evolution of email will need to address both the protocol and the surrounding ecosystem.