[rvkennedy]

Sooner or later, email will either die or get better. The problem with email for most of its life was that there was little competition. Certainly SMTP has never had a serious rival. IMAP came to challenge POP, and won: this made email better. And Exchange has certainly set a standard that IMAP and webmail providers have had to meet.

But it's not much compared to the seething shark tank that the web has been for the last twenty years. Sooner or later I think a RESTful HTTP or SPDY API will replace IMAP, and (for client-server comms at least) SMTP.

I think ccLoop is a side-issue, because they were addressing the problem of mailing list management. Contactually's approach seems to be wrong-headed to me, making the user send and receive more emails! But really it's more of a CRM system than a step forward for email, so perhaps it's solving a problem I don't have.

At comms.io, we're writing an email client. The idea is to work with IMAP, take on the lessons of Gmail, but modernize the experience, make it lightweight and transparent. If you've seen the Gmail interface lately, what I mean by lightweight is the opposite of that. Anyone who's interested in helping out, do get in touch.

[there]

Sooner or later I think a RESTful HTTP or SPDY API will replace IMAP, and (for client-server comms at least) SMTP.

"replace" is a strong word. IMAP (version 4 that most things use these days) has not replaced POP3, but is a much-improved alternative that is well supported on the server-side and client-side. the reason it was able to gain such popularity was that the spec (RFC 2060) came out in 1996. how many different POP3 clients were even around back then? (according to wikipedia, outlook express 1.0 came out in 1996.) a lot of people at that time were probably still reading mbox files in pine through a telnet session or never e-mailed anyone outside of AOL.

The problem with email for most of its life was that there was little competition.

and now e-mail is so prevalent that making changes to the core protocols like SMTP, POP3, and IMAP is nearly impossible. we've been living with SMTP since 1982.

every provider that supports IMAP still has to support POP3: google, yahoo, AOL, MSN, and probably every university and ISP. SPDY will never completely replace HTTP, so sites using it will always have to run both servers in parallel, just like IPv6 will have to run alongside IPv4 for many years to come.

for a new protocol to replace SMTP or even augment it, it would have to be designed, refined, turned into an RFC, then probably debated some more, and then support would have to be added to all of the major MTAs like sendmail, postfix, qmail, and exchange, along with many firewalls, spam filters, and other in-between devices. clients need to support it, so that's outlook express, thunderbird, iphone, android, blackberry, and every other little device and program that speaks it. getting the manufacturers or maintainers to implement support for new things is hard enough, but actually getting all of their customers to switch or upgrade is an even bigger problem (see IE6, DNSSEC, etc.).

maybe it's the rate of change in things like HTML and CSS over the past few years that gives the false impression of being so easy to do.

[zokier]

> a lot of people at that time were probably still reading mbox files in pine through a telnet session

I'm still reading (some of) my mail in pine through a ssh session.

[rvkennedy]

"replace" is a strong word

exactly the word I intended to use: but "sooner or later" can be a long time coming. I know POP still exists, hell, gopher still exists but I'd say it's been replaced in all practical terms.

every provider that supports IMAP still has to support POP3

In what sense - do you mean practically, or in some technical way?

for a new protocol to replace SMTP or even augment it, it would have to be designed, refined...

Right, but I restricted this to client-server. Any protocol you like can replace SMTP for client-server, simply by taking messages from the client, then sending them on via SMTP. This is how Courier provides mail sending via IMAP connections.

maybe it's the rate of change in things like HTML and CSS over the past few years that gives the false impression of being so easy to do.

It's not easy, and it won't be quick. But I like many slow, difficult things, I expect it to happen at some point. In fact there's already a draft RFC to for RESTful HTTP mail retrieval: http://tools.ietf.org/html/draft-dusseault-httpmail-00

[rvkennedy]

Wow, someone really doesn't like draft RFCs!

[dpapathanasiou]

Anyone who's interested in helping out, do get in touch.

What's your contact info?

I'm working on something related for project management and task planning (though it's more in sync with the premise of the original article and to a lesser extent with ccLoop) called TeamWork.io http://teamwork.io/

You can reach me through the contact form at that site, or via http://banrai.com/contact.html

[skevvis]

Completely agree with you that email will either die or get better. The timeline is the question. We haven't seen any strong competitors to the current incarnation of "e-mail" come and really threaten the core architecture. E-mail is too open, too standardized, too widely implemented to be quickly overtaken by any other solution.

With Contactually, we started with that theory - e-mail is still, and will be for the foreseeable future, the primary mode of communication. We're not focusing on making the user send and receive more emails - but we push the realization that e-mail is already where you're doing most of your communication. Why shouldn't you have a tool that leverages that?

[blueplastic]

Did you totally miss Facebook's existence? Teenagers these days don't even use email. Facebook's sucking in the next generation's messages. Email's too slow and asynchronous they cry. Douglas Rushkoff would bet to differ, but anyway. Facebook's unified messaging was kind of interesting, but I might as well be CCing all my email to Kim Jong-un.

[ams6110]

Big as it is, it's still closed. How do I communicate with a person on Facebook when I don't have a Facebook account (I don't). Email has no such barrier: if you have email -- from any provider -- you can email anyone else.

[ta12121]

I thought you could specify a username and receive mail as [e-mail].

[skevvis]

Definitely - when it comes to social communication, there's Facebook, Twitter, Google+, etc. And that's bleeding across into professional communications as well, with companies regularly monitoring social networks and engaging with customers on there. But e-mail still remains, for professional communication, the dominant platform.

[rvkennedy]

I have the impression from your site that Contactually uses email as a principal interface for the service - I expect I'll find out more as you've intrigued me enough to sign up and try it out. I started out on the Comms project because most people I know find email a chore, and it seems like everyone is challenged to find their own solution to basically the same set of problems. My worry taking on a new service that uses mail as the user interface is that for many people, the whole problem with mail is the user interface. Did you consider doing it as (say) a Gmail plugin, rather than a service that mails the user?

[zdw]

QMTP is a good start, if only because it's simple and 8-bit clean.

http://cr.yp.to/proto/qmtp.txt

Put inside CurveCP and a ton of security problems would also be solved.

[LeafStorm]

MIME could use a redesign too. It's a ridiculously complicated format that makes encoding e-mails that contain anything besides "plain text US-ASCII" far more difficult than it should be.