I just don't get this constant fascination of being the one who changes email. This constant race to invent a solution to a problem that doesn't exist. Email is not the problem here. Its a textual piece which is parsed by email servers and your email client to deliver 'stuff' to you. That stuff can be anything in the world. This is what makes email such a success that not PG nor an entire pantheon of gods will manage to 'change' or 'reinvent'. Its the simple technologies that end up being the most genius ones. And every two days someone wants to come in and make simple into complicated because they have this idea that the world will actually prefer complicated. Its not a 'todo list' Mr. Graham. Its a generic piece of message or content I'm being sent or sending. Some of it are tasks to perform. Some of it is my nan asking how her grandchildren are, and some of it is Mr mamboto of Nigeria who wants to give me 35 million dollars - Win!

There is no problem with email. You don't want to change email. This is not the problem you're looking for. What you should be looking, perhaps, is a smarter email client which can represent the contents of various email's differently based on the context of the message. Some messages are todo lists, some are letters from nan, some are offers of a better life from Mr. Mamboto.

Hahaha. I love it. I think it was Joel Spolsky who said that you shouldn't worry too much about discussing your ideas because if they're actually novel the risk that people will steal them is low since in reality you'd have to shove them down most people's throats to try to get them to understand.

Reading these comments has only reinforced that notion. It seems silly to me that anyone could look at the way email works and say "yup, this is perfect, it's not possible to do better, let alone much better". And yet everyone who uses emails runs into the same frustrations with it many times a day. You go on telling people that email is fine, that just winnows out the future competitors, and I'm fine with that.

"Don't worry about people stealing an idea. If it's original, you will have to ram it down their throats." - Howard H. Aiken

http://en.wikiquote.org/wiki/Howard_H._Aiken

While I would tend agree with you that we don't need to change email, your examples actually do fit quite nicely into the "email as to-do list" idea:

An email from Nan would be a "read and reply" task. The email from Mr. Mamboto, assuming it's not caught by my spam filter, also requires me to take action.

I disagree with this quite strongly. If you think that 'an email from Nan' is a 'read and reply' task, then you can turn everything you ever do into a to-do list. Buying a steak is a to-do item because you have to cook it. Discussing what someone's reading at the moment is a to-do item because you have to decide whether to buy the book they suggested. Etc, etc. Almost everything we do either completes a task or creates a new one, if you want to see it that way.

For extremely busy people, everything becomes a to-do list. And this is why I'm somewhat unconvinced by PG's notions of email as to-do list. It probably is if you're a busy and successful person who gets a lot of business information and requests via email.

To my mind, the reason email seems that way more than other communications is largely because email clients give you pretty good ways of turning those communications directly into to-do items (unlike, say, the telephone, where you have to explicitly consider and organise the tasks that come from those communications).

Mamboto's email requires you to take no action what so ever. Its not for you. Its for the gullible 0.001%. You are clever. To me, a to do list is a to do list. That's it. Everything else from breathing to going to the loo can be seen as to do if you squint hard enough but its not. Its just part of life's action and reaction. Like I said, its not email that's broken. If anything its (arguably) the email clients.

The two biggest issues for me have to deal with communicating with groups of people.

First, I hate being involved with an email conversation between several people that lasts for days and you end up with a 100 email long chain. It's difficult to wade through the crap, everyone has their 10 line signature and the useless privacy warning for a 1 line email. It's annoying and very inefficient.

The other annoyance is not being able to unsubscribe yourself from threads that no longer are of interest to you.

This happened recently at work. I was communicating with our QA manager and our clients QA manager. I had taken care of my part, and they continued the conversation through email yet I still received every email because they would just reply all. Eventually I had to send an email and say "next time you send an email, please remove my name from the list unless I actually need to read the contents of the email."

