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.
amelius 6 hours ago [-]
> 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)?
TheOtherHobbes 2 hours ago [-]
The unknown request will be buried in spam - a problem we have already, but worse.
And I do not want an infinite thread conversation. I want to be able to split off - and perhaps archive and export - different conversations by topic.
I recently had to some legal things, which included forwarding copies of a certain conversation to a lawyer. This turns out to be unreasonably difficult because email clients quote previous conversations. You want a clean thread of comment and reply about a specific topic. You don't get that.
You do get it on chat services, but there's no option there to create sub-conversations.
If I was redesigning email I would think long and hard about different use cases and workflows and start with an RFC. Protocols are far downstream of that.
tcfhgj 2 hours ago [-]
> You do get it on chat services, but there's no option there to create sub-conversations.
It's called threads - even Matrix has these
aboardRat4 3 hours ago [-]
>Question: can this e-mail specification/implementation also replace direct-messaging protocols (like WhatsApp)?
Deltachat
MrGilbert 4 hours ago [-]
> I like this.
Honestly, I'd want this as a default. I wonder if a mailserver can be configure like this. Doesn't sound too hard, does it?
Greylisting is not perfect, not even close, but it allows servers to reject huge amounts of garbage mail while allowing new mail from unexpected parties without user intervention.
dizhn 3 hours ago [-]
It is similar but not the same thing. It does not have anything to do with the email being legit (non spam) or not. It only catches emails that do not do what they supposed to do when they are deferred for a little bit. They are supposed to try again later. (A super nice feature of email which protects you from losing all incoming emails when your server is down for a short time). The reasoning here is hopefully a spam script or software will not implement the standard properly or will skip apparently broken destinations.
What parent wants is also possible and I remember people doing it as far back as the early 2000s. You would basically manually whitelist an email or have them bypass the list (once or always) with something like a key word or token sort of like a captcha which can be shared off band.
thesuitonym 2 hours ago [-]
It's definitely possible, a few companies do it, and let me tell you: People hate it.
PaulRobinson 40 minutes ago [-]
"We" tried this in the late 1990s. I remember writing an exim config to do this a couple of ways back in my ISP times:
1. "The recipient will not get this message until you authenticate yourself as a legitimate sender at this URL [...]" - resulted in people never getting mail from no-reply addresses they cared about (banks, e-com, etc.)
2. "This sender has sent you an email, with this subject and this first paragraph. Click here to whitelist, here to blacklist" - created a lot of churn on first setup that users didn't like as a UX
Baking it into the protocol - even now in SMTP and IMAP land - is doable, but would be resisted by email providers who, for example, make their money selling data to marketing agencies. Like, you know, Google, Microsoft, Yahoo...
I've seen other approaches proposed - even at IETF level - over the years, including digital postage stamps (sender pays to send email, your server gets paid, and may reject non-stamped/paying email), but it's the usual network effect: until it becomes widely supported it won't "stick". The stuff that has been adopted has basically been stuff that Google likes, period.
fny 6 hours ago [-]
Is there any reason they shouldn't be the same?
xd1936 5 hours ago [-]
This is the way hey.com operates. It's nice.
ccamrobertson 4 hours ago [-]
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.
thesuitonym 3 hours ago [-]
> Let's design the successor to email on top of HTTP
You can stop there, I've heard enough. Not everything is hypertext.
beej71 2 hours ago [-]
And HTTP transports many, many more things than hypertext. It seems like a sensible choice for this use case in terms of capabilities.
jjice 2 hours ago [-]
From the first paragraph:
>The goal is not to replace the current mail system, heaven forbid!, but to learn, have fun and discover current technologies to swap out every element: sending, receiving, gateway, keys, and so on.
It's all for fun.
andros 3 hours ago [-]
Usually, informed people only read the headline.
AKSF_Ackermann 4 hours ago [-]
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.
wuschel 5 hours ago [-]
> 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.
philipwhiuk 2 hours ago [-]
Yeah the 'Requests' folder just becomes the new Inbox folder.
Email clients already highlight/filter people in your contacts
Multicomp 1 hours ago [-]
We could add a friend-of-friend for 1 degree of separation (Alice gets an email from Bob, she doesn't know Bob, so it would go into her Requests folder. But Charlie knows Bob and has said 'yes this guy is legit' and Alice has configured her email to trust Charlie's email recommendations up to 2 degrees of separation, so it goes into the inbox with an explanation that it was allowed by Charlie's trust of Bob).
And poof, we've poorly remembered Web of Trust from 20 years ago!
Overall I do love the idea of HTMP and if we could get it to easily fall back to standard old bad email, I think it could start as a niche and then upgrade towards HTMP over time as more clients adopted support for it.
aboardRat4 3 hours ago [-]
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?
andros 3 hours ago [-]
GUIs cannot be built either before or during the specification of a protocol. In fact, this is the part that should have the least weight. There are important steps, such as system auditing or making design decisions (like certificate rotation), that are not addressed. However, the goal is not to replace SMTP/IMAP, but rather to show how modern tools, when properly assembled, can replace older protocols with serious design flaws.
JMAP is flexible, mature, and easy to connect with current technologies. It's a better option.
marssaxman 2 hours ago [-]
> At the moment email's gui is horrible on all platforms without exception.
This is obviously a matter of opinion. Of course there are endless different email GUIs, on all the platforms; if you don't like one, there are many alternatives.
I cannot imagine that a "decent GUI" by modern web-development standards could be anything I'd prefer to what already exists. Email works and generally doesn't let designer ego get in the way.
andros 3 hours ago [-]
Why do you find the panel experience so bad?
dewey 2 hours ago [-]
> At the moment email's gui is horrible on all platforms without exception.
How can you say that when it's one of the benefits of email that it's an open protocol and there's thousands of different apps built on top of it. Terminal UIs, web interfaces, chat interfaces etc. - that should be one of the cases where there's a GUI for anyone.
zdw 55 minutes ago [-]
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.
jfb 2 hours ago [-]
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.
syhol 5 hours ago [-]
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.
4 hours ago [-]
philipwhiuk 2 hours ago [-]
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'?
rzerowan 2 hours ago [-]
Id think its for enduser flexibility and convenience. Its more involved to alter DNS records vs just adding a text line to a webpage and hitting that default endpoint as standard.
Same way LetsEncrypt allows the easiest setup with the .wellknown endpoint , where a user may not have DNS access beyond the initial A record setup.
endre 4 hours ago [-]
still better than CoI
gostsamo 4 hours ago [-]
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.
andros 3 hours ago [-]
I'm sorry to hear about your bad experience. I've hidden the counter for screen readers. Please try again when you're ready.
forty 1 hours ago [-]
Anecdotally, I don't use a screen reader and also couldn't care less on the visitors on the site. I doubt anyone but you is interested in this, and probably this number is slightly lower just because of that popup
gostsamo 2 hours ago [-]
Thanks for the change.
jeffbee 2 hours ago [-]
The combination of "I have an idea for changing one of the fundamental experiences of modern life" and "my website is obnoxious and hostile" didn't really work for me.
andros 40 minutes ago [-]
The entire website is accessible; I dedicated ample time to it. This was a minor oversight, but I wouldn't call it hostility.
gostsamo 2 hours ago [-]
Mistakes happen.
Rendered at 16:48:33 GMT+0000 (Coordinated Universal Time) with Vercel.
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.
I like this.
Question: can this e-mail specification/implementation also replace direct-messaging protocols (like WhatsApp)?
And I do not want an infinite thread conversation. I want to be able to split off - and perhaps archive and export - different conversations by topic.
I recently had to some legal things, which included forwarding copies of a certain conversation to a lawyer. This turns out to be unreasonably difficult because email clients quote previous conversations. You want a clean thread of comment and reply about a specific topic. You don't get that.
You do get it on chat services, but there's no option there to create sub-conversations.
If I was redesigning email I would think long and hard about different use cases and workflows and start with an RFC. Protocols are far downstream of that.
It's called threads - even Matrix has these
Deltachat
Honestly, I'd want this as a default. I wonder if a mailserver can be configure like this. Doesn't sound too hard, does it?
Greylisting is not perfect, not even close, but it allows servers to reject huge amounts of garbage mail while allowing new mail from unexpected parties without user intervention.
What parent wants is also possible and I remember people doing it as far back as the early 2000s. You would basically manually whitelist an email or have them bypass the list (once or always) with something like a key word or token sort of like a captcha which can be shared off band.
1. "The recipient will not get this message until you authenticate yourself as a legitimate sender at this URL [...]" - resulted in people never getting mail from no-reply addresses they cared about (banks, e-com, etc.)
2. "This sender has sent you an email, with this subject and this first paragraph. Click here to whitelist, here to blacklist" - created a lot of churn on first setup that users didn't like as a UX
Baking it into the protocol - even now in SMTP and IMAP land - is doable, but would be resisted by email providers who, for example, make their money selling data to marketing agencies. Like, you know, Google, Microsoft, Yahoo...
I've seen other approaches proposed - even at IETF level - over the years, including digital postage stamps (sender pays to send email, your server gets paid, and may reject non-stamped/paying email), but it's the usual network effect: until it becomes widely supported it won't "stick". The stuff that has been adopted has basically been stuff that Google likes, period.
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.
You can stop there, I've heard enough. Not everything is hypertext.
>The goal is not to replace the current mail system, heaven forbid!, but to learn, have fun and discover current technologies to swap out every element: sending, receiving, gateway, keys, and so on.
It's all for fun.
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.
Email clients already highlight/filter people in your contacts
And poof, we've poorly remembered Web of Trust from 20 years ago!
Overall I do love the idea of HTMP and if we could get it to easily fall back to standard old bad email, I think it could start as a niche and then upgrade towards HTMP over time as more clients adopted support for it.
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?
This is obviously a matter of opinion. Of course there are endless different email GUIs, on all the platforms; if you don't like one, there are many alternatives.
I cannot imagine that a "decent GUI" by modern web-development standards could be anything I'd prefer to what already exists. Email works and generally doesn't let designer ego get in the way.
How can you say that when it's one of the benefits of email that it's an open protocol and there's thousands of different apps built on top of it. Terminal UIs, web interfaces, chat interfaces etc. - that should be one of the cases where there's a GUI for anyone.
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 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.
* 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'?
If you have a website, please, don't subject your visitors to something like that.