4 ms·
This is a low effort proposal and the author seems blissfully unaware of the long and varied history of proposed alternatives to email. Alternate proposals hav
by yholio 5y ago
This is a low effort proposal and the author seems blissfully unaware of the long and varied history of proposed alternatives to email.
Alternate proposals have failed and will always fail due to the ingrained nature of email. Nobody is going to use a new email system that allows communication to zero or very few recipients, and the system can never bootstrap. And that's that, no alternative to email will succeed if its only claim to fame is that is "email done right", that's a much too weak feature to break SMTP's decades of first mover advantage.
To break this clinch, you need to either:
1. deliver a communication product that has much superior features, and incidentally does mail very very well; people will start to use it for the other features, play with its email subset functionally, and in many, many, many years, the email will wither and die. Up to now, despite many claims to the contrary, no one managed to do that. The average lifespan of instant messaging protocols is around two decades (anyone on ICQ or Yahoo anymore?), while email is going strong into its 50s.
2. backport those advanced features into SMTP so that they are interoperable with the existing infrastructure AND, at the same time, deliver a tangible benefit to the people using those features, AND deliver those benefits today, not into some distant future where most people start to use it (PGP, where are you). This is a very hard set of conditions and very few technologies have managed to fulfill them, as a consequence email has evolved very slowly.
So if you don't want to have the old "canned letter response making fun of your antispam system" rubbed in your face, you better start working on number 1. or number 2.
- WalterBright 5y agoFeatures can be added as long as they are backwards compatible, by adding another tag for it. For example, the tag could be your public encryption key. Then, your email app, whenever it receives a public key from a sender, the app now knows their public key and can send them encrypted messages. Those without the public key, get the plaintext email. This can all happen completely without any action on the part of the user. Over time, it will gradually become ubiquitous, like https did.
- akerl_ 5y agoAttempting to bolt public key onto encryption is one of the many things that’s already been attempted multiple times. We can see from those attempts that it’s not worked, for a variety of reasons.
- WalterBright 5y agoWhy does the variant I suggest not work?
- akerl_ 5y agoHow do I trust the public key I get via a tag in an email from somebody whose public key I don’t already have? How does the person rotate keys if we only talk occasionally? Or, if we’re looking for a bigger, overall flaw: e-mail is fundamentally fire-and-forget via SMTP, so there isn’t a way to use the users pubkey to creat a per-message session key, and reusing a persistent key for encrypting data is a massive pitfall.
- yholio 5y agoWell, you could use opportunistic encryption: once the first (plain text) email is sent, it establishes an identity for the sender and from that point forward the exchange is encrypted. It's, of course, not authenticated, and anyone can MITM the exchange, but it kills dead all passive (eavesdrop only) attacks. Also it makes a past compromise easy to detect, without reusing any session key. A more direct solution would be to leverage the DNSSec infrastructure and publish, say, an "MXK record" (MX Keyserver) for each compliant server. If such a record is present, then the mail domain vouches that you can find at that specific address a VKS keyserver that can resolve individual public keys for all its mailboxes. The whole exchange is encrypted and hierarchically authenticated, from the DNSSec root down to the individual mailbox, so it requires the cooperation/compromise of the specific level to break. This way, when you type "user@host" in your email client's To: bar, the client can immediately resolve the public key of the recipient, and encrypt and sign the message accordingly with a high confidence that the encryption will be transparent and ensure the security of the exchange.
- pelasaco 5y agoTo that i can just add: Text is cheap, show me your code. Any proposal is great, but if it doesn't turn itself in code, it is meaningless.
- jfrunyon 5y agoThat's like saying that no one's going to use a new social media, or IM, or chat, or ... If it's happened for all of those things (and some of them going from a more useful platform to less useful), it can happen for email.
- yholio 5y agoSocial media are not primarily communication tools, they are content consumption and aggregation platforms. So if a new platform offers good content (say, pretty pictures - Instagram or funny videos -TikTok), they can build a critical mass of users that will attract more content providers etcetera. For communication platforms the network effects are paramount, no one will move to Mail2 just to send plain old emails that almost no one can receive. If you can build a new email with much more attractive features, then you can disrupt email, which is exactly what I said.
- jfrunyon 5y ago[citation needed]
- smeej 5y agoThe network effect was what was wrong with Google Wave, which was better than email in practically every way. If it had been possible to send a Wave to an email address (some sort of embedding?) and receive email to your Wave address, I think it would have succeeded in replacing email. Instead, for reasons I'll never understand, Google tried to replicate the limited number of invitations system that had worked for Gmail, despite the fact that only having a limited number of people you could communicate with made the product effectively useless. It worked for Gmail because you could send email from Gmail to anywhere, and receive it from anywhere! Missing that Wave was fundamentally different to me is one of the worst tech marketing failures I've seen.
- Jtsummers 5y agoOnly one of my Wave invites went out, and to a person who I saw nearly every day but didn't communicate with electronically. I invited my sister, classmates, and some friends who I regularly communicated and collaborated with electronically, none of them ever got in before it was shutdown. It was very frustrating because for one person it had limited utility (may as well just use Google Docs or Dropbox), and I had no community to interact with within Wave.
- technobabbler 5y ago> Missing that Wave was fundamentally different to me is one of the worst tech marketing failures I've seen. Should we tell smeej about Google's fifty OTHER failed IM marketing attempts?
- networkimprov 5y agoThe success of a wide variety of messaging and discussion apps demonstrates that the network effects of email are not necessarily a high barrier. What these products have lacked, which email has, is an open protocol. (XMPP had early success, but never addressed the main use cases of email, and has major design flaws.) A handful of credible alternative protocols are now in development: DIME - https://en.wikipedia.org/wiki/Dark_Mail_Alliance https://en.wikipedia.org/wiki/Dark_Mail_Alliance Math Mesh - https://mathmesh.com https://mathmesh.com TMTP - https://mnmnotmail.org https://mnmnotmail.org (my work) Email was designed in the 1970s & 80s for an Internet whose population and topology have dramatically changed since. We no longer need a messaging system that allows anyone, claiming any identity (i.e. "real name"), to send you any content, without limits. Federation was necessary for the topology of the early Internet, but today it is a drawback -- making email by far the most effective method to initiate cyberattacks.