I've wondered a lot about why e-mail isn't used more as a backend for different services. But as far as I can tell, messaging products proliferate because their creators want to create profitable products rather than distributed protocols.
E-mail is a pretty good group of protocols for distributing arbitrary messages between different locations on the Internet. It's easy to imagine how all sorts of messaging and social network products could be implemented as a specialized e-mail client with a good user experience. Their forms might be slightly different than they have now, but they'd serve approximately the same consumer purpose.
For example, you could build a social networking "client" with e-mail as a backend. Status updates, photos, etc. would be distributed to all your contacts via email, and the client would produce a "timeline" based on the data in its mailbox, without ever showing the user the original messages.
But you give up a lot of control that way, and it's harder to monetize. What developers want (and users too, to be honest) is a centralized service that they can control, mine data with, and sell products or show ads. A distributed protocol, while in some ways more powerful (and less dependent on a fallible central authority!), doesn't achieve the real business aims.
Email is decentralized to us. We have the very specific skils, attitudes, and patience required to buy a domain name, rent a VPS or dedicated server and configure SSH public keys, Postfix/Courier, DNS, SPF, DKIM, and keep it up to date and patched, audit it to make sure it stays secure, and detect/respond to intrusions. And even then, unless you are going to roll your own emergency power, multiple redundant HVAC, and fire supression, as well as shell out hundreds of dollars a month for significant upload bandwidth to your house or apartment, your data and encryption keys are still in the physical possession of a corporate datacenter.
Email is most certainly not decentralized to anyone outside the IT world. They can, with extreme difficulty, move between providers, but they are still dependent on a provider.
Email decreases the volume of users that mediocre players can own (Google does email better than anyone else, so it gets a significant share of the market) but users are still going to be owned by someone.
>unless you are going to roll your own emergency power, multiple redundant HVAC, and fire supression, as well as shell out hundreds of dollars a month for significant upload bandwidth to your house or apartment, your data and encryption keys are still in the physical possession of a corporate datacenter.
You don't need significant upload bandwidth for email. Or download bandwidth either. (Unless you're expecting constant DDOS attacks.) Or emergency services. The HVAC might be a good idea.
You could have made your point a lot better by just saying that 99.9% of users will never set up a home server to do email. Which is the truth.
There's a chicken and egg problem to this. If you do what you suggest, you are going to flood the user's inbox and although you will clean it up in your client, the user is also going to have a standard email client that notifies them constantly about your messages.
We need a transitory client that is better than the one we have today, but still is the only email client you use. It would do a better job of categorizing and prioritizing your messages. When the user gets used to this, they might be willing to accepting dropping general purpose email clients all together.
I don't even want to make the user drop general-purpose email clients; I just think that email, as a back-end distributed messaging protocol, is more understood and battle-tested than just about anything a startup is likely to invent.
Two possibilities that occurred to me:
1) Your service just uses email as a backend messaging protocol, and provides a new "user@myservice.com" mailbox to all users. Advantage is that you can put all your logic in the client, and just run a mail server.
2) Better: include an email header along the lines of "Intended-For-Application: MyService", and encourage general-purpose email clients to auto-archive these messages out of the inbox.
But yeah, it's just the kernel of an idea, and there are tons of problems with it.
A. A random selection of end-user's email services have spam filtering that some of your app's messages can't get around. To the end user who never actually sees the emails (because you simply use them as message passing items) this will simply seem like your shoddy service flaking out.
B. An end user's personal email service goes down, which has nothing to do with you but renders your service unusable to them, again as far as they are concerned, your service is simply shoddy and unreliable.
C. In the event that the end user's email service does go down, and they know about it, they are likely to turn to a secondary protocol to get in touch with people, only to find that your service also isn't working because it relies on the same protocol.
Frankly, I can see several problems with option 1 as well. Excessive bandwidth overhead from unnecessary headers, the spam problem inherent to email, all the parsing you'd have to do to extract data from the text body. I'm not really sure what the advantages of using email are if you're just going to be running a single mail server for all users of your service.
>A distributed protocol, while in some ways more powerful (and less dependent on a fallible central authority!), doesn't achieve the real business aims.
Comments
I've wondered a lot about why e-mail isn't used more as a backend for different services. But as far as I can tell, messaging products proliferate because their creators want to create profitable products rather than distributed protocols.
E-mail is a pretty good group of protocols for distributing arbitrary messages between different locations on the Internet. It's easy to imagine how all sorts of messaging and social network products could be implemented as a specialized e-mail client with a good user experience. Their forms might be slightly different than they have now, but they'd serve approximately the same consumer purpose.
For example, you could build a social networking "client" with e-mail as a backend. Status updates, photos, etc. would be distributed to all your contacts via email, and the client would produce a "timeline" based on the data in its mailbox, without ever showing the user the original messages.
But you give up a lot of control that way, and it's harder to monetize. What developers want (and users too, to be honest) is a centralized service that they can control, mine data with, and sell products or show ads. A distributed protocol, while in some ways more powerful (and less dependent on a fallible central authority!), doesn't achieve the real business aims.
Email is decentralized to us. We have the very specific skils, attitudes, and patience required to buy a domain name, rent a VPS or dedicated server and configure SSH public keys, Postfix/Courier, DNS, SPF, DKIM, and keep it up to date and patched, audit it to make sure it stays secure, and detect/respond to intrusions. And even then, unless you are going to roll your own emergency power, multiple redundant HVAC, and fire supression, as well as shell out hundreds of dollars a month for significant upload bandwidth to your house or apartment, your data and encryption keys are still in the physical possession of a corporate datacenter.
Email is most certainly not decentralized to anyone outside the IT world. They can, with extreme difficulty, move between providers, but they are still dependent on a provider.
Email decreases the volume of users that mediocre players can own (Google does email better than anyone else, so it gets a significant share of the market) but users are still going to be owned by someone.
>unless you are going to roll your own emergency power, multiple redundant HVAC, and fire supression, as well as shell out hundreds of dollars a month for significant upload bandwidth to your house or apartment, your data and encryption keys are still in the physical possession of a corporate datacenter.
You don't need significant upload bandwidth for email. Or download bandwidth either. (Unless you're expecting constant DDOS attacks.) Or emergency services. The HVAC might be a good idea.
You could have made your point a lot better by just saying that 99.9% of users will never set up a home server to do email. Which is the truth.
You probably should be expecting consistant DDOS attacks, or at least aggressive scanning.
OP failed to mention setting up DKIM and SPF as well.
True. But residential bandwidth is just one of many reasons why mainstream users aren't going to actually own their own email anytime soon.
"messaging products proliferate because their creators want to create profitable products rather than distributed protocols."
That's a bingo.
There's a chicken and egg problem to this. If you do what you suggest, you are going to flood the user's inbox and although you will clean it up in your client, the user is also going to have a standard email client that notifies them constantly about your messages.
We need a transitory client that is better than the one we have today, but still is the only email client you use. It would do a better job of categorizing and prioritizing your messages. When the user gets used to this, they might be willing to accepting dropping general purpose email clients all together.
I don't even want to make the user drop general-purpose email clients; I just think that email, as a back-end distributed messaging protocol, is more understood and battle-tested than just about anything a startup is likely to invent.
Two possibilities that occurred to me:
1) Your service just uses email as a backend messaging protocol, and provides a new "user@myservice.com" mailbox to all users. Advantage is that you can put all your logic in the client, and just run a mail server.
2) Better: include an email header along the lines of "Intended-For-Application: MyService", and encourage general-purpose email clients to auto-archive these messages out of the inbox.
But yeah, it's just the kernel of an idea, and there are tons of problems with it.
You would almost certainly have to use option 1.
Option 2 includes such problems as:
A. A random selection of end-user's email services have spam filtering that some of your app's messages can't get around. To the end user who never actually sees the emails (because you simply use them as message passing items) this will simply seem like your shoddy service flaking out.
B. An end user's personal email service goes down, which has nothing to do with you but renders your service unusable to them, again as far as they are concerned, your service is simply shoddy and unreliable.
C. In the event that the end user's email service does go down, and they know about it, they are likely to turn to a secondary protocol to get in touch with people, only to find that your service also isn't working because it relies on the same protocol.
Frankly, I can see several problems with option 1 as well. Excessive bandwidth overhead from unnecessary headers, the spam problem inherent to email, all the parsing you'd have to do to extract data from the text body. I'm not really sure what the advantages of using email are if you're just going to be running a single mail server for all users of your service.
Email is a terrible, terrible set of protocols and formats. We should really move to something less horrible.
There are several social network projects built on top of XMPP, though, which is a lot less terrible.
>A distributed protocol, while in some ways more powerful (and less dependent on a fallible central authority!), doesn't achieve the real business aims.
Then don't build one as a business.