An email can contain multiple arbitrary payloads. It's almost like HTTP, except it's asynchronous. We already have the infrastructure to deliver messages from anyone to anyone. Why keep trying to destroy it when we could take advantage of the existing infrastructure instead? I don't see anyone rallying to disrupt HTTP. Why all the obsession with disrupting email?
We could use different Content-Types to embed all sorts of structured information in an email, and standardize the hell out of it. A schedule for an event. An item to go on your TODO list. A link to click for confirmation. If you can express it in JSON, you can attach it to an email. And the resulting messages will be 100% backward compatible with old email clients, just like newer versions of HTTP.
There are endless possibilities for email as long as you don't try to get everyone on your own proprietary platform. Otherwise you will be just another messaging service that has nothing to do with email, and email users will happily ignore you. Don't fall into that pitfall. You need to make your solution an essential part of people's email workflow, rather than trying to steer people toward a different workflow.
The problem is the usual with a federated protocol: adding a feature requires you to extend all the clients, which does not happen. See for example PGP.
The features are completely opt-in. If you don't want to link your email to your schedules or TODO list, you don't need to do anything. The same information should be present in a human-readable format in the body of the email anyway. (YAML might be better than JSON for this purpose.)
Comments
Better email.
An email can contain multiple arbitrary payloads. It's almost like HTTP, except it's asynchronous. We already have the infrastructure to deliver messages from anyone to anyone. Why keep trying to destroy it when we could take advantage of the existing infrastructure instead? I don't see anyone rallying to disrupt HTTP. Why all the obsession with disrupting email?
We could use different Content-Types to embed all sorts of structured information in an email, and standardize the hell out of it. A schedule for an event. An item to go on your TODO list. A link to click for confirmation. If you can express it in JSON, you can attach it to an email. And the resulting messages will be 100% backward compatible with old email clients, just like newer versions of HTTP.
There are endless possibilities for email as long as you don't try to get everyone on your own proprietary platform. Otherwise you will be just another messaging service that has nothing to do with email, and email users will happily ignore you. Don't fall into that pitfall. You need to make your solution an essential part of people's email workflow, rather than trying to steer people toward a different workflow.
The problem is the usual with a federated protocol: adding a feature requires you to extend all the clients, which does not happen. See for example PGP.
The features are completely opt-in. If you don't want to link your email to your schedules or TODO list, you don't need to do anything. The same information should be present in a human-readable format in the body of the email anyway. (YAML might be better than JSON for this purpose.)