Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Email is async, distributed, offline first, nobody controls the complete platform.

What is needed to fix email is to have structured messages, which can better be automated. Either on the MUA or MDA. But exactly this standardization of message structures is something that won't happen anymore... It's not the '90s anymore



> What is needed to fix email is to have structured messages [...] something that won't happen

You're right in a way that this "won't happen", because Google Wave already tried it, but I think what's really needed is a killer client that supports unstructured email and gets into a position whereby they can add structure (and get adoption thereof).

Take for example Fastmail's JMAP. They started by supporting IMAP, and they'll continue to support it for a long time. But, despite Fastmail not being the biggest provider in the world, we're still seeing adoption of JMAP by others.

I could see the same happening with a really well-made open client. It would have to be "modern" (a GUI that handles & sends HTML mail well), and it would have to have good UX to deal with the awful idiosyncrasies of closed providers (e.g. Gmail's broken IMAP, Google Accounts' non-standard auth measures, etc.). Once those work well, one could create a new Content-Type for structured metadata and start sending it as part of multipart mails: most clients would ignore it at first and render plaintext.

This might be less efficient (bandwidth-wise) than traditional email at first, but could improve on that with adoption.


"Fix"

Fix what again?


One "fix" could be an opt-in key, which you can revoke. A new sender will enter your inbox, and can be more easily identified as spam. You can send an opt-in key, which skips the filters, or at least puts the message in your inbox.

If you notice unwanted emails (maybe from another sender), you'll know: - the sender is misusing the key - if the key had been compromised / sold / stolen, the new sender is a misbehaving party (maybe can't use the key if it's linked to the sender address or domain)

You can then revoke the key, and block the sender. The MTAs can use this information to blacklist abusers.

When the key is revoked, the sender will need to re-request a new one.

The 'solution' here is that the key is now something valuable and linked to their operations, so they won't resell this. It also becomes apparent when keys have been stolen. It would also be possible to add automatic key rotation (key update when sending an email).


I just put these "keys" into the local part of the email address, no additional protocol "fixes" needed. I can make up keys on the fly then add the filter for them later whenever I get home. It is very obvious when a sender has sold or shared an address and I blackhole accordingly (this is actually extremely rare).


hey.com supports exactly what described.


hey.com doesn't support much else of email


Fix the constant desire of everyone to re-invent/move away from & generally denounce email as a platform.

If you think email is perfect as it is, you're living in a bubble and are ignoring the pains of countless people. You may have an email setup that works perfectly for your needs, but if it was easy for everyone to have the same, no-one would be trying to re-invent it.


Oh, and lets be clear:

I do not believe for a minute all this wanting to replace email is about the pain of countless people. There is pain, no doubt. I have some myself.

It is all about massive adoption being equated to massive dollars. That tends to amplify these things.


Right. When a company says "let's fix email with a better solution", it is very clear what they really mean is "we want to lock people into our proprietary channel and profit". What's good for the user long term is not a factor to them.


> I do not believe for a minute all this wanting to replace email is about the pain of countless people. There is pain, no doubt. I have some myself.

To clarify my point: I think people try to replace email because they're frustrated with email and believe it can't meet their needs. Personally, I believe email could meet some of their needs were it improved to alleviate some of their frustrations. And I wish some people would direct their efforts toward improving email rather than trying to replace it.

Then again, maybe I should be taking my own advice.


And I question needs vs wants.

Many people are all about how they want to work. They may or may not be about how others work, working together, or willing to adapt how they work.

And we all have reasons, no worries, no judgement.

That said, I have seen many wants framed as needs. Have done that myself. Have also adapted how I work to see those things evaporate away too.

What is worth what?

Sometimes working differently is lower risk, friction for higher value than attempting to work in a specific way can be.

Cheers!


There is making something new, that reinvention, and there is making better use of what is there now.

What you want is not email.

So make what you want, and if it really does reduce the pain of countless people, it will see broad use, right?

And if it does not?

Send me an email, we can talk about it.

Maybe what you want to do can ride in an email?

Great, do that. And again, if countless people feel better, they can run clients that help them feel better.


> What you want is not email.

What I want is email, with the pains ironed out. I do not want anything fundamentally new. I just want to use what I'm currently using, and have it work as it currently works, minus current frustrations.

These frustrations vary from person-to-person (mine are numerous, some I'd be happy to live with, but others genuinely bother me daily), so fixing enough of them to appease a large portion of email users is no small task, but I think email is a good enough foundation that doing so is worth pursing.

I don't see much value in telling everyone their complaints re: email are invalid and they should accept it as is without improvements.

> So make what you want

That's a fair point, and maybe I should. It would certainly be better than posting aimlessly about it in internet comments. As mentioned above though, it's no small task.


I did not tell you those things. You inferred them.

And that is OK, no worries.

Do make that thing. I will look at it with interest like any new thing.


The wave of emails which are difficult to process automatically, and the fact that you can email anybody (which also is the great thing about it)

There are some standards for invoicing.

Another great application is Civilization over SMTP.


The opt-in key I use is a unique address for each vendor / organization. If their email database is "leaked" or otherwise sold out, I can delete the alias and they are dead to me. This makes email rules much easier for me.


I refuse to believe that most of our "unique" emails addresses and GMail suffixed email addresses are not already being collected and matched across the vast networks of fingerprinting data that companies can purchase.


I'm sure google do this, but I won't use gmail. I have some of my domains on fastmail for family members to use and the rest of them on a VM that I simply run postfix and read emails as text files. My own mail server supports infinite number of aliases and there is no tracking on my own mail server since every email is text and the server discards MDN's. If I need to read html, I pipe the email to a parsemime perl script from 2001.

Fastmail makes some attempt at blocking tracking, not perfect, depends on user preference and default is to allow remote images. [1] Another advantage to this method is that if I get annoyed with Fastmail, I can update DNS and they are out of the picture.

[1] - https://www.fastmail.help/hc/en-us/articles/1500000278102-Bl...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: