Comment by simmons | Hacker News Reader

Comment by simmons | Hacker News Reader

Thanks to the OP for writing this up. I'd love to see mail be rebooted.

A few thoughts:

1. I don't know if HTTPS is the best analogy, since it took 20 years for it to really become widely used (vs. non-secure HTTP). I think a better analogy might be the transition from HTTP/1.1 to HTTP/2 (or HTTP/3?).

2. I don't think we can rely on large providers (e.g. GMail) to quickly adopt a new system and even issue switchover ultimatums. A simpler mail system may not be in their best interest. Aiming for slower, organic growth could be more realistic. Even if a next-generation mail system never becomes dominant, it could still provide value. (Maybe Mastodon/ActivityPub is the analogy here?)

3. In any sort of reboot, I think a modern encryption system (something like Signal protocol?) would be a must.

4. Can we have a system where senders need to hold tokens to authorize them to send a message to a recipient? The whole "anyone on earth should be able to send you an unsolicited message" idea is ultimately the source of the spam problem. Messaging systems that rely on bidirectional agreement have much less of a spam problem. (Obviously this raises a slew of other technical and UX questions...)

I know that making too many changes is a risk. But I think that there is also a risk in making too few changes. (If the value proposition isn't sufficiently bold, this may hurt adoption.)

To your thoughts:

> 1. I don't know if HTTPS is the best analogy...

IMO, the lynchpin to HTTPS accessibility was that we made cutting certificates easy, and most importantly, free. By eschewing the baseline requirement for cutting a certificate to being able to validate that the site on the domain is trusted by virtue of a relationship between the hostname and the certificate requester, and providing an API to automate the renewal process, opting into HTTPS went from "administrative burden that needed a sysadmin to manage" to "service any hosting provider could leverage". LetsEncrypt and the ACME protocol, and Cloudflare before them, did much to radically change the landscape for making HTTPS accessible to everyone. [1] That makes the analogy pretty apt to me, IMO.

2. You make a very valid point here. By virtue of letting SMTP languish so long, bandaiding it as we went, instead of opting for a major refactor of how email works, we made an environment that was rife for consolidation. As a result, it makes sense that we might have to boil the frog to make a change.

3. I'd love to see it, but I'd be interested in learning how key exchange/trust works. I'd be interested to see how you'd envision enabling new senders to send you mail.

4. This feeds back into my comments on 3. With established contacts, this is great, but in a world where, say, you were giving a talk, and wanted to offer folks that listened to your talk a way to contact you afterwards, how would you distribute the token? If someone abuses the permissions, how do you invalidate it? I can't foresee this being an all-or-nothing system, and don't really see a system where creating some sort of one-way or two-way trust between individual senders and recipients is at all feasible.

[1] Let's Encrypt stats: https://letsencrypt.org/stats/

>In any sort of reboot, I think a modern encryption system (something like Signal protocol?) would be a must.

Signal doesn't strike me as a very suitable candidate. It is quite connection oriented and email is not. For example, it requires a online "prekey" server just to do encryption.

We already have two protocols for encrypted email (OpenPGP, S/MIME). I can't see how another incompatible protocol would help. It seems to me that the first problem to address would be the usability of encrypted email, which is quite poor. While we are at it, we should work on the usability of encrypted instant messaging, which isn't that great either, for most of the same reasons.

Reply on news.ycombinator.com