To me, a simple solution to this is a threaded message board (even ones as simple as like vBulletin and the like from the early 2000's, obviously built with better technologies).

With a message board you have control over how much information you consume, but if someone really wants to send you something, they can send you a private message and ask you to join a conversation. You subscribe to threads of conversation, and then unsubscribe when they no longer interest you.

Find a way to do that in an email client and I'd easily pay $100 for that piece of software.

This was the problem with google wave. It tried to solve the distribution problem, but that's easy and solved. The real problem is the opposite, signal-to-noise and information overload.

Also, there is the general problem of keeping information up to date. If every new participant to a conversation has to follow all the convolutions of the original email thread (some of which may be missing because face-to-face meetings probably happened at one point) then that's a huge waste. Figure out how to create a system which naturally encourages people to sum up the current state of the discussion (perhaps with automated aids) and you'll be ahead of the game.

I feel like google wave tried to tackle these problems as well.

Specifically, it was possible for people to join and leave a conversation much in the same way that facebook messaging threads work now.

While Wave did subscribe fairly heavily to the traditional message and reply model it also had support for wiki-style messages, so it was possible for a summary to be maintained in the top message of each thread. (The instant replay tool I always thought was very cool, too.)

And towards the end it did start to introduce some tools to encourage people to summarise information (although admittedly nothing revolutionary). I'm mainly thinking of its widgets for event organisation, date planning and voting which are always horrible to do via email.

I think Wave had a lot of problems and, it may be, that the problems it did solve it didn't solve well but I do think it at least tried and had a few good ideas.

Gmail solved (mostly?) these problems for me: you can mute conversations (archive & automatically mark new messages as read) from the dropdown menu on the inbox screen.

It's not about a to-do list.

Email is a generic container. It can contain to-do's, sure. But it might also be a letter from a friend, an invitation to a wedding, a mailer about discounted products.

The way to improve this is to redirect emails to the relevant place. To-do's to my to-do app, invitations to my calendar, mailers to my Flipboard like app that sucks in all offers and puts them in one place.

The point is none of this stuff should ever touch my inbox. Additionally, if I don't have a "offers mailer app like flipboard" I'll never see those offers.

This can't be done at the client level. But it could play nice with existing email. As the message comes in, you either have an app (registered on the server) that says it can deal with that email content or the message gets bounced. It's kind of harsh, but I suspect most people's inboxes are taking way too much time out of their day - more that it should.

Then on the client side, you'd have a collection of apps that would be designed specifically to deal with those message types.

This, to me, is the winner, minus the bouncing. Email servers or clients can append headers based on what content is in the mail, and that information can be used to provide context sensitive app links. I can imagine a big button next to an email that says "Add to Calendar" or "Send to Evernote" or "View Map/Directions". I think Gmail does a good bit of this, so if they can provide hooks for more external services to capture, it would be a huge win.

the bounce is a bit harsh I'll admit. but the point I wanted to make was that if I don't want that type of message then return the message to sender.

i.e. if I don't have a to-do list app registered, don't send me a to-do.

Ah, that makes more sense. I don't make appointments over email, so bounce an invitation and they can see me in person. I've always liked the idea of email as a non-guaranteed protocol.

The easiest thing to look at is all the pain that people have with email as it exists today. There is the core of email, but then it is festooned with many additions, extensions, associates, and helpers. All of those things are there for a reason, because they solve a real problem with email. But, of course, those things don't have the luxury of rebuilding the whole system from the ground up, and doing so could lead to a design that doesn't have the pain points and weaknesses that need to be mended by additions. Consider a few common aspects: at a big company the MO is typically for individuals to join a large number of distribution groups and then also set up a lot of filters to move the mail they get for those groups into different folders because they have different levels of actionability (if any). Similarly, automated emails tend to require special filtering rules to make sure they don't drown out the S/N. Add to that the common difficulty of personally or publicly archiving email, because so often it tends to be used as an information storage system for key bits of data (contacts, decisions, technical details).

Personally I think the "todo list" model is good but lacking. I think ultimately what you want is something that would look to us like a mashup of issue tracking, messaging, wiki, and maybe even twitter from a certain perspective. I think switching from "private default" to "public default" for messaging is the biggest toggle, with the second one being pull vs. push (or search vs. signup).

Instead of thinking it as your list, turn it around and think of it as lists of people (or circles/bubbles if you please). The bubbles live in your "tank" of tasks. Your tank has different layers.

Each circle/bubble starts at the bottom but has a certain buoyancy - which guides its ascent to the top. For e.g., family bubble is very buoyant - so if you get a mail from your wife, it bubbles to the top really fast. In the time it takes to rise to the top, it can grow larger (more messages from your family) - which in turn increases its buoyancy.

The big difference is that you can change the buoyancy function at any time, causing the bubbles to start sinking/rising according to that change. Bubbles burst after some time - which means they get automatically archived or some sort of autoresponder sends an apology-for-delay email

You can play with different visual dimensions as well, like stale bubbles floating to the left.

An email client that lets me edit the title and body of the mails in my inbox would be a good start. I use email as a to-do list and oftentimes, 90% of the text in the email is not pertinent to that purpose (greetings, signatures, "polite" introductions, etc). Just being able to edit out unnecessary text would be really convenient. The changes would sync with across devices that have this specific mail client and you can restore the original text with just a click.

TL;DR: Mail client that lets you edit other people's emails in the inbox so that you can edit out things that don't fit the context of your mail usage.

"1. Email has to be replaced with a new protocol. This new protocol should be a todo list protocol, not a messaging protocol."

We will always need a distributed, general messaging protocol. That's what email is. If you create a "todo list protocol", it wont replace email. It will either run on top of email, or along side it, but it wont replace it.

Your comment nails the point. Email is to internet communication, as text files is to storing file data. It's the most basic form that's usable.

Sure, you could bolt on abstractions over it like doc/rtf etc. but at the most fundamental level you need some form of cross compatibility.

Maybe PG conceptualizes his email inbox as a bad distributed todo list, but I'm sure lots of people don't. I don't. My work processes are in an actual distributed todo list of sorts.

That said, clearly email is being replaced by other messaging techniques. There was an infamous Slashdot story in 2004 (christ I'm getting old) In Korea, Email is Only For Old People[0]. Back then, it was blogs, IMs and SMS, these days it's, well, still blogs and IMs and SMS but also Twitter and Facebook messages. Particularly Facebook messages.

Which is reason enough to think about replacing email -- with something that is as attractive to people as these techniques, but not proprietary, but rather at least as cross-platform, distributed and reliable as email.

[0] http://slashdot.org/story/04/11/30/0034259/in-korea-email-is...

IIRC, the followup story proclaimed that "In Soviet Russia, email only reads old Korean people". But I might have misremembered that.

1) Read, Write, Attach, Forward and Reply. Like it's right now. Maybe a "Mark as done" although the current mailbox system can easily do that by using folders and having an "Archive" folder (oh wait, we already have all that)

2) Labels and stars get me there. Oh wait, that's already in email as well. And remember the priority flag that lets others indicate how important they think it is?

