Tagged as: Experiment

Today I decided to look into how well XMPP gateways work. Here's how it went.

XMPP Gateways (or, alternately, Transports) are services for XMPP that let users sign on to other instant messaging networks (AIM, MSN, YMSG, etc.) through their XMPP account. So... you sign in to XMPP and the server signs you in to your other networks, and you can do all your chatting through just the one XMPP connection (Wikipedia has a nice diagram of this).

So I was wondering whether this would be a good solution for programming chatbots that work on many different IM networks. In Perl, the options for IM network connectivity aren't all that great at the moment; there is Net::OSCAR for AIM, Net::XMPP, and that's about it. Matt Austin and I were working on Net::IM::YMSG for Yahoo Messenger, but it's not that great yet (it can chat and accept add requests, but after accepting you don't see it online until the program restarts). For MSN Messenger, there's a dusty old MSN.pm module somewhere on the RiveScript forums that might still work but hasn't been updated in years.

I'm not very motivated to work more on Net::IM::YMSG because YMSG is dead to me. I created a new Yahoo ID recently, and made sure to opt-out of any directory listings, and it still gets add requests by spam bots on a regular basis. The ID is literally listed nowhere. I don't know how they find me. It is my opinion that nobody should take YMSG seriously anymore. I don't know anybody who uses it, so developing new code to use YMSG isn't worth my time.

With XMPP gateways though, one could just write an XMPP bot and let the gateways do all the work. Then you can have a bot sign on to AIM, Yahoo, MSN, ICQ, IRC, and even some obscure networks like MySpace IM, without needing to use native libraries for each protocol yourself. Sounds great, but I had some questions about how well gateways work (how many features they support per network, etc.)... so the best way to find out was to test it!

I installed the Openfire XMPP Server on my web server. Installation was surprisingly super easy. Basically all I had to do was this:

# apt-get install sun-java6-jre
# dpkg -i openfire_3.7.1_all.deb

This installed it and automatically started it, and then I went to the admin panel port on my server to set it up. I didn't have to touch any config files or anything; everything was done through the web panel and was dead simple. I set up a Jabber user @kirsle.net and then I went out in search of a gateway plugin.

I found Kraken to fill the role. Installing this plugin was super ridiculously simple too, I just copied kraken.jar to /usr/share/openfire/plugins and Openfire automatically saw it and extracted it and a new "Gateways" tab appeared in the web panel. Black magic. I later discovered that I could've just uploaded kraken.jar to a file upload field on the Plugins page on the web panel, too. This is, by far, the easiest server software for Linux that I've ever seen. I can't believe Openfire is free and open source.

So after setting the gateways up for the protocols that I care about, here is what I found:

• AIM and MSN support buddy icons, but Yahoo doesn't.
• AIM does not support AIM chat rooms or file transfers. Presumably this is the case for the other gateways as well.
• AIM profiles aren't supported. The gateway sets the AIM profile to "oscargateway".
• When my Yahoo gateway signed on, I got 5 add requests from spam bots. Denying these in Pidgin apparently didn't "stick", as the 5 requests came back the next time Yahoo signed on too.
• Chatting with AIM users over the gateway shows their screen names as "screenname@aim.kirsle.net". This is good. I haven't seen how MSN names are formatted though.
• The MSN gateway was a bit buggy. It doesn't sign on right away. It took many many minutes before it finally signed on. I didn't test it very thoroughly.
• I couldn't get my ICQ gateway to sign on. It said wrong password but I'm sure I had the correct one.

In short: it appears that only basic chatting and buddy list management is supported. For Yahoo (and presumably MSN), add requests from other users seem to come in just fine. Presumably you would be able to accept the add requests as well. Multi-user chat rooms and file transfers don't work. I haven't tested Attention/Buzz/Nudge features.

For simple chatbots that only need to communicate over IM, XMPP gateways should work out fine. But if you have a native way to connect to a particular network, that method would most surely be preferred.

The reason I like the @aim.kirsle.net etc. suffixes on gateway usernames is because it would make it easier for a chatbot to distinguish unique users across multiple networks. In my Aires bot (which supports AIM and YMSG, through Net::IM::YMSG), and in all my older bots from years gone by, the protocol-facing code would format a user's name like "AIM-kirsle" or "YMSG-kirsle" before passing it to the main bot code. This way I could make an AIM user an admin for my bot, without any confusion about overlapping Yahoo IDs of the same name. Since the XMPP transports make a unique subdomain for each network, this can be used instead.

