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