Yesterday Google began rolling out video support for GMail. The support is in form of a browser plugin, which is currently available for Mac and Windows platform.

While it’s nice that GMail gets audio and video capabilities, having to download and install plugin voids the webapp benefts (available anywhere), and raises a question on why videochat wasn’t done as an upgrade to desktop Google GTalk client.

The devil is in the (protocol) details

What’s more problematic is the way Google decided to implement these features in the protocol. As GTalk is actually XMPP (with a couple of Google extensions), the good news is that Google continues using XMPP for the new features. The bad news is that Google completely ignored XMPP standard for voice and video (a.k.a Jingle RTP) sessions, and invented their own signalling.

To make matters worse, the way they decided to implement it is really screwed up. In a video call, there’s typically two media streams – one for video and one for audio (if you don’t want audio, you can set up just the video one). Google’s videochat also uses two streams – but, instead of signalling them as two jingle contents, they bundle all the information into one stream, and then have to do ugly hacks with transport candidate naming to distinguish between ports for each of those, and so on.)

All this can be worked around with, and while it will make everyone’s client into shpagetthi code for supporting such a twisted implementation, it can (and will) be solved. The real problem is that,they’ve decided on supporting only one codec, H.264/SVC that practically nobody uses (well, up until now), and that has no free implementations (apparently they’re using the codecs from Vidyo). They could’ve added additional support for any other codec (e.g. H.263, or Theora), that could be used when calling from/to non-gmail client) .. but they didn’t.

While they might have the best of intentions, this all looks very different from the “spirit of open communications” they’re mentioning. While it’s too late for them to change the signalling protocol, I hope they’ll be more sensible about the codecs, support more open (or at least more widely used) ones, and try to play nicer with the rest of us.

A few days ago (actually two weeks ago, but those were pretty hectic weeks) I attended Croatian Linux User’s Conference [DORS/CLUC'08], and gave a presentation about Telepathy there.

Although the slides are in Croatian [well, a few words, anyways, because I didn't force translations for untranslatable terms], there were some english-speaking people in the crowd so I presented in English (and was a bit anxious about it and rushed up a bit, but I think it came through fairly well in the end).

The talks were filmed so I hope there’s going to be a video available at some point, but in the meantime, you can check out the presentation slides (PDF here):

| View | Upload your own

Update: fixed the broken PDF version of the slides.

…is possible starting from today, because AOL seems to have implemented official XMPP<->AIM bridge!

I don’t have the link to the official anouncement (if there is any), and got the good news via Florian Jensen’s Weblog. It’s great to see XMPP getting more and more acknowledge as the de-facto standard IM protocol (today already 4 big “networks” use it – Jabber, GTalk, AIM and ICQ).

Of course, Telepathy users have already had the ability to connect to their AIM/ICQ accounts using great telepathy-haze which provides suppor for a host of protocols using Pidgin’s libpurple.

But, for this excercise, we’ll be using telepathy-gabble and the XMPP protocol. You’ll need a recent telepathy-gabble (0.7.2 is fresh from the oven, 0.7.1 should also work) and loudmouth (1.3.3 is the latest, 1.3.2 will probably work too). If you’re using Ubuntu Hardy Heron or Debian Unstable, you may already have the required packages available in your nearby repos.

The reason newer gabble is needed is because AOL XMPP doesn’t do old-style SSL (on port 5223), but TLS is required. Sadly, they don’t seem to have a valid certificate installed, so for now you’ll have to set ignore-ssl-errors flag (or, alternatively, not set require-encryption because it defaults to not ignoring ssl errors). Also, it seems their server are getting quite overloaded (or are still pretty buggy), so it might take several attempts to successfully establish connection. Also, from my experience, AOL really hates it if you try to reconnect too fast, so keep that in mind.

Params for the connection are:

• server: xmpp.oscar.aol.com
• port: 5222
• username: uin@aol.com (or your aim username, presumably)

Now we wait to see what MSN does. (If you don’t want to wait, there’s telepathy-butterfly and pymsn, and, of course, again telepathy-haze :)

Since my original Epiphany plugin hack, Empathy has matured and now sports new and improved version of Python bindings, including working bindings for Empathy-GTK, so we can reuse its widgets in other apps instead of reinventing half-assed ones.

So, I’ve updated the hack to work with the new bindings, and to use fancy Empathy’s ContactListView widget with contacts’ aliases, avatars and status messages, instead of plain ol’ boring JID list. I think it’s now usable (and pretty) enough to actually be used everyday, and not just an example of what could be done – so if you’ve got working Empathy setup already, give it a try! You can download the new version here: Empathy Link Share

Obligatory screenshot

Empathy and the bindings are still in heavy development, so it’s no surprise if some things don’t work as expected. If you get assertions like CRITICAL **: empathy_contact_list_get_members: assertion `EMPATHY_IS_CONTACT_LIST (list)' when you try to run the script although you are online, you might want to try and patch the bindings with this. Just go into empathy/python/pyempathygtk/ directory, patch it with patch -p0 < path_to_diff_file and rerun make and make install in the project directory.

Update: I’ve updated the extension to a newer version of Empathy (0.12+), you can read about it here.

There’s lots of exciting things going on in Telepathy and Empathy projects. Telepathy has been quite stable and usable for some time now, but since it’s really a backend service, it wasn’t very visible on the desktop, and the Empathy client (a fork of Gossip) is still mainly used as a standalone client.

Better way to use Empathy is actually to use the provided API and widgets and incorporate them into other applications and desktop components, so that the instant communication (both text-based and audio/video) really becomes a first-class object in GNOME and free desktops in general. There is some work already on the way – Soylent can use contact information provided by Telepathy to display information about the contacts, and there is a Google SoC project to enable Jokosher to use audio calls (using Telepathy) as Jokosher instruments.

Empathy provides a rich set of reusable components which can be used to easily incorporate im-related stuff into other application, and consists of two libraries, libempathy, which is the core API not dependant on GNOME or GTK+ (glib is required, though), and libempathy-gtk, a set of readily-available widget for things such as contact lists, account creation, chat windows, etc. Empathy is written in C, but one of the benefits of the Jokosher+Telepathy projects (which aims to reuse Empathy widgets) is that we now have Python bindings for Empathy! It’s a work in progress and some things are missing, but it is already usable.

To show how easy it is to integrate IM components into other application, and why it would be nice to do it in the first place, I’ve spent a couple of hours writing an Epiphany extension that allows the user to share the links on a web page with their IM contacts. Most of the time was spent figuring out how to make an Epiphany extension, and installing
the required Empathy libraries and bindings.

The result:

Hover over the interesting link and right click


Select one of your contacts


The contact gets the message with the link

The code for the extension is here. As you can see, the actual code for getting the contacts and initiating the chat is the smallest part of the extension :) The stuff is currently just a hack and needs to be cleaned up and properly packaged, which I do intend to do in the near future, by which time hopefully the pyempathy-gtk will be stable enough to sport real contact list chooser widgets instead of a hacked-up version I did here.

Update: I’ve confused Sabayon with Soylent. Thanks to cassidy for the correction