In conclusion, I think it will be worth it to add XMPP support to my Aires bot so that transports can be used for people who want them. Native support for a network is always preferred, but with transports you can easily put your bot on a lot more networks with very little effort.

Update (Nov 17 09): The final version of Fedora 12 fares slightly better with GNOME Shell, but not by much. It also works just fine with Compiz Fusion within VirtualBox. Read more about it.

This is a sequel to my rant about GNOME Shell. I decided to back up my claims with an experiment.

Installing gnome-shell in a virtual machine with no 3D hardware acceleration.

Every single desktop environment that exists right now will run just fine in a virtual machine with no 3D hardware acceleration: XFCE 4.6 and older; KDE 4.3 and older; KDE 3.x and older; GNOME 2.26.3 and older; LXDE; and of course all of the desktop-less window managers (IceWM, et cetera).

GNOME 3.0, I claimed, with its GNOME Shell, will be the first desktop environment that will not run unless the user has 3D hardware acceleration, and that there is no fall-back. Here is the proof:

No Guest Additions; No 3D

I installed the Fedora 12 Alpha in a virtual machine with VirtualBox. Fedora 12 Alpha (11.92 Rawhide) is the latest development release of Fedora, and the Rawhide repository contains up-to-date packages for gnome-shell. So with this I don't have to worry about whether I just compiled gnome-shell in the wrong way; the Fedora dev team has built the RPMs here.

* Fedora 12 Alpha (11.92 Rawhide)
* VirtualBox 3.0.6 r52128 (2009-09-09)

Let's launch it!

And... what happens?

Basically, my screen is mostly black; I can't see any of my windows. I can see only a little bit of the GNOME Shell interface.

Let's put on the dumb end user hat and say Joe Average installed Ubuntu 10.10 which might come with GNOME 3.0 and GNOME Shell, he hasn't installed his nvidia drivers yet because they're proprietary and Canonical can't legally include them with Ubuntu, and he logs on and sees THIS. He's lucky that X11 didn't crash entirely and send him back to the login screen, but nonetheless he can't see anything. He can't see Firefox to start browsing the web trying to find a solution to this problem.

Okay, let's move on...

Guest Additions, No 3D

After installing the VirtualBox Guest Additions in the new virtual machine, but still not enabling 3D hardware acceleration, the results are...

Exactly the same.

I won't post screenshots because they look just like they did the last time. I get a mostly black, unusable desktop.

Of note however is that the terminal printed this upon starting the GNOME Shell:

OpenGL Warning: Failed to connect to host. Make
sure 3D acceleration is enabled for this VM.

VirtualBox knows GNOME Shell was requesting 3D support via OpenGL, and the guest additions driver gave me this warning. Let's move on...

Enabling 3D Acceleration

VirtualBox's 3D support is fairly new and still full of bugs. Actually their support for Linux guests is even more recent than the 3D support itself. I haven't tested running the ol' Compiz Fusion in VirtualBox, but I've heard that with the 3D support this becomes possible.

I've personally not used it. But it is known to be buggy; VirtualBox labels it as "experimental"... well, here's why:

In this experiment, even with 3D acceleration by the virtual machine, GNOME Shell is not usable. Again, though, VirtualBox's 3D acceleration is still in the "experimental" phase. It probably doesn't work a whole lot better with Compiz Fusion, either. Plus my video card might just suck (VirtualBox basically passes the guest's OpenGL calls directly to the host's video card).

But the thing to take away from this is:

• Desktops that work with basic video drivers:
  • GNOME 1.x series
  • GNOME 2.x series
  • Xfce 4.6 and older
  • KDE 3.x series and older
  • KDE 4.x series and older
  • LXDE
  • All window managers
• Desktops that don't work with basic video drivers at all:
  • GNOME 3.0 with GNOME Shell
  • (can you hear the crickets? yes, GNOME 3.0 stands alone, all by itself, in this category. sad. :( )

I rest my case.

Now let's see if the GNOME dev team can turn this around in the next year (doubtful; they all come off to me as a bunch of eye-candy-obsessed children who'd rather snazz up the desktop because they think it's "cool" than to worry about things like usability, functionality, or accessibility... and with absolutely no thought given to the user experience, and no usability studies done, etc.).

GNOME Shell for the lose.