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.
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.