XMPP software documentation

In an attempt to dust off my neglected blog, I bring you the following post about something that has been nagging at me for the past couple of days.

Since the recent changes at jabber.org I've been thinking a lot about Jabber from a new user's perspective.

The new web-based registration form may help clear up a lot of confusion that resulted from in-band registration (many users were looking for somewhere on the website to register), but after registration what do they do next?

They no longer need a client to register, and it is now quite likely that after registration they won't yet have one, so obviously most importanly we need to guide them to find a client.

We could simply direct them to the XMPP client list on xmpp.org, however that isn't particularly friendly for someone who might not even be familiar with the term "client".

What we need is a shortlist of some user-friendly clients, with good documentation.

And this set me thinking that perhaps there ought to be a concerted effort to document the basics of XMPP clients (in fact any and all XMPP software) in a unified way.

For each client I would like to see a set of simple single-page tutorials, complete with screenshots, on issues such as:

• How to register an account


• How to add an existing account


• How to add a contact


• How to join a MUC


• How to send/receive files

Where the pages would be hosted (in one place, or on the respective client sites) as well as some other things still need thinking about, but I'd like to know what other people think about the basic idea before setting anything in stone. Thoughts?

irssi notifications over Jabber (or IRC barking)

Thanks to daubers (the brains behind the XMPP doorbell) who suggested it, I now have irssi highlights sent directly to my Jabber client. Quite a handy thing since only yesterday I logged in to find several PMs awaiting me from 4 days ago.

For the base I used an existing irssi script called fnotify, which was designed to write notifications to a file. I found this script from Aaron Toponce's blog post.

mkdir -p ~/.irssi/scripts/autorun
cd ~/.irssi/scripts
wget http://www.leemhuis.info/files/fnotify/fnotify -O fnotify.pl
chmod +x fnotify.pl
ln -s ../fnotify.pl autorun/fnotify.pl
nano fnotify.pl

Change line 56 (which reads something like open(FILE, ...)) to:

open(FILE,"| sendxmpp -i me\@example.com");

Replace the JID with your own, and make sure to put a \backslash before the @ sign as above.

sudo apt-get install sendxmpp

When it is installed, tell sendxmpp what account to use for sending messages:

echo me@example.com verysecret123 > ~/.sendxmpprc
chmod 0600 ~/.sendxmpprc

Replace with your JID and password of course ;)

Now, in irssi:

/win 1
/run fnotify.pl

(switching to window 1 is necessary to see any error messages if they appear)

If it loads successfully, get someone to say your nick or send you a private message. It should appear in your Jabber client within a few seconds.

A consequence of this for me is that IRC now barks too :)

IM Barking

Over the weekend my brother found an old toy of his... a "robotic" dog. It has two functions, walking and "barking" (where bark is more of a squeak). Unfortunately the controller for these said functions had been put beyond practical repair by leaked batteries. I cut the controller off and wondered what uses I could put the thing to. A solution looking for a problem.

People often complain that I don't respond to their Jabber messages, often this is because I simply didn't notice it, or wasn't at my computer. I do have speakers, but I either have music playing, or when not, they are turned down to 0. Problem found.

To replace the dog's original controller I used a USB interface board. It wasn't long before I knocked together a quick Lua script to use the board and make it bark on demand.

With thanks to vArDo (Mateusz Biliński, working to add a plugin system to Gajim for GSoC 2008) for the D-BUS notification handler script, I managed to link up new message arrivals to the barking. The result? See for yourself:

Open Discussion Day 2008

Open Discussion Day (19th May) is very nearly upon us!

However due to various reasons, we did not manage to get the new site online until very late. This means there is still plenty of work to do.

If you have something to suggest, or want to offer a hand at short notice, join opendiscussion@conference.jaim.at, or #opendiscussion on Freenode!

We are keen to know what *you* are planning to do for open protocols this 19th May :)

Jabber Abuse Handling

No blog post since... when? Never mind :)

