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 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)?
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.
> 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'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.
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.
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 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)?
> 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?
Is there any reason they shouldn't be the same?
This is the way hey.com operates. It's nice.
[delayed]
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.
> 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'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.
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.