3) Anything, as long as I can decide what's important and what's not.

4) Let's just stick with email. If it doesn't work for you as it is right now, stop using that webmail client you use and get a proper client. Email has always worked fine for me.

5) I sure hope not. I like email as it is.

Bottom line: I really don't want email to change. It's pretty good as it is right now, and mail clients such as Thunderbird offer all functionality any new system is possibly going to offer. If email doesn't work for you, you're doing it wrong.

1. I think you're misunderstanding; actions are a more general concept. Most emails I get fall into one of several boxes: "confirmation, no action required"; "event you might like to attend"; "request for email reply"; "request to do some thing in the real world"; "notification that something you were waiting for has happened". I'd like it to be possible for an incoming email to be marked as one of these (and the client can use it to determine e.g. whether my phone beeps). I'd like closer integration with my calendar; currently if an event email has been formatted right (which most of them aren't) I can "add" it to my calendar, but that's a one-way, fire-and-forget process.

2. Eh. I can handle my priorities. Maybe some very simple high/medium/low priority based solely on sender, but I don't want anything complex.

3. Anything can go on there. If I don't want to do it I can handle that myself.

4. Eew, my buzzword bingo went off. A REST API is still a new protocol. Anyway, the point of making this a new protocol and not email is that if I just add tags to email, 99% of incoming emails won't have these tags and they'll become useless. The only way to make senders adopt the new format is if they gain a benefit by doing so; with a separate protocol, maybe I'm willing to have my phone interrupt me for (some) new-protocol messages, but not for email. That will give people an incentive to use the new system.

The problem is, if you want to replace email it needs to play nice with email. You're not going to prise that from businesses unless it's out of their cold, dead hands.

A distributed client/server system would probably work, and you could go via REST, but if you're wrangling data along those forms as well as trying to fluidly integrate email into the experience (as it's not going anywhere), it might be easier to spec out a data format/protocol from scratch, you could even base it off REST if that floats your boat.

