Instant messaging is dead - long live instant mail

I really don't get it. Just how did we end up in this stupid messed up instant messaging situation. I mean, how did several proprietary, centralized and for the most part incompatible messaging networks end up usurping the existing distributed and highly compatible messaging system we all use daily and have been for decades, that is email?

Maybe the question is so obvious no one has bothered asking it before. Let me phrase it another way. What exactly is the difference between "instant messaging" and email?

Well, I guess its because its "instant" isn't it? And it has that "on-line" indicator, and all those rinky-dinky icons and a separate little window for typing your messages in.

I see, is that it?

Well in case you haven't noticed, email is now, for all intents and purposes, pretty much instant. Most, if not all the delay in getting email these days is largely the delay for you to hit the "get messages" button in your email client. If there is any difference we're probably talking the difference between 1 second and 5 seconds. Occasionally it takes a minute or so, and once in a while when Yahoo screws up, a few hours. But really, so what? How often in IM have you hit "send" and you didn't get a reply for minutes or until hours later?

It turns out for the most part people use IM in quite a asynchronous way, one expects delays because people usually time-slice while they are using IM. I'm doing it right now. There's an answered question in my IM client and I feel no compunction to get right to it and bash in my response. Isn't that completely the idea of IM - its instant but you expect that the person may not respond. If its really urgent well then, pick up the phone!

About that "on-line" indicator... In my experience its usually a lie. Half the time someone who says they are on-line is actually not there or didn't actually mean to be. They turned on their computer and it put them on-line automatically, or they intentionally told their IM client not to announce when they are idle. So when you send them a message you don't get a response, or not until much later - just like email!

The converse is also true - half the time when they are off-line they are actually available. They either forgot to start their IM client, or are up for receiving important messages from a few people, but didn't want to announce their presence to people just wanting a chat. I find a lot of people send me messages when I'm off-line anyway - just to probe my status.

So, that leaves the separate window and icons and... Lets face it, all that is just window dressing. Yes, window dressing. One could easily build an email client just like an instant messenger (see below).

Thus, here is my suggestion: ditch all that proprietary instant messenger stuff, its time is gone and the inconvenience of IM spam, viruses and having to deal with multiple IM networks is just not worth it. In its place will be a separate email client, or extensions to existing clients (in the same way that RSS/blog reading functionality is now being integrated into mail clients).

The client will have a list of your favorite email buddies on the right and allow someone to click on a name to start "messaging" with them. The client will fill out the email From: and To: fields behind the scenes and the user will type in the message just like in a regular IM client. When they hit send the client tags the email to adds to indicate its a message intended to be read with, or intercepted by, an instant messaging tool. There are many options to do this - perhaps a special X-Instant-Message heading, maybe just a special X-Priority header value "0 (Instant)", or even just use something like putting "[IM]" in the subject line (which has the advantage its easily filterable by existing email reading technology).

On the other end the recipient, if they are running a client compatible with "instant" email will see the message in the mailbox with its "instant" header and pop it up in an "instant" message client window - again just like in a regular IM client. The recipient can then just type in a reply message and hit send - again the client fills in all those other fields normally in an email.

If the recipient should happen not to be using a compatible instant email client then they'll still get the message, it'll just appear in their regular mailbox as normal and they can still reply! If the tagging method used is something in the subject line then their reply will even appear back in the senders IM tool. So, in effect all email clients are capable of being compatible with such a protocol.

And as for that pesky on-line and off-line status? Well that's easily implemented by having IM capable email clients act as auto-responders. When someone's client starts up it goes through their buddy list and pings all their buddies email with a status query. Again this either has a specific header to indicate its just a status query, or it uses the subject line setting it to something like "[IM] on-line?". The recipient's IM tool, if its on, sees the message and responds to it based on the current users preference, adding in their status message if any. Until any response is received the other client will assume them to be off-line. Again, someone without an IM compatible client can still manually generate a response if they want to, or filter out such messages to the trash.

Finally, to deal with communication delays the IM clients can send message with receipt confirmation request. That way you can know the difference between a delivered but unread message, and an undelivered message. This will enable the client to show an animated icon for each message indicating when its delivered, read and finally when its responded to. Yeah, the "xxx is typing a message" could be synthesized too, but really, I don't think its worth it.

Any drawbacks to this scheme?

Well, it doesn't offer "chat rooms" or private multi-way conversations, or support the anonimity of IM services that let you create multiple identities. However why not use the existing Internet Relay Chat for that which is standardized, has an open protocol and has tons of free and mature clients available? Alternatively all you need is a hacked up SMTP server that can generate email aliases or mail lists on the fly by some simple email based request protocol. It then forwards emails it receives for the aliases and lists using the standard SMTP protocols. No rocket science required, no separate protocols and again completely compatible with all current email tools.

The huge benefit of this scheme is that its layered on current technology and can be implemented to be backward compatible with current email clients so you don't need to get everyman and his dog to adopt it before its useful. In fact its completely useful from day one. Plus your IM is inherently no less secure than email sent and received using your existing email client. All that good anti-virus technology you our your company bought that is scanning your email still works just like it always did. No special ports are required to be opened up so just like HTTP based protocols it works through all current firewalls with no changes.

Other benefits? Well there is no centralized IM server to go down. All messaging is distributed and the only failure comes from a mail server going down. So if AOL's email servers drop off the planet all you loose are clients using AOL email, not every single IM user on the planet. That means you're also not tied into someone proprietary system, its entirely open and clients and client extensions are easily developed.

Do the benefits outweigh the drawbacks? Well since as far as I can see the only drawback is the relative slowness of email, I say most definitely no. In my experience on average the speed of email delivery is entirely satisfactory for "instant" communication. In fact most of the "instant" feeling of IM is purely derived from its intrusive "pop up a window on receipt" behavior that demands some attention over email that will languish in an inbox. Hence its a usage problem not a delivery problem.

Next steps?

I say a standalone client and add-on for Mozilla mail should be developed immediately. A basic implementation is so easy it could be released within just a few weeks, and regular IM and its closed, proprietary messaging kingdoms would come crashing down in months. For me, that wouldn't be a moment too soon.