Something that interests me became a hot topic in the Jabber community (specifically server administrators). We had a meeting at fairly short notice about possible solutions to the problems we know are around the corner.

The following are some *quick* rough notes I made (too early in the morning) of an abuse reporting method, very much along the lines of XEP-0161: SPIM Reporting and XEP-0236: Abuse Reporting. What I have in mind is something of a mixture between the two. Not all abuse is SPIM, so XEP-0161 should probably be a little more generic (as XEP-0236 is).

I haven't thought much about the below, but I believe the general concept is not that far from usable, and doesn't disrupt too much the distributed nature of XMPP.


End-user
It is nearly always going to be the end user who originates abuse reports. Whether they received spam to their JID, or experienced flooding in a MUC room they administrate.

The abuse report should be sent to the abuser's home server.

Abuser's server
Upon receiving an abuse report, the server may choose to act immediately, or wait and gather more evidence (possibly from sources it deems more reliable).

It is important that the server relates reports it receives to IP addresses when weighing the evidence, *not* JIDs, since obviously the same user may have created multiple accounts).

Upon receiving satisfactory evidence that a certain IP is abusing the service, the server may decide what action(s) to take.

Clearly the most obvious step is to ban the IP from the server, and lock associated (reported[1]) accounts.

The other (optional) step is to report the IP of the offender to a central reporting/blacklist service (ie. abuse.xmpp.net), to help aid other servers who wish to prevent similar abuse of their own service.

[1] Only reported accounts should be locked, since legitimate users behind the same NAT router as an abuser could otherwise be (overly) punished. Unfortunately there is no way to avoid that legitimate users are sometimes going to get caught up in the net.

Clearly blocking an IP is not the ideal solution. A new IP is not usually hard to come by. Each reported IP should be investigated, and network administrators notified of the abuse to reduce the chance that it will happen again.

Dates and times are very important. In the case of dynamic IPs, it is the only way to track down the offending user. Perhaps it would be useful to report more than one IP + time and date (ie. the last X IPs that used the account), for this purpose.


Apologies for the unpolished post. Time to sleep on this :)

GNOME 2.20 released

...and it looks like I will be sticking with GNOME for another 6 months after all!

Even the most annoying thing about Epiphany seems to be fixed - the address bar. Also I no longer have to sync my Tomboy notes with an automated SVN commit. I'm close to forgiving it for being written in C#...

Do read!

Summer of Code final update

As of 20th August Google's Summer of Code program has officially ended. Students must upload code produced up until the deadline to Google's hosting, and are only judged on work up to that date.

Continuation of GSoC projects is encouraged however, and I shall be finishing off HTTPS (and have already committed bug fixes) and tidying parts of my code over the next few weeks.

There has been plenty of interest in my summer's work, on the gloox mailing list, and in private emails/IMs to me personally. It is great to know that people are finding my work useful to them.

I would like to thank Jakob my mentor for endless help with figuring things out when they went wrong, and for guiding me around the innards of gloox when I got lost (not to mention for his excellent library existing in the first place!). Thanks to Peter for taking on the hard task of orchestrating the XSF's involvement in GSoC, and for supporting the students throughout. Finally thanks to Google and the team behind the administration of GSoC, for, well, you know what :)

I will update this post with the URL to my uploaded tarball once it is on Google's servers.

However the latest, greatest code will always be found in SVN. Currently BOSH is at svn://svn.camaya.net/gloox/branches/work/mw/bosh but very soon will be moved to the trunk. More information on gloox's download page.

The server-side implementations that I know work with this code are Openfire 3.3.2 (or .3), and Araneo (a standalone CM (connection manager), which allows any BOSH client to connect to any standard Jabber/XMPP server, using the CM as a kind of proxy) from ff.bluendo.com (site down at the moment I write this).

PS. Apologies for the delay in this post... blame my vacation :)

Update: Official tarball uploaded here. Please use the version from SVN (see above) though if you would like to test or use my code.