I don't think any such system can work in isolation. We would need to integrate it with existing email system and SMS and may be also HN/Twitter/G+/etc if we consider reading all these as a to-do item.

One solution that comes to mind is to let users integrate their existing email accounts by allowing them to periodically fetch email through POP and converting it into to-do items. We can also add "Reply as email" and "Forward as email" actions to implement outgoing email functionality.

But at that stage what you want is effectively a messaging client with heavy to-do functionality, rather than some transformative. Bolting the to-do functionality on is probably a lower-hanging fruit than a new protocol.

Ideally you'd need a protocol system that allows for multiple data formats to be specified through a plugin mechanism to cope with things like social networks and SMS on top of email, but then you're squarely in the territory of being at the whims and mercy of constantly ensuring the plugin works with the backend data APIs for the services (for social networks), and sticking to the letter of the RFC law for email.

It's a great idea, but as they say, going to need a bigger boat.

Think of it as a classification problem. Every message falls into one of four levels:

1. Should read immediately (generates an interruption)

2. Must read, but can wait (goes in a queue that I look at regularly, and must be marked read)

3. Maybe worth reading, but okay to miss (goes in a pool that I look at sometimes, but disappears if ignored. This pool should be bottomless.)

4. Should not read (uninteresting stuff, spam, and duplicates)

We have many ad-hoc systems for performing this classification, and email is only one of them; we use the medium itself as a proxy for parts of this classification.

Gmail's Priority Inbox is meant to distinguish level 1 from 2, and its spam filter to distinguish level 2 from 4, but it breaks down when level 3 messages (such as mailing lists) get into your inbox. RSS is for level 2 only, and can neither escalate to 1 nor filter to 3 and 4. Forums are for level 3 only. News aggregators like HN distinguish between levels 3 and 4, but they suck at escalating to levels 1 and 2, and their ad-hoc nature means that they have pretty serious duplication problems; an awesome post is still a level 4 message if you've already seen it.

If you want to replace email for me, you need to go broader; let me pull everything into the same system, then get the classification right.

One thing that is broken in most cases: email signatures. I can appreciate that they serve as a practical branding opportunity like a business card or letterhead, but no one needs to see their own in a chain of replies.

I recently converted from Outlook to Gmail and end up with email tails that consist of a stack of signatures. I'd rather easily insert a signature (easy shortcut in Outlook) in the first contact with a client than have to delete one that is automatically appended to a sequence of replies. I suppose my best bet is some tweak/add-on that allows quickly choosing a canned response?

Wish there was a concise signature format that combined fixed data pairs (Phone = 1234 5678, etc), branding chances, and a maximum size+. Then (as some mail clients or web apps do) show this info as a 'card' in a right sidebar, and stack those cards in the event that multiple people are in the conversation.

+ And automatic stripping of those "Keep it green, read on screen" messages. If someone's going to print an email, they'll print the email.

