Earlier quoted context omitted.
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 categorizi…
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 y…
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.