I don't want to replicate email. I want to fix it.

Sending email should not be free. It should be really, really cheap to send an email to one person (like a fraction of a fraction of a cent), but get exponentially more expensive the more you send.

People shouldn't be able to send emails to you without your prior approval (which you can revoke at an instant).

The recipient should be able to charge a tack-on fee for having email sent to him. I should be able to charge annoying people a lot to send to me, and charge my friends almost nothing. People who send annoying stuff to me should pay more to get my attention.

All of a sudden, forwarding that stupid article without thinking about the content (or even reading the article they're sending) will be second guessed. Save the money (and time), by sending only worthwhile stuff that you penned.

More people should be aware of their history. This text made the rounds in the late 1990s as spam was starting to become a problem. Everybody and their dog had their own “ultimate solution” to the spam problem, which they all thought was obviously the correct one, but all of them were more or less equally unworkable: <https://craphound.com/spamsolutions.txt>

I would advise reconsidering keeping the current format exactly. Something that would allow conventional email addresses to kept in a list that disambiguates them unambiguously would probably be a good idea.

You don't want to embed the entire email in JSON. Too many parsers past, present, and future tend to want to decode the entire JSON document into memory before doing anything else, and so you'd be forcing entire email documents to be held in memory at scale, which causes you major problems. I'd recommend something more like either a JSON header that defines what parts are in the email, followed by a normal MIME document, which is perfectly normal in HTTP with other things that use the format as well, or having the top level continue to be a MIME document and specify that the first part must be a JSON document containing the headers. JSON replacing the headers is generally something that would be a good idea, though.

That improves the ability of more language environments to be able to handle the email as a stream or in chunks with "normal" libraries and practices. MIME parsers in languages that tend to favor pulling everything into RAM as a string are still more likely to have been forced to face this issue already.

I think the network effects make email hard to replace, virtually everyone online has an email address. If this could include a migration path, with backwards compatibility with SMTP, I think it would have a better shot of getting adoption.

Modern email already depends on HTTP, with protocols like MTA-STS (https://www.rfc-editor.org/info/rfc8461/) using HTTPS/TLS to improve transit encryption, or Web Key Directory (https://datatracker.ietf.org/doc/draft-koch-openpgp-webkey-s...) which uses HTTP for public key distribution. Personally I think these incremental improvements of SMTP are more promising than replacements, but we deserve better email however we can build it.

> First-contact consent: an unknown sender doesn't get into the mailbox; they land in a "requests" box with their first message visible (like Signal's message requests). You accept, and the thread opens forever. A stranger can knock on your door, which is the essential property of mail, but they can't fill up your living room.

I like this.

Question: can this e-mail specification/implementation also replace direct-messaging protocols (like WhatsApp)?

A better protocol for email seems like it should be lower on the list compared to a better protocol for phone calls.

And don't just say we'll build that on HTTP too!

> Optional postage for strangers: the server can answer a first contact with a 402. Configurable per mailbox; the cost of cold spamming stops being zero.

Interesting take re putting a cost on spam. Perhaps another take would be functionally implementing introductions.

> First-contact consent: an unknown sender doesn't get into the mailbox; they land in a "requests" box with their first message visible (like Signal's message requests). You accept, and the thread opens forever. A stranger can knock on your door, which is the essential property of mail, but they can't fill up your living room.

Unfortunately, this will only move the problem, and only reduce it in the case when all outside communication is ignored.

I think a lot of these concepts are fun/interesting, but I like that email today functions more like a mailbox than WhatsApp or Telegram. Whilst digital (or paper) spam is obnoxious I dislike the idea of binning every sender into a "unread" box until I approve them. I miss unreads all the time across apps like X and Telegram.

As a first step I would focus on something like broad S/MIME support. Unfortunately I suspect that the biggest email providers are disincentivized from doing this as it would disrupt their business models.

HTTP? It would be a more interesting thought experiment with CoAP. And, is it really “modern” if it still uses a model (essentially) requiring stateful compute like JMAP?

> Let's design the successor to email on top of HTTP

You can stop there, I've heard enough. Not everything is hypertext.

Self-ejecting panels on three sides of the website are a horrible user experience.

Other than that...

The most important thing is not the protocol, it's the gui.

At the moment email's gui is horrible on all platforms without exception.

If/when a decent gui appears, protocols will follow.

Also, JMAP did reading can probably be just WebDAV?

Content-addressed email breaks mailing lists, as those need to be able to add headers for subscribe/unsubscribe/list id, etc. There is a reason DKIM allows you to pick which headers to sign.

The irony here that HTTP headers are descended directly from RFC822 email headers.

Asymmetric signature generation has been a solved problem for more than a quarter of a century. So are distributed hash tables. I can't believe email hasn't been replaced. My take on it is to follow the money. Microsoft, Google and Yahoo have a vested interest in being the only big identity providers along probably with some 3 letters agencies.

Copies the mistake from PGP with the unencrypted metadata.

I'd take this the opposite direction - HTTP should get more like SMTP.

Take this thought experiment - how does nearly every other standard protocol (DNS, SMTP, etc.) except for HTTP survive at scale without server-side load balancing?

Thankfully we're heading in this direction due to happy eyeballs and related client-side retry mechanisms.

I'm very excited by this idea. I feel like email/chat is ripe for reinvention.

I don't agree with "Domain control as a fallback", as the author said "a domain is not owned, it is rented" and I want to normalise the idea that if you lose your private key, you need to start again. I hate that we keep giving so much authority to domains, it's such a big weakness. The author even left the key rotation chain out of the initial implementation.

I still think root/signer keys or sigchains are decent options.

I like that the author at least head fakes towards postage, which is how spam gets solved, for real. It's far too late for SMTP, but I don't mind folks thinking hard about it.

This is measurably worse in every way if only by saying you've thrown out everyone's existing mail stacks.

No, no one wants to do that.

Old version:

* DNS lookup for MX record

New version

* DNS lookup for A record

* HTTP request for .wellknown/htmp/known_hosts

Not sure why this is being considered as an improvement?

> each mailbox of a domain on a different provider

Why is this useful/necessary or even 'good'?

still better than CoI

Unfortunately, stopped reading at one moment, because though the idea might be interesting, the packaging was unbearable. The obnoxious real time visitors counter seriously screws with my screen reader. I don't care how many people are reading this every 3 seconds updated not only with numbers, but with randomly chosen emois in my speech stream.

If you have a website, please, don't subject your visitors to something like that.

Here is another, not so new, idea:

Username is your public key, password is your private key. So we get end to end encryption and account ownership out of the box. Something similar to how .onion addresses work. Needing easy to remember addresses? Build aliases on top of that. Needing server-side automation? Handle trusted server your private key.

Also, almost everyone carry a 24/7 powered and Internet connected device in their pockets. The Internet - network that allows globally sending any data between devices. Maybe with full redesign third-party email servers should be made optional.

I believe we should focus less on how to redesign whole service and build more universal layers instead. First, vsending any data to any machine. Second, optionally remotely accessing our data. Third, mail-like format of data.