I think the solution to that is simple on the client side. Any text that repeats itself in two emails from the same person (including one's own) can be considered a signature and hidden. Gmail does a pretty good job of that.

Doesn't seem to do it for my signature - does it only happen in Conversation Mode or whatever it's called?

Rather than trying to replace the entire system, try thinking about the individual problems.

For instance, Dropbox have replaced a big chunk of where people used to email files to one another. I've seen this both inside companies and when operating as an independent consultant. In fact, I've had a surprising range of otherwise non-technical people ask me whether I have it installed.

Exactly, the problem with e-mail is that it is not RESTful. Nothing is hyperlinked by default. Sending a huge binary to a group of 100 people results in 100 send messages including the huge binary, even though maybe 50 people actually did something with the binary attachment. But the same problem is sending a mail to a large group of users. For example if Amazon sends an e-mail to its user the complete content is transmitted N times. If with a RESTful architecture they only had to transmit the URL to that message with a subject. Users that are interested would open the message.

To rephrase how I understand your comment, an email sitting in your inbox would just be a link to a glorified webpage hosted on Amazon's servers, where everyone can click through to that.

That's a pretty interesting idea. Emails from, for example, Amazon are pretty much just HTML files being sent to each user already. Obviously you would be able to customize the links sent as emails so each user can see the information they want being pulled from the database so it looks functionally like an email right now. Seems like it would be a nice bandwidth-saving protocol. It would also get around the issue of email storage and file attachment limits. It would offload the cost of receiving a message away from Google or the user and shift that burden back to the sender. Someone could easily tell how effective their newsletter is because it would count as a page view. The page could even be opened "within" Gmail as an iframe (or whatever people are using these days).

When I need to reach someone, I usually want them to respond as soon as possible. That's why I'm trying to find a way that I know they receive. Sometimes it is skype/gtalk (if i know that the person is at a desk with clients online), sometimes it's sms (if i know that they have their phone). And of course, voice call, if text doesn't cut it.

If I know their main communication agent is email and it's business hours, I will send an email.

My point is, you can make a perfect replacement for the email, from point of view of recipient, but people who are in control most of the time are the senders.

THEY will choose a way to contact you. If they see that FOR THEM it is more efficient to send a chat, SMS or email, they will do it.

Of course, you may try telling them: "That's it, I'm using only my new perfect todo tool", but I don't think it will hold for long.

I may definitely be totally wrong.

The thing that jumps out at me is your first question: the majority of the actions I get from e-mail come in the text of the email and are external to the mail client (implement this feature, fix this bug) rather than part of it (reply with an answer, accept meeting request).

I think the reason why email works for this is that somehow email "comes to me" whereas everything else I have to consciously "go to it" to check it. I recognise that some of this is habit, some of it is how the email client is integrated into the computer (outlook at work, mail on my iphone) so that it presents new stuff to me directly, and some of it is that it presents a single place to check rather than having to hit refresh on a bunch of webpages to see if anything has changed on each.

Are there any mail clients that handle CCed mail quite differently to direct mail in the inbox?

BCC to me, in most contexts, is "You can eavesdrop on this if you want." CC is sometimes "Just showing you that I am on top of this" and sometimes "I'm mostly dealing with Rollo, but there could be a question/task for you in here too."

In inbox terms, something very roughly like this: if I'm CCed on a message from employee Bob to client Rollo, it could say "Bob emailed Rollo about 'The contact form bug' and included you." And maybe alert me if my name/alias/nickname (hard to catch them all) is mentioned in the body.

If BCCed, maybe "Bob emailed Rollo about 'The contact form bug'; you can read it if you want."

In each case, neither should really be given the importance of an email sent directly to you.

I think the current email protocol should not be changed, for maximum backwards compatibility. The solution should be a web (or native, why not) client that does all those things based on the email content.

The difference would be giving feedback to the sender ("your email has been marked as important" or "your email has been converted to a task" etc.), with obvious incentives to convert to said email client. Thus, if both recipient and sender use the solution, this feedback happens in-app, without emails being sent back and forth.

There's a lot of room for creativity when designing a client. I liked someone else's idea of integrating with the various web apps such as todo lists, calendars etc. to keep from reinventing the wheel.

Everybody uses email differently. Any one person proposing a "solution" to email or a new client design or workflow or whatever is going to be shouted down by the 90% of the population that doesn't do it the same way.

The best thing, then, might be to let everybody design their own email client. I'm imagining something that lets you drag around GUI widgets like "this email has a to-do item associated", "displays this email's author", or "mark this email as being high/medium/low priority". Provide a few layout tools, maybe a really simple ___domain-specific scripting language in case someone wants a widget that you didn't provide, and everybody's happy.

That sounds similar to the Steve Jobs Calculator Construction Set story (http://www.folklore.org/StoryView.py?project=Macintosh&s...).

For the 90% of people I imagine until something much better is forced upon them they'll be perfectly happy with what they have, be it Gmail or Outlook. For the people who want a better experience, I imagine a lot of them will have the technical ability to strike forth and do it.

Essentially what you want is a backend message server and then let people communicate with it however they fancy with a high level API they can plug into their widget toolkit of choice if you go down that route. If you're into C++/Qt there's already a solution that does that (http://labs.qt.nokia.com/2009/09/21/introducing-qmf-an-advan...).

Very true, perhaps something along the lines of sublime text. So at it's core it's just a fast simple email client. Then have a really nice plugin system so people can create their own plugins really easily to customize it or add functionality as they like.

Of course non-geeks won't really understand installing plugins however others could create services (whitelabel versions) that have a bunch of plugins pre-installed so they work well out of the box.

I would rather try to make that 10% of the population happy than try to make everyone happy. I can't do that and I don't know anyone who can do that.

I'm sure if I can delight 10% of existing email users to a level where they are ready to pay me it is going to be big, very big.

The big advantage of email is its federation and no need for end-to-end connectivity (Store and Forward paradigm). Today due to cloud computing this could be attempted as a monolithic service and the messages can be stored in the cloud until delivery (or even afterwards). So a new email protocol should take into account if it needs federation (distributed) or not and what would be the intended reach.

IMO the core problem is that we're trying to use asynchronous service with poorly linked messages (email) for conversation between people which is synchronous, strongly linked and subject-oriented by nature.

I don't see how a todo list can match the informational nature of an email. For example I've subscribed to some mailing list like misc from OpenBSD, how can it fit in the system you are describing ?

Relevant? → http://web.archive.org/web/20110607224446/http://www.prescod...

Also interesting:

http://code.google.com/p/rmep/source/browse/wiki/References....

http://tools.ietf.org/html/draft-dusseault-httpmail-00

http://www.mailgun.com/

This is ridiculous - its like saying replace the car, because gas is too expensive, so we're not doing it right. Its simple - people use email incorrectly - they use it for task management (as you state). So maybe task management tools (the one billion of them) aren't doing it right. If you use email properly - solely as a ways of communication. Than it does it's job correctly.

The SMTP protocol is not going anywhere. Deal with it.

It's really straightforward to fix your griefs with e-mail: Write a MUA.

If it provides good value over normal e-mail clients and handles normal e-mail well then it will quickly become popular. If it's not backwards compatible then it's just yet another "todo-app" and will very likely not take off.

tldr; There is no such thing as "replace e-mail".

I can't shake the thought that if I could only forward an email to my trello boards, (a la Evernote) my problems would be solved.

This is something you can use Zapier for: https://zapier.com/zapbook/email/trello

also Evernote: https://zapier.com/zapbook/email/evernote

Do you mind sharing your list of trello boards (names/purpose)?

I think google wave was really fucking close; if it had been backwards compatible (to a degree) it would have been a headshot.

There were some email interop tools built on top of it, including an email notification system from Google. I think it was an excellent solution to several problems, but the default client was just too heavy and slow.

They also had a marketing problem. If they had simply called it "Gmail 2.0" or similar I think people may have used it more. I hope Apache Wave gets more traction. It's promising but I'm doubtful of its progress.

I want something along these lines: http://cr.yp.to/im2000.html

Being able to mark an email in a to-do system as "Waiting for reply" with an expiration date would be useful. This way, such to-do system could alert you when an email has not been answered to and prompt the next action.

Emails could be cross-linkable and have tags (among the tags, there could be the ID of the project they belong to).

Email is the worst solution to the problem of general communication except for all the others.

In fact I think that quote goes a long way to explaining why email is so wonderfully useful while also being annoying. Because it is so wonderfully free and open. That's also it's downside

I don't really get the TODO list thing (even though I think PG mentioned it himself). Is that because people tend to mail their TODOs to themselves? Or because most email translates to TODOs?

I know that I certainly don't want a system that allows people to push TODOs at me.

Every email is a todo. Period. Full stop.

This is true regardless of your work or workflow. Consider that at the very least most emails tend to be an implicit request for a reply. In most cases that reply requires at the very least remembering some bit of information (in the best case scenario something that is trivially easy to recall). And even more fundamental than that, each email message is an implicit command to digest the information contained in it. But beyond that, it's quite typical for work to be tracked or requested through email, for some jobs it's by far the normal way that the vast majority of work is organized.

Most emails are spam, actually. Some legitimate, but the majority doesn't warrant a reply (like all the "marvel at the new features of our startup" mails). Of course the mix varies from person to person. And they are TODOs in the sense that you feel like you should delete them, or archive them, or whatnot.

I think it would be better to make most of them go away automatically, though. Perhaps things like "automatically save attachments from x into project folder z" would help (already doable? I don't use filters much).

Maybe it really would be better to make emails a universal transport layer and integrate it better with other stuff. People send you a TODO -> goes into TODO list. People send you an image -> goes into photo library. And so on... Of course I always hated the idea of Outlook of allowing other people to mess with my calendar, so I don't know...

email doesn't need any replacement. it's a fantastic messaging protocol. It's used by millions and every system supports it. Maybe in the far future it will disappear as other messaging protocol will rise, but we still use phones and snail mail, and there are very old. What need to be replaces is the bridge between email and todo protocol. The task management tools, even now, are not solving the problem of intelligent task management and creating more work than reducing it. You have to file, categorize, make priorities, or even type the tasks yourself. That's the reason people don't use them and use email instead as a task management tool - which it doesn't support.

Asana is working towards this (http://www.asana.com), though it's currently a mostly closed system, not an open protocol.

Umm make it more similar to current postal system?

Let me share my thoughts as we have been working on these ideas lately. To see our work please visit http://bubbleideas.com

At the outset, let me be straight and upfront to say that it is nearly impossible to kill or replace emails. The idea may be frighteningly ambitious, but from where things seem to be one cannot possibly replace email by creating yet another (so what if better) - mail service.

Current level of email, its provisions, functionality, simplicity and pervasiveness are enough to keep the user coming back in and keep him/her satisfied too. Probably the thinking of having an evolved protocol, that provides for more control on who can/cannot write is also not ambitious enough. At least not so much as the idea itself is.

What I mean to say is that the approach to execute a disruption of this level one has to think on a bit on radical lines. Answering 15 regular questions on a HN post may help but not let you get away from reality. Think deeper, perhaps.

Fifteen years ago emails nearly killed physical letters (yes they do exist even today) with its convenience, simplicity and for being completely free. At that time the need to be able to write to anyone with something as simple as a form hit at the bottom of one's hierarchy of needs.

Now this is not the case. The need to move to something higher or better is not at the bottom of my need-pyramid. I believe this is true for many users out there. One cannot just service, iterate and evolve from the existing to be able to disrupt/replace. That's what my thoughts are.

I think of email as a schema-less, dynamically-typed system for communication. Anyone can send an email to anyone, and there's only one "type" for email (a long string of blah)... but most emails are sent to too many people, and often go unread. IT works, but it's a huge mess and it's unreliable. Also, the time behavior of email isn't right for all purposes. Some emails are generally useful 2 years later (and if you think the content is likely to be useful in 2 years, you probably shouldn't use email). The vast majority are not. Inbox search solves the time problem, but it feels "bolted on". Inbox search isn't an intrinsic fix but a late patch; it's using full-text search (which usually works, but not always, because you might not remember any key phrases) because there's no better solution right now.

So one thought is to consider something analogous to static typing, where emails have types (we'd need a different word, because it's not exactly the same concept) and these message types restrict (i.e. you might create a type T for emails sent by user U under 500 characters). Unfortunately, I can't see a way to design a system like this without making it massively complicated. The problem here is that people are already overloaded with email and adding any piece of additional complexity is going to piss a lot of people off. Google added typed edges with Circles in Google+-- clearly a good feature-- but they took a lot of flak for G+ being "too complicated" for "mere mortals" to understand because of Circles. When people are already fatigued and overloaded and starting to get annoyed with the "tragedy of the commons" (all of this being with email, and with social networks) even small bits of additional complexity turn people off.

I think the final answer is: let email be. The problem isn't email itself. There's a place for schemaless, dynamically-typed communication. It (or some form of it) will always be useful and some part of how we communicate. The problem with email is that people use it for too many things and in too many sloppy ways, so the solution might be to identify communication patterns (for example, persistent storage of knowledge) where email is not the best solution and focus on those.

For some ideas, consider one problem with forums and social networks in general: time behavior. Lots of content is generated, but quickly becomes useless. How often do you read a 5-month-old thread on a message board or social network? Occasionally, but not often. This imposes siloization by time, so the value of the content can never grow faster than linearly as a function of the amount of it. A lot of interesting discussions just won't happen if they can't occur asynchronously. They won't get the critical mass.

One forum that I think deserves a lot of props for solving the time problem is Quora. Quora has managed to structure itself in such a way that content generated 12 months ago is still extremely valuable. It doesn't fall into obscurity or become useless because it's "old", and it's pretty common that a 6-month-old answer will get a new comment actually worth reading. Quora is also great in terms of how it handles new threads. On a typical message board, an OP that doesn't get immediate response is just a failed thread. On Quora, it's an open question. A good way to set it up, because not every OP that doesn't get immediate attention deserves to die.