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

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

A sign of Jabber's increasing popularity?

Some of you reading this are regulars in the Jabber MUC at jabber@conference.jabber.org. This MUC is referenced on www.jabber.org, and is the default room to join in many clients.

Unfortunately the past weeks have included events that I can only say are reminiscent of IRC...

• Flooding


• Abusive language


• Spamming/advertising ("hey, check out this cool site! http://..." and leaving again)

Inevitably as Jabber gains good users it will also gain bad ones. While their activity in private chats is of little concern to us, I believe we need to lay down some guidelines for acceptable behaviour in the public conference.

Currently there are a handful of moderators keeping the MUC friendly. However it becomes hard to draw the line between what is acceptable and what is not. This is a matter of opinion that varies between most people.

My hope is that with some guidelines it will be easier for both the moderator and the user (who can then be directed to them if necessary).

The need for these moves is somewhat disappointing, but necessary it seems, if we are to keep the friendly atmosphere that we currently have in this little corner of the Jabber community :) and to continue providing useful help to Jabber newcomers.

Swearing
I propose the same policy as the official Ubuntu support channels, which works well. Mild swearing is ok, as long as it is not excessive, or directed at a person. Anything else may result in a warning and/or kick at the moderator's discretion.

No deliberate flooding
Though I am not aware of it happening in the Jabber MUC, it has happened in another MUC I am in. A user joined 2 bots into the room, and set them into a loop with each other, and left. Obviously this is deliberate, and I had to ban all 3 JIDs involved (but not until several hundred messages had already been sent to the room).

In IRC it is frequent to get shouted at for pasting more than a couple of lines. In Jabber people seem to be more lenient, and I don't see why this should change. Obviously a warning should be given when needed.

English only
It may seem unfair to prevent people from speaking in their native language. However most languages have their own servers and their own conferences. I don't propose this rule to affect those casual users who come in search of help, yet speak no or little English. Those users are usually directed in a friendly way to a room and server of their native language, where they will hopefully receive better help.

However some users hold long conversations which could easily be taken into private messages, or to other rooms. These conversations are nearly always unrelated to Jabber, and only annoy the other occupants of the room. It also makes it impossible for moderators to moderate when the conversation is in a language they don't know (I have previously been asked to kick people who were being insulting toward other users, although I had no idea because they were not speaking in English).




Obviously these choices are not up to me alone to make, and so I welcome comments and opinions on what I suggest here.


Update: It seems this post caused something of a discussion... :)

The AACS Saga

It is unlikely that many missed this one. At one point it was even responsible for the news site Digg going offline...

It started when details of a crack for scrambled HD-DVDs was posted on the internet. This crack involved a (supposed to be) secret key used to decode the DRM-enabled DVDs. It caused quite a storm, and spread across the internet, mainly through blogs. Bloggers excercising their right to free speech posted the key. Obviously it was not long before the story got 'Dugg'. However after the AACS-LA announced that it was prepared to take legal action against those publishing the key, Digg began censoring stories linking to the number.

Disgruntled Digg users rebelled, and began mass-posting stories about the crack to the site. The whole issue has become something of an internet phenomenon, and the key can be found from T-Shirts to well, anywhere! In the end forcing Digg to side with its users, saying they had made their wish clear.

Though the AACS-LA's threats have stirred up internet users worldwide, and only served to publicise the key more than ever before, a more important story may have been forgotten. There exists a crack published a while ago that can not be revoked the way this infamous key has been. A much deeper flaw exists in the copy protection method itself. Perhaps HD-DVD and the video industry in general will go the same way as the music industry, which is now shifting away from DRM.