I'm almost convinced at this point if somebody simply built a facebook like interface, and used email as the messaging protocol, but didn't display it like an email, more like a FB conversation (as opposed to a threaded or gmail-like conversation view), that it would be used. There's not really much that's offered by alternate messaging solutions that email can't do if it existing in the right sort of framework:
1) Person-to-person? Check
2) Person-to-group? Check
3) Group-to-group? Check
4) Group-to-person? Check
5) Multimedia? Check
6) Fancy formatting? Check
7) Attached files? Check
8) Near real-time? Check (most of the time)
9) Deliver Fault tolerant? Check
10) Federated/distributed? Check
Why everybody seems to want to reinvent email is beyond me. About the only thing that FB or G+ offer is the storage of a server-side contact list so I don't have to remember their email address and the use of a white-list for sender/receivers so I don't get spam. Offer the same with email and a decent web interface and you've basically recreated any "modern" social network, except it'll be built on a time-tested, robust protocol that's already ubiquitous across the internet and already has billions of users.
edit I guess what I'm saying is that it's the application layer (server and client side) in the email equation that needs most of the rework, not the protocol layers.
> Why everybody seems to want to reinvent email is beyond me.
11) Program parsable structured info? UNCHECK
How cool if emails have a semantic layer standard, like when someone invites you to an event using email, another app could automatically recognize datetime, convert time zones and add to a task reminder? (think of embedded iCal or vCard, but more generic and powerful).
I agree with most of what you said, except that the real-time aspect is not real-time enough. If email were actually real-time, then it could completely replace instant messaging as well. Right now it's lacking.
True, which is probably why google put im right next to the message viewer in gmail. I know of many ocassions where a flurry of emails turned into an im session.
I think gmail's "conversations" are really the first try at what I'm talking about, a new front end on email, but I don't think they work well enough personally. And they haven't really expanded well on the concept recently.
1) incredibly poor rollout strategy (imo)
2) what problem did it actually solve again?
forgive any appearance of snark; i just wanted to be concise, and i don't think that "the ideal marriage between email and IM" is something that people were - or are - desperately crying out to have.
I believe it failed in part because of the slow rollout (nobody you cared about had access yet) and lack of interop with email for notifications about changes, etc. I tried using it, and gave up. By the time it became widely available most of the early adopters gave up as well.
Shameless self-promotion: my startup (http://movableink.com) lets you add real-time elements to email. In fact, we have a group messaging company using it to show real-time conversations in status emails.
It doesn't allow interactivity (which is what you're probably thinking of) but it does provide real-time content.
It is real-time, it's just that current email clients aren't designed to be efficient, it's purely UI's fault. Again this is something we've fixed at post.fm, cant wait to show you guys.
Obviously email doesn't support seeing someone type, but SMTP is almost as fast as XMPP - sub 1 second doesn't really make a difference, it's usually IMAP that's the slow bit. Of course it's just as fast as XMPP if both sender and recipient are using post.fm, but the real latency comes from the recipient using eg gmail which has really slow IMAP polling in the web client (plus having to go back to the inbox or clicking show new message in gmail). Post.fm doesn't use IMAP under the hood so its instantaneous (and querying your mail in SQL lets us do amazing stuff).
its a new email platform to rival gmail, but we're stealth still so i cant disclose much. we'll be starting a beta pretty soon and issue an official press release at that stage - make sure you request an invite in the meantime.
I made a REST/HTTP/JSON API for accessing IMAP mailboxes: http://imappr.com. The idea is to make email, as a messaging platform, as easy to work with as the Twitter or Facebook APIs.
E-mail is so broken fundamentally, that it's not even funny. I'm surprised more people aren't trying to replace it.
E-mail's based on the idea that it is free to message me and bother me and take a few precious seconds of my stream of consciousness.
If it's free to email people, then of course spammers will flood email channels with their deals and scams.
Ideally, I want a communications platform where only my 200 or so friends, co-workers and friends of friends can message me for free. Anybody else who wants to contact me has to send the message with a $1 bitcoin (interrupting my stream of conciousness price would be custom set by me, so lil' wayne would probably set his price at $75).
If the message from a stranger I got was in fact a cool dude I met at a party last weekend following up on that cat picture, then I'd click "reply and return" to give him back that bitcoin. If I see that the message is from a prince, I'd just ignore it and go buy some gum or something with his precious $1.
The current horrible e-mail architecture feeds giants like gmail, microsoft, yahoo b/c everyone is going to get tons of junkmail and people around 1999 had to start moving to cloud based providers who did free spam detection to parse through people's emails (Outlook Express sucked at spam cleaning). Problem is the web giants are snorting in everyone's private communications. It's as if the US Postal Service offered to deliver all mail for free, but in exchange opened everything and read it and if they thought this is something you shouldn't read or if this is marketing propaganda, so they won't deliver it to the recipient. I think pretty much everyone would think that's a crappyly architected postal service, but I guess with email we shouldn't be thinking about those kinds of things. Let's just figure out some new technical protocol instead, after IMAP and POP and SMTP will be replaced by SPDY or RESTful HTTP right? Yeah, let's build that instead.
True, e-mail is a universal platform, but it sucks.
I understand your dislike of spam, but what's the rationale behind building in the filtration into the architecture? That's merely a constraint on what email already offers, not an evolution.
Right now spam filtration is decentralized (as it should be), and there's NOTHING stopping an email provider like Gmail or Hotmail or [fill in your new startup] from CHARGING senders a fee to actually deliver mail to your personal inbox.
If you think your charge-per-message makes sense, then build your own email server that intercepts incoming messages and makes sure they've been paid for before distributing them to you (or your customers). No one is stopping you.
By the way, if there WAS a centralized spam filtration somewhere, as you seem to be proposing, there would still be "a giant" snooping everyone's mail. Or did you not realize that.
hammock, blueplastic didn't say to centralize spam filtration. He said to make messages cost money, thus making spamming unprofitable. This is totally different from the machine-learned-model-reads-all-my-mail situation that we have now AND totally different from a centralized Big Brother antispam agency.
Email is a collection of protocols stacked on top of each other, so when we're talking about replacing email you have to be specific about which part you'd like replaced. DNS? SMTP layer? IMAP layer? application / email client layer? spam filtering layer?
What you're suggesting is indeed something that can be,and will be, added to email. But there's nothing wrong in email at a lower level (SMTP say) thats preventing someone from setting this up. One thing that definitely sucks is IMAP though, would love to see that replaced by a restful protocol. But we have no alternative to a ubiquitous distributed and open messaging system that is SMTP.
> It's as if the US Postal Service offered to deliver all mail for free, but in exchange opened everything and read it and if they thought this is something you shouldn't read or if this is marketing propaganda, so they won't deliver it to the recipient.
USPS has a large list of Restricted Matters that you're not allowed to send. It's ridiculous to think they would never "inspect" your package in anyway.
The only place I have seen where people are able to set a fee on "email" that is sent to them is in EVE Online, where I believe it was introduced to stop spam. I'd never thought of it in the real world before, but now that you mention it, I wonder how well it could work. Unfortunately, it may be a little bit too late to introduce it now.
It's a good idea, though not a new one. Bill Gates suggested this very idea in his book The Road Ahead. I must have read it 15 years ago when I was in elementary school and have always wondered why no one's gone ahead and implemented it.
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.
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.
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
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/
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?
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.
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.
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.
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?
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.
@sankalpk - I've seen that before, and it's a great post-mortem. I can see why it's hard for a collaboration company that's not solving a strong pain point. We look at the relationships that are live and die via e-mail, and are building a solution for that.
So, why would I trust you with 5 years of all my sent and received emails? Should I take your word for it that you'll just save the email addresses and the sent/received timestamp for each?
@blueplastic - we do regular security audits and will soon engage with a firm to provide that guarantee as well. In the interim, what would you like to see to alleviate that?
I do appreciate the reply. The only way I'd feel safe is if you never got or saw my emails. Instead of me sending 5 years of my emails to you, I'd rather you send me 2,000 lines of code to analyze my email locally and locally tell me who I need to follow up with. If your analyzation code came to me, I wouldn't even mind if it did NLP and deeply datamined the emails to tell me who I may have missed following up with.
Ideally, I'd like to see unsecure e-mail replaced by crypto communication systems based on OTR and people locally storing their emails on Raspberry Pis, but that's dangerous stuff and I probably shouldn't have even said that.
Thing is, I'm sure you're nice guys and gals right now, but when you're billionaires and have 500 million people's digital data, evil you will turn.
By the way, good presentation at SVNewTech last night.
I have to think about the security of my business. The way to get me to stop running my own SMTP and IMAP is to provide a service which is:
- auditable (our stored messages by us; the whole system by a third party)
- reliable (99.9% uptime, that's not so awful)
- resilient (if you lose a server or a data center, I shouldn't have to worry about it. Ideally I don't notice anything except perhaps a slowdown)
- guaranteed (with a hefty bond against security issues and another one against prolonged downtime, not a pro-rated refund)
Those are the gotta-haves. If you provide a secure clearinghouse to talk to our clients and vendors, that would be a major selling point. It has the chicken-and-egg problem, of course, but also the network value effect.
Many years ago, working a support desk at an ISP, I fielded calls from angry seniors who wanted to know why their dozens of email forwards were not getting delivered to their friends, who desperately needed to know about the Microsoft/AOL cash reward giveaway. Suffering through the message logs, I would find typo'd email addresses, blacklisting message, or whatever the cause of the day was. I'd then have to explain that email and the internet was "best effort", and there was no guarantee of delivery, even if you did manage to type the email address correctly.
Interesting now, how most people wave off email delivery as flaky, or accept that spam filters will eat the 5% of incorrectly classified mail.
Are social networks more or less reliable? Have we all become numb to the best efforts of the web? I'm not sure. I think it is interesting though. I wonder if those seniors still call up these days?
1) Person-to-person? Check
2) Person-to-group? Check
3) Group-to-group? Check
4) Group-to-person? Check
5) Multimedia? Check
6) Fancy formatting? Check
7) Attached files? Check
8) Near real-time? Check (most of the time)
9) Deliver Fault tolerant? Check
10) Federated/distributed? Check
Why everybody seems to want to reinvent email is beyond me. About the only thing that FB or G+ offer is the storage of a server-side contact list so I don't have to remember their email address and the use of a white-list for sender/receivers so I don't get spam. Offer the same with email and a decent web interface and you've basically recreated any "modern" social network, except it'll be built on a time-tested, robust protocol that's already ubiquitous across the internet and already has billions of users.
edit I guess what I'm saying is that it's the application layer (server and client side) in the email equation that needs most of the rework, not the protocol layers.