Telepathy


11
Mar 09

Empathy, Telepathy, Farsight, … ?

In the Telepathy stack there are a lot of components, so often it gets very confusing for people hearing about it for the first time. So, here’s a very basic breakdown:

Telepathy
A framework for doing IM and VOIP. Supports Jabber/GTalk, SIP, IRC, MSN, ICQ,… (not all of those support VOIP at the moment). It has no UI and the end user doesn’t really need to be concerned about it.
Empathy
A IM/VOIP client for GNOME that is using the Telepathy framework.
Farsight
An extension to GStreamer that supports VOIP. (Farsight devs, mea culpa for this dumbing down so much). Farsight is used by Telepathy for actually moving around audio and video in calls.

That’s it. Easy, no? :-)


31
Jan 09

Retweeting IM status using Gwibber

What are you doing?

telepathy+gwibber

Microblogging is now much more (well, for some) than just answering the above question, but some people do want to publish what they’re doing at the moment. If they also use an IM client (and who isn’t?), it makes sense to make the IM status message and “what I’m doing” tweets the same.

As my technology of choice when it comes to IM is Telepathy, I started thinking about creating a connection manager (essentially, a protocol support driver) for Twitter, but then it dawned to me there’s much simpler and better way to do it, if you just want to retweet the status messages.

My preferred Twitter client is gwibber, written in Python, and it was very easy to extend it to listen to presence status change messages from Telepathy’s Mission Control and repost them to the configured microblogging services. Together with Davyd‘s work on improved status message widget for Empathy, I think this is going to be useful for people changing their presence often (and not using canned statuses).

To keep the requirements to the minimum (and since it’s a very simple client), I’ve used dbus-python directly, and also wrapped the whole thing so that patched gwibber continues to run even if there’s no dbus-python available. The big ugly chunk of the change in the diff is preferences.glade, where for some reason glade reindented a whole lot of lines that I never touched (another table row with a single checkbox is the only UI change).

The code is in bzr branch in Launchpad. Go, grab it and play with it! Keep in mind it’s fresh and not thoroughly tested. Also beware, ye rhythmbox (or other music player) users that update your IM status with every new song – this will spam your microblog if you let it :)

Does this mean I think Empathy should become microblogging client? Absolutely not. There’s more to microblogging than sharing statuses, and existing clients (e.g. gwibber) already do it very well. This patch is just a way to integrate previously disconnected parts of your digital life (ie. IM and microblogging). To publish your status (both on IM and Twitter), use Empathy. To microblog, use gwibber.


12
Nov 08

GMail VideoChat – the good, the bad and the ugly

2011 Update: Google came good on their promise and worked hard both on the signalling spec and the codec, so now there are multiple implementations that can interop with them. They’ve also just (June 2011) announced support for the finalised Jingle spec.

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.


30
Apr 08

Telepathy slides from DORS/CLUC ’08

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):

Update: fixed the broken PDF version of the slides.


18
Jan 08

Connecting to AIM/ICQ with telepathy-gabble

…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 :)