Any way to improve email as a standard in a backwards compatible manner? | Hacker News Reader

Any way to improve email as a standard in a backwards compatible manner?

2 pointsmofosyne4 comments

I'm wondering if there is a way to maybe augment existing email standard to include metadata for at least these purposes. But happy to hear your other wishlist as well.

- Add hashtag? (e.g. '#invoice') This would be very handy for cooperative senders to let receivers better auto sort each emails. (And if we could agree to common tags... it be easier to sort emails across companies)

- Add recommended short response? What about a form? (E.g. "Yes/No" with override if user wants to elaborate). This is similar to how telegram bots works which is very convenient.

- What about a form? (E.g. Shopping list selection)

What would it take to make it happen? Or are we forced to wait for Google gmail or Microsoft office mail to decide what will happen? (Though Microsoft priority flag is pretty nice)

Or should we just migrate to activitypub?

You can add another format to the multipart/alternative container. Just like html emails often have a text fallback. It requires picking a Content-Type name (application/vnd.<your_name>.something) but then you can attach any additional metadata you want: https://kevinjmcmahon.net/articles/html-and-plain-text-multi...

The hard bit is getting email clients to use your information.

> Add recommended short response?

That's the email client's job. While it's nice to not have vendor lock-in, many popular email clients can do this by default (Gmail, Outlook, etc.)

> Or should we just migrate to activitypub?

Email is already ActivityPub in a way. It can talk to many email providers, and it isn't locked into a specific provider.

You could use the "Keywords:" header (sometimes used in Usenet) if you want something like tags.

For suggested short responses, perhaps make up a new header such as "Responses:" with a comma-separated list of short responses.

This would make it fully compatible and can work fine with plain text and will be compatible with all existing email clients and servers. It is also not that complicated to implement, and some users may see the headers already.

Support "private" addresses with a maintained list of approved sender addresses. Any sender not on the list either goes to junk or gets rejected.

This could be implemented on either the client or the server with appropriate maintenance functions.

Reply on news.ycombinator.com