Instant messaging clients: Stop the insanity

Skype. AOL IM. Yahoo IM. Google Hangouts. Facebook Chat. Twitter DMs. The number of instant messaging accounts that I have to deal with on a daily basis is absolutely mind numbing.

It's not that I necessarily choose to have all of these accounts; it's because the people who I have to interact with on a daily basis have these accounts, and have their allegiances to specific services.

Things have become a little better over the years. Microsoft shut down MSN Live Messenger recently and folded the Live account stuff into Skype, and Skype now can talk to Lync with some limitations and vice versa.

But I still need to use several distinct IM programs to manage all my accounts.

On my Windows 8.1 desktop, I use Skype and Lync for dedicated communications on those systems. I have TweetDeck running in the browser for all of my public and private Twitter interactions, and Facebook also runs in the browser for those folks who live exclusively there.

To attempt to catch all the rest, I use Trillian, which is a good multiprotocol IM client that uses a centralized communications network to consolidate (federate) communications, and has a unified logon.

Now, it's certainly possible for Trillian to be used to handle Skype IMs, and for Facebook, and for Twitter as well. There's a few problems with this, though.

The software engineers at Trillian (and those developing other multi-protocol IM clients like IM+, Adium and Pidgin) all work in a best-effort basis to try to reverse engineer or maintain compatibility with published implementations of protocols of all of the competing IM systems.

As such, from time to time, connectivity to these networks breaks, and not all functionality is supported.

The reason why the connectivity breaks is because each of these providers implements changes or new functionality, and, as a result, the third-party implementations of these protocols stop functioning until the fix by each messaging client rolls out, or the open-source community develops a shared library (such as libpurple, which is used by Adium and Pidgin and a few others).

Now, it's understandable why certain information/content providers like Google, Microsoft, Twitter, and Facebook want to maintain their own clients and their own protocols, because there are distinct advantages to integrating these with all of their distinct services and respective platforms.

But there has to be a better way.

Trillian, for example, has been breaking on connectivity with Facebook more often than I like, so I'm forced to use the Facebook web UI when communicating there.

I would also prefer not to use Trillian for Twitter and Facebook integration, because I'd get far too many updates and it's hard to control granularity of what Twitter and Facebook can do within its UI.

The situation becomes even more complex in the mobile space, where the preferred IM client is tied to and is tightly integrated with a specific mobile operating system.

That being said, there has to be some common ground. I'd rather not use multiple IM clients, because it clutters up my screen and you end up having different notifiers coming up in an inconsistent matter.

And using a third-party multiprotocol clients on a mobile device using reverse-engineered or best-effort protocol support is going to make the communications disconnect even more of an issue now that devices far outnumber desktops.

So then the alternative is that you need to have the native client for that platform running in resident memory. Modern mobile operating systems support push notifications, but we know how annoying that can be, as well.

This gets even more annoying when you, say, end up having to use a web UI for a social network like Google+ or Facebook, and then suddenly an IM session pops up in there and gets out of sync or overrides the one in your multiprotocol client.

Trillian and IM+ have the advantage of working on various mobile device OSes, but the key is keeping them running in the background, which chews up resources.

Man, wouldn't a single instant messaging standard be nice? So you could just use one client?

Well, there is. Sort of. The XMPP protocol, previously known as "Jabber", was a good attempt by the IETF at trying to provide cross-platform unified IM communications.

For a long time, Google provided an external gateway for XMPP, but recently dropped support for it on Google Hangouts in May 2013. Facebook Chat supports some of the capabilities of XMPP, but it's not a fully compliant XMPP server.

To be fair, Skype doesn't support XMPP at all, and the native protocol is completely proprietary, so all third-party attempts to communicate with it directly or via a federation service have been either reverse engineered or licensed directly.

Obviously, getting all of the IM services providers to agree on a unified instant messaging protocol just isn't going to happen. But there is another way to deal with this issue.

And no, although it actually is my favorite IM platform and my employer develops it, and it works on such a wide variety of devices, I don't think everyone should abandon everything else in favor of Skype, because that's an unrealistic and totally impractical view of the world.

Ideally, what you really want is a natively implemented IM protocol service that can simply plug into the device's existing integrated messenger and notification system. But such a thing doesn't exist yet.

The way I envision this is that each of the major platform providers agree to a "package" format that contains the libraries and protocols that permit encrypted IM communication to the third-party service.

Optimally, this package format should be easily translatable or portable across the different device OSes, and each of the respective service providers should be responsible for maintaining a repository that allows a platform partner to download the respective package so that it can be automatically updated and integrated into the native device platform messaging application.

The alternative to not doing this is not just device platforms becoming siloed in applications and user bases, but also becoming isolated from each other as each of the respective companies carve out market share and ecosystems.

Are we facing IM client overload, or, alternatively, a Tower of Babel with instant message communication on competing device operating systems? Talk back and let me know.