Tuesday, March 25th, 2008

Do you want your browser to Jabber away?

Category: Browsers

Yesterday Rey posted about an ExtJS based Jabber client.

I had just earlier posted about whether you would want Jabber to be built into the browser, and will repost below:

Old Men Talking

Aaron Boodman was probably right in thinking that me wanting OpenID in the browser makes more sense as a browser feature, or separate plugin. This is a consumer level feature more than a developer focused one.

As I ruminate in the world of wishful thinking, I started to wonder about Jabber, and how it would be interesting to have XMPP as a native browser protocol.

We do have Jabber plugins, and there are JavaScript libraries that implement Jabber, but shouldn’t this be in the browser?

Jabber seems to be popping up all over the place. It started off as the IM protocol, and now has become a generic, scalable, messaging system. If XMPP was native and reliably in browsers, imagine how it could help the chat in Gmail? It could also transform the chat relationship with the Web. Social browsing as Me.dium does it could become more integrated. For example, I could have a trivial way to enable group chat on Ajaxian. I would love to be on the site and have others who are on there tell me how things are going, give me tips, and have comments feed into the same system. I shouldn’t have said “enable” as I wouldn’t have anything to do with it.

At an API level, we could also access XMPP from JavaScript.

Hmm, actually, is there a way in which this could tie into single sign-on and OpenID? Could XMPP be the way to login?

Posted by Dion Almaer at 7:11 am

3.7 rating from 17 votes


Comments feed TrackBack URI

Let me sum my comment on your blog… :)

On the last XMPP (Jabber) Development Conference in February, a small working group was formed to create a Jabber API for web applications, primarily for JavaScript.

Our basic examples are currently a turn-based board game, a whiteboarding session, an activity which would provide some realtime channel and an invitation mechanism.

Current examples of such technologies are SamePlace (which author of is participating with us), and Meebo Platform. For the record, both are jabber-based.

The initiative is in a very early stage. We appreciate every help, especially from JavaScript developers. You can subscribe to our list at:


Personally I believe that what you may like to have is achievable with such an API, and the IM client and the web browser shouldn’t be necessarily the same application, althought they certainly need integration.

If anyone wants to ask questions about the initiative, you’re free to subscribe to the list, or contact me directly via aadaam at googlesmailservice via XMPP/Jabber.

Hope that a lot of you’ll be interested and just excited about the possibilities of integration between IM and the browser as we are :)

Comment by Adam Nemeth — March 25, 2008

I am not sure if having XMPP protocol features in the browser is good or bad, what I do know however (which kind of probably is an answer I assume) is that having business logic in JavaScript on the client as a general rule is bad. And by having Jabber protocol access in the browser we’re doing something which leads to far more business logic in the browsers. To have XMPP support on the server and using XMPP on the server to access Jabber servers is 100 times easier and more scalable and can take advantage of things the browser can only dream about. And the protocol to communicate the “jabber results” back to the browsers we already have and it’s called – XMLHTTPRequest and is BTW currently being standardized by W3C…
Remember the first rule of standardizations. One is good, two is virtually the same as having none. And the “overlap” between XMPP protocol and XMLHTTPRequest is so huge that it would basically mean having two… (which again leads to “none”)
Just my 2cents…

Comment by polterguy — March 25, 2008

Hi polterguy,

The importance of javascript and ajax nowadays is about storing some kind of logic on the client side as I believe, as this made creating of cross-platform, even further, cross-environment (think of OpenSocial) applications possible.

Today, XMPP has more than 200 extension protocols standardized, but only a few of them are actually implemented, therefore interoperability between clients is usually limited. That’s why I strongly believe in code-on-demand technologies [Fielding, 2000] like JavaScript. This makes interoperability a lot more easier for everyone.

Compared to XMLHttpRequest, XMPP is about peer-to-peer bidirectional communication, rather than communicating requests to a server from client side. It’s not about two standards instead of one, it’s about integration of two already deployed standards for solving a common set of problems. Both are about communication, but I don’t feel they’re on the same field.

I hope this makes my point a little bit more clear

Comment by Adam Nemeth — March 25, 2008

I’d just settle for better scripted networking support in general such that writing clients for Jabber (and other protocols) is simpler and less error-prone. Biting off the entire jabber spec (plus N number of XEPs to get something actually usable) but having it behind the “browser wall” is just asking for years of incompatibility while we wait for another set of omnibus browser revisions which conjoin protocol support with renderer support with scripting support (etc, etc.).


Comment by slightlyoff — March 25, 2008

For the record:

Peter Saint-Andre, executive director of XMPP Standards Foundation just introduced another mailing list, now about social applications and Jabber:


Seems that a lot of interests there is overlapping with the API list, such kind of folks like Aza Raskin from Mozilla Labs, and Charles Forman from iminlikewithyou.com ( a social gaming site using XMPP for real-time communication between game clients) showed interests on the list.

(Sorry for the “spamming”, it just seems it’s a current topic and there are two lists for two sides of the problem it seems now :)

Comment by Adam Nemeth — March 25, 2008

Leave a comment

You must be logged in to post a comment.