Comments
Hacker News
> Let's design the successor to email on top of HTTP
You can stop there, I've heard enough. Not everything is hypertext.
by thesuitonym
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.
> 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.
by wuschel
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.
by jerf
The fact nobody reinvented e-mail on top of a different set of standards is a good indication that the current stack is not as broken as some people would like to think.
It reminds me of a previous life, at a previous time, when everybody reinvented the content management system based on slightly different approaches, because they thought existing CMSs were too big. It starts with serving pages, then you want multiple templates, then you want accessibility, then you want to authenticate with LDAP, then you want to use the LDAP groups as your groups, and then you need to tie groups to roles, because groups mean one thing to the org, and roles mean another just to the CMS, then you realize a relational database isn't that good a match, then you realize it would be convenient to attach some logic, and a document database is no longer a great idea, then you need multiple datastores for content, then you need new workflows on top, then...
The devil is in the corner cases. They have been solved in different ways, by different parties, for decades, not always documented ("because it was just a simple thing, that once, and we fixed it"). Unless you've been there, you are doomed to make the same mistakes, and nobody was everywhere to avoid all mistakes.
Why not dedicate an effort to migrate all the COBOL code currently running almost every banking transaction? That should be easy ;-)
by rbanffy
> 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)?
by amelius
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.
by 8organicbits
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>
by teddyh
Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- > Let's design the successor to email on top of HTTP
You can stop there, I've heard enough. Not everything is hypertext.
by thesuitonym - 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.
- > 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.
by wuschel - 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.
by jerf - The fact nobody reinvented e-mail on top of a different set of standards is a good indication that the current stack is not as broken as some people would like to think.
It reminds me of a previous life, at a previous time, when everybody reinvented the content management system based on slightly different approaches, because they thought existing CMSs were too big. It starts with serving pages, then you want multiple templates, then you want accessibility, then you want to authenticate with LDAP, then you want to use the LDAP groups as your groups, and then you need to tie groups to roles, because groups mean one thing to the org, and roles mean another just to the CMS, then you realize a relational database isn't that good a match, then you realize it would be convenient to attach some logic, and a document database is no longer a great idea, then you need multiple datastores for content, then you need new workflows on top, then...
The devil is in the corner cases. They have been solved in different ways, by different parties, for decades, not always documented ("because it was just a simple thing, that once, and we fixed it"). Unless you've been there, you are doomed to make the same mistakes, and nobody was everywhere to avoid all mistakes.
Why not dedicate an effort to migrate all the COBOL code currently running almost every banking transaction? That should be easy ;-)
by rbanffy - > 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)?
by amelius - 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.
by 8organicbits - 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>by teddyh