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).
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).
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)
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,
due: may 5
email type: attachment
You could use a similar attribute for todo and calendar entries, but these could be inferred from other attributes in most cases.
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).
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).
I like the paradigm of having one line per attribute, with
<attribute> : <value>
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.
Sorry, I've rambled a bit. What do you guys think?