4 ms·
Ask HN: If there is a replacement for email, what should be the requirements?
HN,
Email is one of the most revolutionary internet technologies. However, both in terms of feature and security, a lot could be done today if it was designed from the ground up instead of pieced together over 30 years.
If you will indulge me and pretend for a moment that I somehow have the power to magically make an email replacement happen and I am asking you to define your requirements, both as technologists and users, what would those requirements be?
Beyond delivering a text message from sender A to recipient B, what are your specific requirements?
Keep in mind, it has to be a passive and somewhat reliable messaging system (i.e.: Not an IRC replacement).
- logicalmonster 5y agoI think Apples data detectors features for email are pretty cool. It does some minor things like recognize dates in emails or certain things like recognizing phone numbers. I think some kind of advanced system that does a much better job of letting you sort through emails’ content or taking action with this data in some structured format would be useful. If I’m trying to remember the name of somebody I talked to years ago, I should have an option to see the first names of everybody who I ever communicated with. If I’m trying to find an old receipt, I shouldn’t have to search through receipts for half an hour to find out that the word I should have looked for is invoice instead: it should be smart enough to sort through all similar data. If an email mentions a location, it should automatically be marked in a map. Etc. I don’t use it myself but hey.com has some interesting and sensible quality of life functions. https://www.hey.com/features/ https://www.hey.com/features/
- _8j50 5y agoThe problem with that is it breaks end to end encryption. Would you feel ok with having a database on each mail client that caches all text-only content for sorting/searching locally? Let's say a 1GB disk-space allocation for this feature alone ?
- logicalmonster 5y ago> The problem with that is it breaks end to end encryption. Depending on how it's implemented, I'm sure there are security issues to consider, but I'm not following how this kind of feature would necessarily cause a breaking encryption problem. If you can add some thoughts on how this breaks encryption, that might be interesting. > Would you feel ok with having a database on each mail client that caches all text-only content for sorting/searching locally? Let's say a 1GB disk-space allocation for this feature alone ? Given that modern HDs in most professional machines are in the 1TB and way up range, I'd say that anybody who wants to use the full power of email would probably consider that tradeoff worthwhile.
- jqpabc123 5y ago...what would those requirements be? Privacy. If someone sends me spam, I want the ability to easily reject any further mail from either the specific address or the entire domain. It would be nice if this applied universally, on every device. Basically, a user controlled spam filter at the server. Also, a standardized form of encryption --- to be easily invoked as needed for sensitive data. 98 percent of email doesn't need encryption --- but that last 2 percent does. Basically, privacy invasion via email needs to be eliminated.
- dane-pgp 5y ago> Basically, a user controlled spam filter at the server. This seems reasonable, and even achievable. It's probably already possible to reject emails that don't have SPF and DKIM (to prevent spoofing), so we just need a way for a sender to determine whether the recipient has whitelisted them. If they haven't been whitelisted, they should be limited to sending a short (100 character?) plaintext introduction, with no hyperlinks. > to be invoked as needed for sensitive data. 98 percent of email doesn't need encryption --- but that last 2 percent does. I disagree slightly. The 2 percent that does need encryption also requires that the other 98 percent be encrypted too, so that: * attackers don't know which messages to target, * the pattern of encrypted vs. unencrypted emails doesn't reveal information in itself, and * the user doesn't have the mental overhead (and error potential) of having to decide which emails are worthy of encryption (a task which requires them being able to reliably predict the future). Much of the logic for encrypting the whole of the web (as opposed to just "important" pages) applies to the need to secure (almost) all email too. The main difference, I think, is that the web is a pull architecture while email is push, meaning that spam and identity works differently, and server-side filtering can't work with E2E encrypted email.
- jqpabc123 5y agoOnly the body and attachments need be encrypted and the decision to encrypt can be applied on a case by case basis with little mental overhead --- is the data sensitive or not? Revealing my email as a potential target is a minor trade off I would accept for ease of use. It should not be a big deal if the encryption is solid. The cost to try and break the encryption is enough to discourage most attackers. How many email "man-in-the-middle" privacy breeches are you aware of? The ones I am aware of usually happen at a service provider endpoint --- like Google data mining your email. I doubt even Google is motivated enough to absorb the cost of breaking email encryption. There would also be legal ramifications if they (or any other provider) did.
- dane-pgp 5y agoRequirement 1: It should be backwards compatible with existing email systems. As examples, consider Delta Chat and the Autocrypt specification it's built on. https://delta.chat/en/ https://delta.chat/en/ https://autocrypt.org/ https://autocrypt.org/
- _8j50 5y agoWhat do you think of a protocol that is not compatible with email at all but at the transport level can relay SMTP to SMTP servers intact? MUA's (clients) would either add support to the new protocol or dedicated clients would be used?
- dane-pgp 5y agoI'm not sure what would be gained by that compatibility break. If it was something like the "upgrade" from plaintext email to HTML email, where both could be supported in the same message, I think that could be a reasonable approach, but I can't imagine anything that could be improved at that level.
- yuppie_scum 5y agoEnd to end Encrypted Private (figure a way to prevent pixel tracking, etc) Trusted (figure out how to prevent unsolicited spam - opt-in “friends only” model?) Overcome file size and type sending/sharing roadblocks Overcome embedded malware issues Treat groups the same as individuals at the delivery/trust level Instant delivery Easy import/export/transfer/backup/cleanup First class integration with calendaring
- _8j50 5y ago> Treat groups the same as individuals at the delivery/trust level why? If I may ask. Does that not violate end-to-end encryption? Or, I think what you meant is from a delivery perspective, not trust? As in, if you accept messages from a sender, the whole group's messages are also delivered going forward? Or do you mean for authentication?
- d--b 5y agoPay to send (maybe?)
- _8j50 5y agoInteresting. Maybe a reputation system where you pay a significant escrow that will be lost with spam reputation? But it must be optionally set by recipients, otherwise no one will use it.
- d--b 5y agoThat sounds too complex to me. Pay to send is simple, definitely reduces spam, means that you can have an ad/tracker-free experience, reduce the amount of “chat-by-email” threads. Maybe nobody wants that though.
- _8j50 5y agoProblem is, anytime you say "pay" you lose at least 90% of users for a service they can use for free. In other words, everyone wants to force others to pay but they themselves don't want to pay to send messages to others. Plus, $0.99 to you could mean an entire day's wages in some countries.
- dane-pgp 5y agoI think a reasonable compromise is to make the trust/escrow work at the level of domains, rather than users. That way the providers operating an email service have an incentive to stop spammers abusing their accounts. To get providers to agree to this system, we could say that all domains registered before 2022 are grandfathered in, and only newly registered domains (with an MX record) have to put money into escrow. Domain owners already have to spend money, and hire technically knowledgeable people, so it's not like millions of ordinary email users will have to suddenly start entering their credit card details in order to send messages. The only problem is how to decide who is allowed to make a claim against the escrow. If I accuse Gmail of sending me spam, can I take Google's money? To avoid some bad incentives, the money in escrow should go to charity rather than the claimant, but that still allows attackers to make false claims and prevent millions of Gmail users being able to send emails. A naive voting system would break down because of Sybil attacks, so we probably end up having to trust some cabal of big email providers, who maybe become anchor points in a trust graph, or they employ people to review instances of DKIM-signed emails that claimants report to them as being spam. This cabal could perhaps be made slightly more democratic by allowing UN/ITU members to vote on organisations they trust with this power.
- collinthecorgi 5y agoI think most importantly would be privacy, then the features of sending files and maybe spam blocking is highly recommended.