The problem with replacing email is the fact that, unless you're using the standard email protocols, it's not really email at all. What needs to be done is to write a wrapper around the normal email protocols, and allow integration and interoperability with vanilla email that way. Then, you could write a new protocol if you wished, as long as the old ones kept working. If you want to replace email, you actually need to replace it.<p>I don't know if that's what you were already thinking, but thinking that they can make the world move to another protocol all of a sudden is a problem I see a lot of "reinvent email" guys having. That and building it so it only works with specific providers (usually just gmail) are big problems. (I use Hotmail, now Outlook.com, for my email, which is @ my own domain).<p>So, I think this could work, and I'd be interested in helping, but only if
- It works on classic email protocols
- It supports arbitrary providers (this goes along with the first point).<p>My suggestions as to features:
- I really like the idea that alokhar mentioned of the unnecessariness of attaching a document. You could sort documents in different ways (types, who they're from) and list them along with email (which would be toggleable, for obvious reasons). If you need to send them, you send them with a stub email with some sort of markup in it that lets this service ignore the actual email, but is human-readable so it works with vanilla email.
- An integrated inbox would be really nice - this would work well with the calendar/todo list integration. You could have some sort of human-readable, human-writeable metadata that would allow for various functions (setting a due date, etc).
- Any email sent to an address by that address could be treated as a note - this would include todo-list entries (mentioned above), as well as just text notes. You could even sync these with external services (such as Evernote), which would be pretty cool.
- The first image in an email could be used as its thumbnail in some views (or be overridable by the attributes described below)<p>These ideas hinge a bit on the idea of "Markdown for metadata" - some sort of obvious, flexible way to include metadata that, when read by a human, just looks like what you might write anyway. For example,<p><pre><code> due: may 5
due: tomorrow
due: 2012-06-21
task: development
email type: attachment
</code></pre>
This last one could be used for something like the stub emails I mentioned earlier, where a dumb email client would just ignore this and display the text, while a smart email client would hide the email and just add the atttachments to the inbox. You could include some explanatory text ("This is an attachment from johndoe@example.com"), but if this attribute was set to attachment, then it would be ignored by the smart email client. You would probably include a way to see these hidden emails anyway, to mitigate accidental invocation.<p>You <i>could</i> use a similar attribute for todo and calendar entries, but these could be inferred from other attributes in most cases.<p>In order to be as flexible as possible, you'd want to support many different aliases and formats (so I could, for example, write "date" or "when" instead of "due", and use any of the above formats).<p>These are just examples (the task would probably just be the email title, not an attribute - if it was an attribute, it would at least default to the email title).<p>I like the paradigm of having one line per attribute, with<p><pre><code> <attribute> : <value>
</code></pre>
Attribute and value could be parsed on a case-by-case basis - see the several different date formats I used above.<p>You would use this parsed metadata to implement things like to-do lists, calendars, etc, and it would look like something you might type anyway.<p>Sorry, I've rambled a bit. What do you guys think?