Introductory Post

Welcome to jabbering.org a new and exciting website that will showcase some of the capabilities of the Jabber Messaging/Presence Protocols. We hope to provide Jabber users and newcomers with some interesting examples of how Jabber can be used to augment a website and make the 'net in general a more connected experience for users. The possibilities for integrating Jabber into a website are endless, from online chat boxes to full scale monitoring and tracking of assets.

For those not familar with Jabber, it began as an Instant Messaging Service, much like MSN or ICQ, allowing users to exchange presence updates and real-time messaging but has since grown into much more. Jabber is based on open standards, drawn up by the XMPP Foundation and uses XML to convey information between users and servers. Jabber uses a server architecture similar to email. Any machine which has a domain name can run a Jabber server, and then messages and other information are routed between servers, then finally onto end users. This architecture has two main advantages:

  • Server distribution, means that if one server goes out, the rest of the Jabber service remains active. Could you imagine if there was one central email server, and if it ever went down then all email would be offline? This also means that no one organisation/company owns the service, anyone is free to run their own Jabber server, as anyone is free to run their own email server.
  • Interoperability, could you imagine if you had to have an email account with the same provider as someone else who you wanted to send an email to, just to be able to send them an email? Such an idea would be ludicrous, and email would probably not be what it is to us today, if it's designers had taken this approach. Likewise with Jabber you don't have to have an account on the same server as your friend to send them a message, all Jabber servers can route messages to eachother. The same cannot be said for most IM networks that exist today. If I have an account with MSN, I cannot send a message to my friend on ICQ. Google Talk is an exception to this rule, in that they decided to adopt XMPP (Jabber) to base their IM system on.

The lack of interoperability alone makes other "Legacy" messaging systems problematic for end users, because obviously it means you either have to sign up for several different services to stay in contact with all your friends or you have to force/encourage your friends to switch to the one you prefer. Multi-protocol messaging software like Trillian and Pidgin have made the task of juggling several messaging services a little easier, by allowing you to access all of the different Legacy networks from within the one program, instead of having to run 3 or 4 different client applications. But why should we have to manage such an awkward array of accounts and configurations? The simple answer is that most of these legacy networks are add-ons to existing search/webmail portals. They grew out of the need to make their website/portal the central hub for everything, and interoperability with your competitors certainly wouldn't help you stay on top in such an environment. So they all made their own networks and their own protocols, and tried to tie them into their other services (or Operating System in one Monopolist's case) so that you would use their services because all your friends did.