blog

(Apparently, I copied stpeter's blog post title...)

A couple of weeks ago, Google introduced Wave, their new not-yet-a-product (to be unveiled later this year) that integrates chat, email, wikis, and the kitchen sink. Their demo video was very impressive, I must say – those guys know how to put together a demo, and they know their audience. Thumbs up on their Initech “client”. Here are some of my thoughts on Google Wave, from a technical/protocol stand point.

Open Source, Open Protocol

Google will be releasing their implementation under an open source license. Not only that, but their protocol will be open. That is probably the biggest thing about it. Google gets it. Near the end of the video, Lars says (paraphrased) that email is successful because the protocol is open, and anyone can communicate with anyone else. They want this to be the next email. No more MSN/ICQ/AIM/Skype/Yahoo! incompatible instant messaging networks. Jabber/XMPP attempted to take over the world of instant messaging by being an open protocol where everyone can run their own service, but despite gaining ground in internal communications in corporations, it hasn't seemed to have gained much ground in the public space (other than Google Talk, and to a lesser extent, Live Journal). Google Wave may be revolutionary enough to get people to switch. Maybe...

XMPP-based

And, on the topic of XMPP, the Wave protocol is based on XMPP, which means that a lot of the underlying framework is already there for Wave; there are many different XMPP servers out there already. How easy it will be to tack Wave on top of the servers remains to be seen. It may be (it probably is) as easy as writing an Wave component that communicates to every XMPP server via XEP-0114, or the newer (experimental) XEP-0225, which has the additional benefit that the Wave server could live on a different machine from the XMPP server. (Of course, then my Wave address would be [email protected] instead of [email protected])

Being based on XMPP makes you wonder how it will interact with other parts of XMPP. Will it completely replace instant messaging and conferences? (That seems to be one of the goals of Google Wave, but will it happen for real?) Will it replace pubsub? (I think that pubsub still works better in some situations than Wave, but then again, pubsub hasn't seemed to have caught on very much yet.)

Simple protocol

Looking briefly at the protocol itself, there is nothing terribly surprising to anyone who has thought about how to implement collaborative editing. However, they are combining multiple ideas together, which gives it power. There are a few key concepts that it uses. One server has to be the “authoritative” server, and none of the clients changes their internal state until it gets a confirmation from the server. Clients send change instructions to the server. The one key concept that was novel to me was that “wavelets” (sub-waves) could be owned by different servers than the master wave.

The protocol is also simple on the client end, and more complicated on the server end, which coincides with the Jabber philosophy.

One downside to the protocol is that each wave (and each wavelet) has a single point of failure – if the authoritative server goes down, then the wave(let) can't be edited. However, I believe that this is pretty much unavoidable for this type of functionality. (This might be a good research topic.)

Persistence

However, one related consequence is that each server is pretty much obligated to store history for every wave that it owns. In contrast with XMPP chats, where once a message is sent, a server can forget about it, a Wave server has to keep its copy around indefinitely. Again, this is probably unavoidable for this type of functionality.

Security

I haven't seen much in regards to security. For instance, there seems to be nothing to prevent wave-spam (other than XEP-0016, XEP-0159, and XEP-0161). Perhaps this was intentional, and they want to rely on the standard XMPP extensions (which would be a good thing). In my cursory glance at the protocol, I also did not notice anything about controlling access to your waves, such as allowing invitees to only read a wave, or to only add new sub-nodes, or to disallow sub-nodes. It could be that I just missed it, though.

Conclusion

With all this said, the protocol specification that they have published is just a draft, and their service is not publicly accessible yet (though apparently the lucky folks who were at Google IO got test accounts). It is definitely an interesting technology, and could have huge effects. But for now, we'll have to wait and see what happens.

Related links

Several blog posts from the XMPP community:

• stpeter
• ProcessOne
• Pedro Melo

Google Wave was announced on the same day as, and overshadowed, the Google Talk Gadgets API. It's not as sexy as Google Wave, but Moishe should still be congratulated on his effort.

I have created a new project, which I have dubbed “Talk-to-me”, which is a web-based instant messaging client designed for the sole purpose of enabling website visitors to, well, talk to me via my Jabber account. Well, not to me, per se. I'm not conceited enough to think that anyone would want to talk to me... But perhaps there are others out there who are.

In fact, the main reason that I wrote it was that it could be one half of a live chat system for companies. With a correct back end, it could be used to allow website visitors to chat with sales/support/etc. staff. Without going into too many details, the backend would be a double-headed bot, where the forward-facing end would talk to the web client, and the backward-facing end would ... do something, which would depend on how you want the system set up, to distribute the chat requests between staff. Probably the best way would be to use MUC somehow, so that multiple staff members could talk to the same client. But I won't go into much detail, because for one thing, there are so many ways to do it, and, for another thing, I'd much rather code it than to write about it.

(I've been (re-)reading The Chronicles of Narnia, and I think it's affected my writing style a bit. Well, as much as Lewis can affect your writing style when you're talking about coding...)

OK, this is very old news, but anyways... I have written a couple of Jabber bots. The first one is very simple system monitor, which basically allows me to keep an eye on my server(s) from my Jabber client. It is in the public domain (but depends on software that is GPLed).

The second is more interesting: a weather monitor. It gives me the current conditions of various cities, and I can ask it for the forecast. Currently, it just fetches the data from Yahoo! weather, but I'm hoping to add other weather services soon. This one is released under GPLv2 or later.

Apparently, both AOL/ICQ and Yahoo! have been doing some stuff with Jabber/XMPP. It seems that AOL has set up a test server so that you can log into AIM/ICQ with a Jabber client (Jabber Wiki instructions). It's just a small test server, so it may not work all the time (I haven't been able to log in yet), but it is a positive sign. Who knows? Maybe by next year, AOL will federate, meaning that AIM/ICQ users will be able to chat seamlessly with any Jabber user. That includes Google Talk, Live Journal, etc. That means that we'll be one step closer to having one single instant messaging network, instead of ... well, over 10.

The most common analogy people use is the email network. You can send an email from GMail, to Hotmail, or AOL, or Yahoo!, or any other network, without any problems (modulo spam filtering, etc.) But you can't chat from Google Talk, to MSN, or AIM, or ICQ, or YIM. If all the networks used Jabber and allowed federating, like Google does, then we would be able to chat between the networks.

AOL is, surprisingly, becoming more open to open standards recently. First, they're trying out OpenID (although it seems that ICQ accounts don't have an OpenID), and now Jabber. Or perhaps, it's not too surprising. AOL used to be the big boy on the Internet, but they're losing market share. Perhaps they're hoping that embracing open standards will help them regain some position. I hope that they do, so that they can set the example for others.

Yahoo! is also experimenting with Jabber, but in this case, they're just using it to power their chatrooms at their live.yahoo.com site. This means that they're much farther away from using Jabber for their instant messaging service. But it's still encouraging.

It makes sense to use an open protocol, rather than invent your own. There are many already-built tools that you can use, rather than having to write everything from scratch.

Yet another large player has decided to embrace Jabber. LiveJournal is integrating Jabber into their system (stpeter), which means that every LiveJournal user now has a Jabber account (although it’s still being tested). In addition to straight chat, it will also allow users to post new entries via Jabber, as well as to receive notifications of new posts via Jabber. It’s nice to see that they’re not only supporting Jabber, but also trying out new things with it.

LiveJournal also supports OpenID, an open identification system (so that you can sign into sites that support OpenID, you don’t have to fill in yet another registration form, or worry about your username being already taken). So if anyone is interested in starting a blog, I’d recommend LiveJournal over something like Blogger.

The LiveJournal folks have also implemented their own Jabber server, written in ... Perl?! It seems like a pretty neat system (despite the Perl) — everything is implemented as a module, which should make it pretty flexible.

This looks neat. (stpeter) Make phone calls using Jabber. It has decent rates too (0.022 USD/min, for Canadian numbers). Now, I’m just waiting for the Psi Jingle branch to be merged in.

(I’m hoping for an XMPP/SIP transport, too.)

Google has finally opened their Google Talk servers to support server-to-server connections. (ralphm, melo, stpeter, pgmillard, 3pBlog) This means that Google Talk users can talk to the rest of the Jabber world (which means I can now recommend Google Talk to people). Users of Google Talk can now add me to their roster: my Jabber ID is [email protected].

As a followup to my previous post about Jingle, Jingle (and Jingle audio) are now official JEPs (albeit experimental status) (stpeter, Hal Rottenberg) Psi has pledged to support it, although probably it won’t happen for a while. But I’m still looking forward to it. (IMHO, Psi is the best Jabber client out there.) And of course Google, being a co-author of the standard, is supporting it. Interestingly, Digium (the guys behind Asterisk telephony) also pledged support, which probably means we will be seeing a Jingle/IAX gateway at some point. Although I’m sure the Digium guys are more creative than me when it comes to figuring out what Jabber can do for Asterisk.

Update: (at 19:29 -0500) The Google Talk blog also mentions Jingle, and Google has released libjingle, their implementation that they use in Google Talk, and released under a BSD-style license. With libjingle released, this should help speed up Jingle support in Jabber components. (Now I’m just waiting for Google to support s2s communication in their servers.)

Update: (at 21:18 -0500) Apparently, there is now a development version of Psi that supports Jingle voice chat. It’s not yet stable, but it’s a start.

It looks like Jabber is finally getting (standardized) voice chat. (Hal Rottenberg) And it seems to be based on GTalk’s voice chat. (Thanks Google!) The JEP editor has announced two new submitted JEPs: Jingle Signaling and Jingle Audio, which are co-authored by Google staff. Hopefully, these will be implemented soon in the clients and servers, and someone implements a Jingle/SIP gateway.