It’s all the rage these days to shorten URLs with fancy URL shortening services. Heck, even I have one. They are certainly nice to have, when links are exceptionally long, such as search result URLs, and just the mere wrapping from one line to the next breaks the URL (not to mention, any additional characters added in the line break, such as spaces, other characters, etc.). I’ve used, and still use, link shortening services for IM, IRC, email, Identi.ca, Twitter, etc., only when I suspect the link could break as a result of line wrapping. I use them sparingly, and only use them if they provide a preview feature, giving the link to the preview.

While they have their advantages, they certainly come with a cost. Link rot is a very real concern, should the link shortening service go offline. You can nest shortened links in each other, concealing JavaScript/CSS mouse hovers. They can contain all sorts of nasties, and you don’t know what you’re getting into, unless you use some sort of software to expand the URL for you, before you actually follow the link. I’ve already blogged about using a simple shell function to expand shortened URLs (post at http://pthree.org/2011/10/18/use-wget1-to-expand-shortened-urls/). Well, now it’s time for Irssi to automatically provide the function for me.

Presenting https://github.com/jcande/Expand-URLs. This is a simple Irssi script that will identify URLs in a given notice, whether in private or in public, and expand them using the http://longurl.org service (I think a patch for doing the lookup without a 3rd party should probably be submitted, as any 3rd party expanding service might go offline).

For me, this script is exceptionally valuable, because I connect to a local Bitlbee instance with Irssi, and use Bitlbee to connect to Twitter. Unfortunately, Twitter wants to track your clicks with their http://t.co service. Every link longer than 19 characters (20 for HTTPS) submitted to Twitter is automatically shortened with this wrapper. They claim that the service is to identify malicious links, and prevent them from being posted, should one be identified. But certainly, a company the size of Twitter can do so much more with this new “service”. They could track what links are clicked and when. They can use this information to identify what stuff you’re interested in, and when you use the service. They can track who clicks the link by IP or ISP. Of course, it would be foolish to not sell this information to advertisers, to target additional advertising on Twitter or other sites, based on this info.

At any event, this is one of the few Irssi scripts that I find really, really useful for day-to-day. It makes the Twitter timeline a bit chatty, now that lengthy URLs are being shown, and a few break due to line wrapping. And that is a pain, no doubt. But, the vast majority of links don’t break, and it’s nice seeing where I’ll be taken when visiting the link. Keeping Twitter from tracking me, despite the occasional link breakage, is worth it.

P.S.: There is also a WeeChat script at http://www.weechat.org/files/scripts/expand_url.pl.

At any event, here is the configuration for the theme:

Obviously, this won’t look that great on a terminal with a white background (or really any color other than black). And here is the screenshot:

As you can clearly see, the active window you’re under is bold white with red parentheses around the window name. The previous window you were in is marked with a dash ‘-’ (by default). An alert in a terminal will change the text to bold yellow, so long as you’re not in that window (as you can see with the “mutt” window). It ties in nicely with the 88_madcows.theme file for Irssi, and the ZSH theme I built.

I’m new to building Tmux hardstatus lines, so if there is something I should be doing differently, let me know.

Aliases
I’ve only added two aliases to Irssi since we’ve last met. The first alias comes from the main Irssi.org website. If you scroll to the bottom of the page, there is a tip close to the end for adding all open channels to your “/channel list”. The only thing it was missing was saving the window layout to the config, so next time you open your Irssi, not only will you be rejoined to all of your channels, but they’ll all be in the same place they were last time. Here’s the alias:

/alias CHANNADD script exec foreach my \$channel (Irssi::channels()) { Irssi::command(“channel add -auto \$channel->{name} \$channel->{server}->{tag} \$channel->{key}”)\;}; layout save; save

This next alias will effectively “mark all as read” for your channels. For whatever reason, you may like to have a clean slate for channel activity in your statusbar, rather than all the channels showing some form of activity. This alias will clean up your statusbar, so any new activity becomes immediately available. As mentioned, think of this as “marking all channels as read”:

/alias READ script exec \$_->activity(0) for Irssi::windows

Scripts
My scripts have changed a little bit, but not by much. Really, there’s only two scripts worth mentioning about that I haven’t already done so in the previous post.

The first script is similar to “screen_away.pl“, except for tmux(1). I’ve adopted nesting Irssi behind tmux(1) instead of screen(1) because I just couldn’t get bolded black and white to work correctly. Now, everything looks as it should, with zero formatting issues. At any event, “tmux_away.pl” does the same thing, in that it sets your “/away” status when you detach your session, and resets it when you reattach.

The second script is “trigger.pl“. This script is mostly a search/replace script for events that happen in the channel. For example, if you don’t like the “F-word”, you can change it to something less vulgar with trigger.pl. It can handle much more, but I only use it mainly for that purpose. The triggers I’ve set up this far are as follows:

-publics -regexp ‘Message from unknown participant ‘ -replace ”
-all -nocase -regexp ‘</?(a|b|body|div|em|font|i|s|u)( +\w+=”.*?”)*>’ -replace ”
-privmsgs -nocase -regexp ‘&amp;’ -replace ‘&’
-privmsgs -nocase -regexp ‘&gt;’ -replace ‘>’
-privmsgs -nocase -regexp ‘&lt;’ -replace ‘<'
-privmsgs -nocase -regexp '&quot;' -replace '"'
-publics -masks 'update!update@identi.ca' -channels '&bitlbee' -regexp '^aaron: ' -replace ''

All of my triggers are Bitlbee triggers. Let’s cover each trigger that I’ve created, just so there’s no confusion:

1. When joining Jabber MUCs with Bitlbee, the Jabber server you’re connecting to can be configured to print the past 20 lines (or whatever) of the previous log, so you can get caught up to speed on the discussion quickly. However, if the user that said something in that log is not in the MUC when you join, you’ll see “Message from unknown participant” in the backlog. This trigger removes that completely.
2. When Pidgin or Adium users get online, sometimes the clients send HTML/XML to Bitlbee. THis trigger strips the HTML/XML tags as listed completely.
3. Similar to trigger #2, this trigger replaces the HTML “&amp;” with “&”;
4. Similar to trigger #2, this trigger replaces the HTML “&gt;” with “>”;
5. Similar to trigger #2, this trigger replaces the HTML “&lt;” with “<";
6. Similar to trigger #2, this trigger replaces the HTML “&quot;” with ‘”‘;
7. I use Identi.ca with the XMPP bot in the “&bitlbee” channel. I know the bot is addressing everything to me, so I don’t want to see each notice begin with “aaron: “, so I’ve stripped that out completely, so the notice actually starts with the user nickname. If you’re interfacing with the bot in a private channel, rather than in “&bitlbee”, then this trigger won’t do much good for you. You’ll need to modify it.

Theme
As much as I try to do a new theme, I always come back to my custom-built “madcow.theme” called “88_madcows.theme“. It’s the awesome. Screenshot

First off, before beginning, make sure you have the latest version of Bitlbee. The options I’ll be going through in this tutorial require version 1.2.8 or later. If you don’t have at least this version, this tutorial might not work for you completely. Twitter support was added in 1.2.6, but getting it to work with Identica might not work. I’ll outline both Twitter and Identica, as they have different setup requirements.

Twitter support
Twitter no longer supports the username/password combination to authenticate your client with the service. Instead, they use OAuth for the authentication. Bitlbee supports Twitter’s OAuth. So, when asked to provide a password with the account, just give something totally bogus. Your password won’t actually be used. So, in your Bitlbee root window, type the following, replacing “username” with your actual Twitter account username. Also, make sure to replace the account number with the appropriate number from “account list”. I’ll assume it’s “1″.

account add twitter username bogus_password
account list
account set 1/mode chat
save
account 1 on

Notice, I set the mode to “chat”. This makes the Twitter account behave like a standard multi-user chat room. As a result, Bitlbee will create a new room in your IRC client, and add all account that you are following to that room. The great thing with this, is you have full nickname tab completion if your IRC client supports tab-completing nicks. No need to use Twirssi, tweet.im, or other services/plugins if you’re already using Bitlbee. Personally, I dig it. However, the mode also supports “one”, meaning you have a nickname that you must interface with to send all tweets through (like an IM bot) or “many”, in which every account you follow will have its own “buddy” in your buddy list, that you could send messages to directly. Personally, I like chat best. Play with whatever works for you.

Identica support
I’m told that the BZR branch of Bitlbee (current stable version is 1.2.8, development 1.3) supports Identica natively. However, I only have 1.2.8 installed, so we get to hack up a solution (a rather elegant one at that). The Status.net developers pride themselves in keeping the API 100% backwards compatible with the Twitter API. This means that even though Bitlbee doesn’t have native Identica support, it does support it indirectly through the Twitter API. So, we’ll make a slight change, and we’ll be good to go.

A couple notes on this method that is worth mentioning. Identica doesn’t support OAuth. As such, you do need to setup your actual username and password. Unfortunately, this is sent over the Internet in PLAIN TEXT. If you’re at all concerned about the security of your Identica account, I would recommend interfacing with the Jabber bot, as it uses SSL for its connection, and your username and password are actually never sent. However, with the Jabber bot, you don’t have nickname account tab completion, and you do if you setup Identica the same way we just setup Twitter.

So, weigh out your options. Personally, with me, I prefer using the Jabber bot and using trigger.pl to do some light text munging fore me to make it rather slick. Not only for the SSL support, but also because I really like the “reply #[message_id]” feature of the Jabber bot, and you lose the ability to send a reply to a specific message with this method.

With that said, let’s see how to set it up. In your main Bitlbee root window (remember, you must use your Identica username and actual password here as OAuth isn’t supported), type:

account add twitter username password
account list
account set 2/mode chat
account set 2/oauth false
account set 2/base_url http://identi.ca/api
save
account on 2

I assumed that setting up Twitter was account “1″, so I’m assuming setting up Identica will be account “2″. Replace as needed for your instance. Also, notice that we also set the mode to chat, just like we did with Twitter. However, we changed the OAuth mode to false, because Identica doesn’t support it, and we changed the “base_url” to “http://identi.ca/api”. This is needed, so you’re not sending your messages to Twitter, obviously.

With both Twitter and Identica (or either one), you should have chat windows where you can interface with the service directly using the API. The great thing here is full nickname account tab completion, and the chat window looks great, because it’s using your IRC native theme and controls, rather than setting up some weird theme (I’m looking at you Twirssi).

If Bitlbee is running in Irssi, as is the case for me (just search for Irssi on my blog ), then this make Irssi a full-blows messaging suite with some pretty extensive scripts that make your IM/IRC/microblogging very versatile, flexible and complete. For me this takes Irssi + Bitlbee to a whole new level. World domination is nearly complete with messaging. Jabber, Facebook (which is really Jabber), Twitter, Identica, IRC all in a single client.

Yeah. I’m happy.

First, so you understand, Open Discussion Day started back 4 years ago when Ploum first blogged about showing support for open protocols, such as Jabber/XMPP (using Google Talk, jabber.org, and others). I’ve blogged about it in the past, even though I missed blogging about it last year.

You can start with by checking out the page http://www.opendiscussionday.org. There, you’ll find a wiki that has some information on how to get started with open communication platforms, protocols and software. Given the ways we communicate with each other on the Internet and elsewhere, it makes sense to advocate supporting these open platforms. Here’s a brief, non-exhaustive list of various open protocols worth checking out:

• Jabber/XMPP- Jabber/XMPP is probably the most successful open communication platform to date. According to Wikipedia, it has more than 50 million active users, mostly on the Google Talk/Gmail service. It’s supported on Windows, Mac and Linux. It’s a federated protocol, which means Jabber/XMPP can communicate across different domains. It uses SSL encryption by default, which means your communication is secure, and most of the clients are free, and solid applications.
• OMB- The Open MicroBlogging protocol was started in response to Twitter. Rather than being tied to a particular vendor for your status updates, Laconi.ca, now Status.net, launched and announced they would provide an open, federated, protocol for broadcasting your “tweets”, following others, and others following you. Identi.ca was their product, and it has proven to be very successful, and the open platform has sparked a number of other microblogging servers, all in tight communication. http://army.twit.tv, http://brainbird.net, and others are based on this code, and can all communicate together. Lastly, there are a number of microblogging applications that support Identi.ca, and the others. You can follow me at http://identi.ca/eightyeight.
• IRC- Internet Relay Chat is one of the older forms of open communication in this list, except for email. It uses TCP for the transport protocol, and optionally SSL/TLS for encrypting your communication. As with everything else is this list, IRC is federated, meaning connecting multiple IRC servers together, and communicating transparently. Freenode is probably one of the more common IRC servers for open source projects. OFTC, EFNet and UnderNet are popular as well. There are many IRC clients out there that can get you chatting on any number of different IRC networks at the same time. My personal favorite is Irssi, a text-based client.
• Email- The last, but definitely not least, however the oldest, and probably most ubiquitous. Everyone is familiar with email, and it’s rare to find people these days that don’t have an email address. It too is federated, meaning you can send an email from gmail.com to hotmail.com, without thinking about it. Many open protocols have been built around email, including SMTP, IMAP and POP, as well as their secure, encrypted versions. As much as the Internet would like to see email die, I personally think it will be around for quite some time. The only thing I would ask, is that people stop sending proprietary attachments to their message, bottom post, trim unnecessary cruft from the mail, and write in plain text (I think I might be reversing my stance on HTML email- we’ll see).

Of course, there are many closed discussion platforms and protocols, such as Twitter, Facebook, Skype and MSN/AIM/ICQ/Yahoo. It’s important to note that you don’t own your data on these services, unlike the ones I’ve mentioned above. You are subject to vendor lockin, and everyone else must use those services too, as they don’t communicate with each other. But, we’re about the open discussion protocols, not the closed ones, so let’s continue.

I’m sure there are many other open communication platforms that would be worthy discussing in this post. I chose what I feel to be the biggest and most successful of the open protocols. The future will tell what else we see in this arena, but right now all I can say, is we have a great deal of options for supporting an open protocol, many of which are doing very, very well. If you have other open communication protocols that you use, make sure you specify them in the comments, or add them to the Open Discussion Day wiki. For the record, I fully support all the open protocols/communication platforms, and you can find me on any of the protocols listed above.

Happy Open Discussion Day, 2010!

First, my ZSH prompt was already developed from the outset with that in mind. So, no additional hacking has been needed on that. There are some elements that I’m not too terribly excited about. I don’t care for the dark blue directories on a black background, and I don’t care for the yellow character devices on a white background. Using the Tango scheme for gnome-terminal makes both of those scenarios much more tolerable. However, I do have additional items that I want to put in my prompt, but that will be for a later post. Also, my GNU Screen hardstatus line also needed to be compatible. This wasn’t that big of a deal, as I only needed to apply some colors to a few elements. Hhere’s a couple screenshots showing both black and white backgrounds, and how the ZSH prompt inside looks in each. Note the GNU Screen hardstatus line is at the bottom of the terminal.

From Desktop Screenshots

From Desktop Screenshots

Second, my Irssi theme also needed to work well with both. As I’ve already blogged before, I was really, really impressed with the madcows theme. However, I didn’t care for a few elements, so I started hacking it, making my own changes. I’ve tried keeping the true nature of the theme, while still adding my own style. The theme was already largely compatible with my ZSH prompt colors, it just needed some adjustments here and there, before I was totally satisfied. Further, it looked like crap using a white background, so this needed some hacking as well. I think I’m overall happy with the result, although I’m sure I’ve missed many things (like DCC, or CTCP), so there’s likely much more hacking to go before it’s perfect. However, for the general day-to-day chat, it’s 95% there. Screenshots for both backgrounds below:

From Desktop Screenshots

From Desktop Screenshots

In a nutshell, the themes are compatible with xterm-color support on most terminals. Mainly, I’m using bold and normal weights on red, green, yellow, black, white and blue. Anything else takes the default color of the terminal itself, whether it be the foreground text or the background. So, as long as your TERM variable is set to “xterm-color” or something better, you should be okay.

This post wouldn’t be complete without the source for you to try it out. Here’s a compressed tarball for giving it a shot, and reporting anything you find in the comments, if you like.

Cheers!

Hanging out in the amount of channels I do, I see a lot of activity in my statusbar for all of my joined channels. This can be overwhelming for some, but I don’t mind it. What I do mind, however, is when I check in on a specific channel, and see pages and pages of scrollback that is nothing more than people joining and leaving the channel. I’ve tried blatantly ignoring JOINS, PARTS and QUITS, as they’re called, but I always disable it, because I usually want to be kept abreast of when someone leaves a channel that I’m having a conversation with. I don’t want to look silly continuing to chat to someone, long after they’ve left. So, I need a way to keep on top of when people are joining and leaving the channel, but not have that information in the channel itself. Thankfully, Irssi meets this need.

The concept is simple. A JOIN, PART or QUIT is what is referred to as a “level”. There are a number of different levels that Irssi supports, all of which can be found with “/help levels” in Irssi. With Irssi, it is possible to ignore, or even redirect, levels. In my case, I want to redirect these three levels to another window, if possible. So, digging through the settings in Irssi, I found “window_check_level_first”. By default, this setting is “OFF”, which means that Irssi has a global setting for levels, and how they’re handled. Enabling this setting, means to follow the levels that have been assigned to their respective channels. However, if you turn this on first, without doing some initial setup before hand, you’ll notice everything going to your status window by default, including chat. This isn’t what we want, so let’s get setup.

The first thing we need to do is set our levels for all of our currently open windows, as well as any future windows that we open. We can accomplish this with two commands in Irssi:

/foreach window /window level ALL -JOINS -PARTS -QUITS
/set window_default ALL -JOINS -PARTS -QUITS

Now, the next thing to do is to create a new hidden window that will be the new home for all your JOINS, PARTS and QUITS. So, from Irssi:

/window new HIDDEN

Navigate to that window, wherever it is placed, and give it a name. For me, I called it “junk”. Of course, this isn’t necessary, just optional, but I prefer that each of my windows have a name:

/window name junk

It will have picked up the -JOINS -PARTS -QUITS from our default setting we just applied, so we’ll need to reverse that. Easiest way is to just apply the converse of what you did earlier:

/window level -ALL JOINS PARTS QUITS

Sweet. Our window is finished. Now, we can turn on the setting that will tell Irssi to look for each individual window level setting:

/set window_check_level_first ON

Wait a bit, and you should see all the JOINS, PARTS and QUITS going to your new hidden window, rather than each respective channel. You’ll also notice that it doesn’t print the channel where these are originating. I don’t know of an easy way to set that without a script, so if you know of such a script that exists, or want to write one yourself, sharing that would be appreciated. In the meantime, this is better than nothing.

Don’t forget to save:

/save

Also, you may not want to make your “junk” window hidden, but rather make it sticky, and split Irssi, putting the junk window on the top. I’ve done this with my highlight window, so it would make sense here. In that case, just:

/window stick on
/window show (number|name)

You can then size the window as needed if you decide you split your Irssi.

And, there you have it. Now, when people are joining and quitting, rather than filling your scrollback where precious chat exists, it’s all being forwarded to a window of your choice. If eventually, you like this setup, and you find that you’re not checking your junk window for joins and quits, then you may be able to get away with just ignoring JOINS, PARTS and QUITS altogether Irssi-wide. Which means, if for any reason you want to reverse this setup, it’s rather trivial:

/set window_check_level_first OFF
/foreach window /window level ALL
/set window_default_level ALL
/window close
/save

And that would back you out of this configuration, and get you back to default.

I should mention that I’ve heard that WeeChat has a feature that only people you’ve recently chatted with will show when they quit, or there is a setting for setting this. I personally think WeeChat is a solid client. However, in this case, I don’t want to see any quits, even with those I’m chatting with, in that buffer. However, I would like to see it in another buffer, and Irssi makes this painless. So, while I’m sure WeeChat can also meet similar needs, Irssi meets my needs best.

As with my other Irssi tutorials, I hope this one was helpful. I find that I personally benefit from my own writing, and that’s the major reason why I blog. I have searched for doing solving problems in the past, only to stumble upon my own blog post, outlining the very issue I’m faced with again. So, if it won’t benefit you, at least it will benefit myself.

Adding your Facebook account to Bitlbee is rather painless, as it is with any other account. The only catch, is you have to have a Facebook username set before you can continue. Once that is set, in Bitlbee, from your “&btilbee” status window, you can add the account:

account add jabber <username>@chat.facebook.com <password>
save
account on

That’s it! You should be up and running with a new XMPP connection to the Facebook chat. However, rather quickly, you’ll notice that the usernames in your “blist” roster are their user identification number on Facebook, rather than their name. Something like “u123456789″. Who is that you wonder? Well, in your “&bitlbee” window, you could run:

info u123456789

Then, using that information, you could rename them one-by-one as they login. However, this is a pain. Fortunately, if you’re running Bitlbee with Irssi, then there is an Irssi Perl script for renaming these automatically for you, as they login. You can find that script here. Save it as “bitlbee_rename.pl” in your “~/.irssi/scripts directory, create a symlink in the autorun directory, load it, and you’re set. Here’s what you would do behind the command line:

wget -O ~/.irssi/scripts/bitlbee_rename.pl http://browsingtheinternet.com/temp/bitlbee_rename.txt
ln -s ~/.irssi/scripts/bitlbee_rename.pl ~/.irssi/scripts/autorun/bitlbee_rename.pl

Now in Irssi, load it:

/RUN bitlbee_rename.pl

Now, each of your Facebook buddies will have their user ID number renamed to “FirstnameLastname” format. The script only works for Facebook chat, so no worries about it mucking up other XMPP connections, and it only renames buddies that haven’t already been renamed. It also saves it to your Bitlbee config (which is /var/lib/bitlbee/username.xml) every time it renames a buddy.

So, there you go. Bitlbee, XMPP and now Facebook, married together. What a beautiful relationship.

When I used to teach system administrators for a living, I gave them the mantra that if you have a tool that can modify a config file, use the tool. The tool has most likely been tested for bugs, and will generate syntactically correct configs. Humans are error-prone, so editing a config by hand means setting yourself up for error and pain. For Irssi, the developers have put in rather extensive commands that can modify everything in the config directly, and there’s even an exhaustive documentation support structure behind those commands. So, there should be no reason to edit the Irssi config by hand.

To show this, in irssi, go to the status window, and type “/help”:

/help
05:29 Irssi commands:
05:29 accept     disconnect  lastlog  op        script     unquery
05:29 action     echo        layout   oper      scrollback unsilence
05:29 admin      eval        links    otr       server     upgrade
05:29 alias      exec        list     part      servlist   uping
05:29 away       flushbuffer load     ping      set        uptime
05:29 ban        foreach     log      query     sethost    userhost
05:29 beep       format      lusers   quit      silence    ver
05:29 bind       hash        map      quote     squery     version
05:29 cat        help        me       rawlog    squit      voice
05:29 cd         hilight     mircdcc  recode    stats      wait
05:29 channel    ignore      mode     reconnect statusbar  wall
05:29 clear      info        motd     redraw    time       wallops
05:29 completion invite      msg      rehash    toggle     who
05:29 connect    ircnet      names    reload    topic      whois
05:29 ctcp       ison        nctcp    resize    trace      whowas
05:29 cycle      join        netsplit restart   ts         window
05:29 dcc        kick        network  rmreconns unalias
05:29 dehilight  kickban     nick     rmrejoins unban
05:29 deop       kill        note     rping     unignore
05:29 devoice    knock       notice   save      unload
05:29 die        knockout    notify   sconnect  unnotify   

So, long story short, don’t edit the config. Use the commands, and learn the help system. With that out of the way, let’s begin.

I’ve encountered many who are using Irssi that don’t understand how a few key commands relate with each other and how to tie them in. So, I would like to cover those commands here, namely: /channel, /network, /server and /connect. Hopefully, by the end of this post, not only will you be comfortable enough with the commands I’ve taught you about, but you’ll be comfortable enough to use the built-in documentation should you be stuck.

/network
The first command to learn is /network, because all the rest of the commands take advantage of it. So, we’ll start there. /network is used for defining some client-specific settings you want to apply when connecting to a server. These settings can include username, real name, nickname, usermodes and other goodies. Running “/help network” can show you everything it supports:

05:32 NETWORK ADD [-nick <nick>] [-user <user>] [-realname <name>] [-host <host>] [-autosendcmd <cmd>] [-querychans <count>] [-whois <count>] [-msgs <count>] [-kicks <count>] [-modes <count>] [-cmdspeed <ms>] [-cmdmax <count>] <name>
05:32 NETWORK REMOVE <network>
05:32
05:32      -kicks: Maximum number of nicks in one /KICK command
05:32      -msgs: Maximum number of nicks in one /MSG command
05:32      -modes: Maximum number of mode changes in one /MODE command
05:32      -whois: Maximum number of nicks in one /WHOIS command
05:32      -cmdspeed: Same as /SET cmd_queue_speed, see section 3.1
05:32      -cmdmax: Same as /SET cmds_max_at_once, see section 3.1
05:32      -nick, -user, -realname: Specify what nick/user/name to use
05:32      -host: Specify what host name to use, if you have multiple
05:32      -usermode: Specify what usermode to use on this network
05:32      -autosendcmd: Command to send after connecting to a server
05:32
05:32 With -autosendcmd argument you can automatically run any commands after connecting to network. This is useful for automatically identifying yourself to NickServ, for example
05:32
05:32 Shows and changes the settings of defined IRC networks.
05:32
05:32 See also: CONNECT
05:32
05:32 Irssi commands:
05:32 network add network list network remove 

So, let’s go ahead an define some networks. I personally connect to several networks simultaneously, all of which have different usermodes, and some which I need to provide authentication to when connecting. So, let’s say I wish to define client-specific connections to Freenode, OFTC and bitlbee. Let’s look at what to add. Oh, by the way, every command and option provided by Irssi can be tab-completed. Worth knowing to save some typing.

/network add -user 88 -realname eightyeight -nick eightyeight -usermode +iw freenode
/network add -user 88 -realname eightyeight -nick eightyeight -usermode +w oftc
/network add -user aaron -realname "Aaron Toponce" -nick aaron -autosendcmd "say identify password" bitlbee

As you can see, each network line is different. I’m using the same username, real name and nick for “freenode” and “oftc”, but different ones for “bitlbee”. I’ve specified different user modes with “freenode” and “oftc” where I haven’t provided any with “bitlbee”. Further, with “bitlbee”, I’m sending an identify command to the server when I connect. As you can probably imagine, this gives me great flexibility on how I want my client to interact with different servers.

Running “/network list” should show you the three servers you just added:

/network list
05:48 Networks:
05:48 freenode: nick: eightyeight, username: 88, realname: eightyeight, usermode: +iw
05:48 bitlbee: nick: aaron, username: 88, realname: Aaron Toponce, autosendcmd: say identify password
05:48 oftc: nick: eightyeight, username: 88, realname: eightyeight, usermode: +w

If you’ve just installed Irssi, you will likely find many networks already defined, including OFTC. If this is the case, and you want to make some adjustments to the OFTC definition, go ahead and provide those in the “/network add” command, and those options will be appended, provided the network name is the same. If you wish to remove any of the networks, then as you learned in the help doc, “/network remove name” is the syntax for that.

It’s important to note that at this stage of the game, any of the commands you enter in Irssi are only used for the current running session. If you wish to keep the settings persistent, then you will need to save it to disk (your config). You can do this with the “/save” command. I would recommend saving often when manipulating Irssi. Further, if for some reason you make a mistake in the command you’re typing, and you wish to revert back to the previous “/save” command, then you can use “/reload” for this purpsoe. “/reload” will read the config, and load the settings it finds there, ignoring any previous settings you’ve defined without saving.

/channel
Now with our networks defined for our client settings, let’s define some channels to visit when we connect to these networks. So, in the status window, what does “/help channel” show?

05:56 CHANNEL LIST
05:56 CHANNEL ADD [-auto | -noauto] [-bots <masks>] [-botcmd <command>] <channel> <network> [<password>]
05:56 CHANNEL REMOVE <channel> <network>
05:56
05:56 Irssi can automatically join to specified channels in specified IRC networks. It can also automatically send the password when manually joining to channel without specifying the password.
05:56
05:56 /CHANNEL ADD [-auto | -noauto] [-bots <masks>] [-botcmd <command>]
05:56              <channel> <network> [<password>]
05:56
05:56 With -bots and -botcmd arguments you can automatically send commands to someone in channel. This is useful for automatically getting ops for channels, for example
05:56
05:56 /CHANNEL ADD -auto -bots "*!bot@bothost.org bot*!*@host2.org"
05:56              -botcmd "msg $0 op mypass" #channel ircnet
05:56
05:56 You can also use the -botcmd without -bots argument. The command is then sent whenever you join the channel.
05:56
05:56 If you want to remove some settings from existing channel record, for example bots, just give the -bots "" parameters to it. Password can be removed by setting it to - (or actually, "" works too).
05:56
05:56 You can remove the channels with /CHANNEL REMOVE <channel> <network>
05:56
05:56 /CHANNEL LIST displays list of channels with settings.
05:56
05:56 /CHANNEL without any arguments displays list of channels you have joined. You can also use /CHANNEL to join to channels just as with /JOIN, like /CHANNEL #a.
05:56
05:56 See also: TS, JOIN
05:56
05:56 Irssi commands:
05:56 channel add channel list channel remove 

As you can clearly see with “/channel”, we can define what channels to join, and if any, what bot commands to send to the channel when we join. Each channel we join will be based on the network that we’ve previously defined. So, I could join #ubuntu whenever I connect to the Freenode network and #debian whenever I connect to the OFTC network. As with “/network”, on a fresh install of Irssi, there may already be a couple channels defined. Feel free to keep them in play when using Irssi, or remove them with “/channel remove” as per the syntax in the help doc.

So, let’s define some channels:

/channel add -auto #ubuntu freenode
/channel add -auto #freenode freenode
/channel add -auto #debian oftc
/channel add -auto #bitlbee oftc

Pretty straight forward, right? I’ve added four channels, two on the “freenode” network and two on the “oftc” network. Because Bitlbee doesn’t handle “channels” necessarily the same way IRC servers do, I haven’t defined any channels to join when I connect to Bitlbee. Notice I’m passing the “-auto” switch, so when I join that network, I’ll automatically join those channels. This is entirely optional, and “-noauto” is default if “-auto” isn’t passed.

As with “/network”, you can append settings to each channel listing as needed, as long as the channel name and network name are the same. If you wish to remove some settings, then you’ll need to “/channel remove” and “/channel add” as appropriate. Running “/channel list” should show our progress thus far:

/channel list
06:05 Channel         Network    Password   Settings
06:05 #ubuntu         freenode              autojoin
06:05 #freenode       freenode              autojoin
06:05 #debian         oftc                  autojoin
06:05 #bitlbee        oftc                  autojoin

Again, you should run “/save” when you’ve defined your channels, so next time you start Irssi, your settings won’t be lost.

One last related note about your channels. For me, I get very used to the location, or layout, of my channels. When I lose my running Irssi connection, for whatever reason, nothing is more frustrating than the channels being in a different order than previous. Fortunately, I’m not the only one that this annoys, so the developers have provided “/layout save” as a way to keep my sanity. “/layout save” will save the location order of your channel windows, so should you join a channel again, it will go to the same location as it was in previously. However, as with every other command in Irssi, this will only save it to your currently running session in RAM. If you wish to keep it persistent, you must issue “/save” for the next time you start Irssi.

/server
At this point, we’re ready to connect. We have all the details out of the way, and we could easily just connect to Freenode or OFTC. However, we may want to pass some server-side options to the networks, such as connecting via SSL. So, before covering “/connect”, let’s get “/server” out of the way, as it’s the last command in this post that does any saving to disk, then we’ll play with “/connect”. As is verbatim in this post, let us pull up the help doc:

06:24 SERVER [-4 | -6] [-ssl] [-ssl_cert <cert>] [-ssl_pkey <pkey>] [-ssl_verify] [-ssl_cafile <cafile>] [-ssl_capath <capath>] [-noproxy] [-network <network>] [-host <hostname>] [-rawlog <file>] [+]<address>|<chatnet> [<port> [<password>
             [<nick>]]]
06:24 SERVER PURGE [<target>]
06:24 SERVER REMOVE <address> [<port>]
06:24 SERVER ADD [-4 | -6] [-ssl] [-ssl_cert <cert>] [-ssl_pkey <pkey>] [-ssl_verify] [-ssl_cafile <cafile>] [-ssl_capath <capath>] [-auto | -noauto] [-network <network>] [-host <hostname>] [-cmdspeed <ms>] [-cmdmax <count>] [-port
                 <port>] <address> [<port> [<password>]]
06:24 SERVER LIST
06:24
06:24      -4, -6: specify explicitly whether to use IPv4 or IPv6 address
06:24      -ssl: use SSL when connecting
06:24      -ssl_cert: The SSL client certificate file (implies -ssl)
06:24      -ssl_pkey: The SSL client private key (if not included in the certificate file)
06:24      -ssl_verify: Verify servers SSL certificate
06:24      -ssl_cafile: File with list of CA certificates (implies -ssl_verify)
06:24      -ssl_capath: Directory with CA certificates (implies -ssl_verify)
06:24      -noproxy: Ignore the global proxy configuration for this server
06:24      -auto: Automatically connect to server at startup
06:24      -noauto: Don't connect to server at startup (default)
06:24      -network: Specify what IRC network this server belongs to
06:24      -ircnet: Same as -network. Deprecated. Do not use
06:24      -host: Specify what host name to use, if you have multiple
06:24      -!: don't autojoin channels
06:24      -cmdspeed: Same as /SET cmd_queue_speed, see section 3.1
06:24      -cmdmax: Same as /SET cmds_max_at_once, see section 3.1
06:24      -port: Use this only to edit the port number of an existing server,
06:24             for new servers use the <port> argument
06:24
06:24 /SERVER disconnects the server in active window and connects to the new one. It will take the same arguments as /CONNECT. If you prefix the address with the + character, Irssi won't disconnect the active server, and it will create a
      new window where the server is connected (ie. /window new hide; /connect address)
06:24
06:24 /SERVER without any arguments displays the list of connected
06:24         servers.
06:24
06:24 /SERVER REMOVE <address> [<port>]
06:24
06:24 /SERVER LIST
06:24
06:24 /SERVER PURGE [<target>]
06:24
06:24 Clears the server send queue. Useful if, for example, you accidentally paste lots of text to a channel.
06:24
06:24 See also: CONNECT, DISCONNECT, RECONNECT, RMRECONNS
06:24
06:24 Irssi commands:
06:24 server add server connect server list server purge server remove 

As should be obvious, this help doc is rather verbose. There are a lot of options that you can send server-side, such as using IPV4 or IPV6, connecting via SSL, changing the connecting port, and a myriad of other options. Let’s pick on just a few, and I’ll let you examine the rest.

Just the other day, I posted on how to connect to Freenode using SSL, and yesterday I covered connecting to OFTC in a similar manner. Let’s take those “/server” strings, along with one for Bitlbee to define how I wish to connect to these servers. As with the previous commands, the syntax is “/server add”, as the help doc mentions:

/server add -auto -ssl -ssl_verify -ssl_capath /etc/ssl/certs -network freenode irc.freenode.net 7000
/server add -auto -ssl -ssl_cert ~/.irssi/certs/nick.pem -ssl_verify -ssl_cafile /etc/ssl/certs/spi-cacert-2008.pem -network oftc irc.oftc.net 6697
/server add -auto -network bitlbee localhost

As you can see, I’m using SSL for the Freenode and OFTC connections, but not for bitlbee. Further, I’m specifying “-ssl_cert” with OFTC to present my self-signed certificate to NickServ, which I’m not doing to the others and I’m using a specific CA certificate to verify the OFTC SSL cert, whereas with Freenode, I’m specifying a whole CA path, and letting it choose the appropriate CA certificate for verification. Lastly, with all three connections, I’m automatically connecting to the networks, so when I launch up Irssi, it begins connecting right away. Because there are channels with “-auto” added to them, when the server connection is successful, I’ll join those channels right away, and my session will be ready to go without any interaction from me.

If I wish to see the listing of servers I just added “/server list”, as per the documentation, will show me that list. Again, on a fresh install, there may be more servers than what we have added here, and you can keep them in play, or remove them as needed. If OFTC is already defined in the server list, then you can make changes to the listing as long as the port number, network name, and server url are the same. If there are settings you wish to remove, then you’ll need to “/server remove” and re-add as appropriate.

So, what does our listing show us:

/server list
06:50 Server               Port  Network    Settings
06:50 irc.freenode.net     7000  freenode   autoconnect, ssl, ssl_verify, ssl_capath: /etc/ssl/certs
06:50 irc.oftc.net         6697  oftc       autoconnect, ssl, ssl_cert: ~/.irssi/certs/nick.pem, ssl_verify, ssl_cafile: /etc/ssl/certs/spi-cacert-2008.pem
06:50 localhost            6667  bitlbee    autoconnect

As you can quickly see, where we specified ports for Freenode and OFTC, we didn’t for Bitlbee, so the default IRC port 6667 was added. Of course, don’t forget to “/save”, so you don’t lose your work up to this point.

A cautious word about “/server”. “/server” is used for defining server connections, not for connecting to servers themselves. However, it can connect you to a server should you say something of the effect to “/server irc.mozilla.org”. If you did this, it will disconnect you from your current connections, and ONLY connect to you irc.mozilla.org. This is an unfortunate side-effect that many first time Irssi users discover. The proper method for connecting to irc.mozilla.org is to use “/connect irc.mozilla.org”, as we’ll discuss below.

/connect
Our last command that I plan on covering in this post. With our networks defined and our servers and channels configured, we could easily at this point connect to Freenode, and all of our settings that we’ve set at this point would be applied, which means it will save us SERIOUS amounts of typing in the future, provided you don’t keep setting up Irssi over and over. Let’s first look at the help doc, as we did with the other commands, then we’ll see how simple our life is from here on out.

/help connect
06:58 CONNECT [-4 | -6] [-ssl] [-ssl_cert <cert>] [-ssl_pkey <pkey>] [-ssl_verify] [-ssl_cafile <cafile>] [-ssl_capath <capath>] [-noproxy] [-network <network>] [-host <hostname>] [-rawlog <file>] <address>|<chatnet> [<port> [<password>
              [<nick>]]]
06:58
06:58      -4, -6: specify explicitly whether to use IPv4 or IPv6 address
06:58      -ssl: use SSL when connecting
06:58      -ssl_cert: The SSL client certificate file (implies -ssl)
06:58      -ssl_pkey: The SSL client private key (if not included in the certificate file)
06:58      -ssl_verify: Verify servers SSL certificate
06:58      -ssl_cafile: File with list of CA certificates (implies -ssl_verify)
06:58      -ssl_capath: Directory with CA certificates (implies -ssl_verify)
06:58      -network: the network this connection belongs to
06:58      -ircnet: Same as -network. Deprecated. Do not use.
06:58      -host: the host
06:58      -!: don't autojoin channels
06:58      -rawlog: immediately open rawlog after connected
06:58
06:58 This command makes irssi to connect to specified server. Current connections are kept and a new one is created.
06:58
06:58 See also: SERVER, DISCONNECT, RMRECONNS, SCONNECT

Obviously, “/connect” is verbose, but not as verbose as “/server”. Further, the first thing to note about “/connect” is there is nothing to save. This command just takes the settings you’ve already defined for your networks, and applies them in to the connection string. However, should you not have a defined network or server to connect to, such as maybe connecting to irc.mozilla.org, you can use many of the settings in “/server” here, such as IPV4, IPV6, SSL and so on. So, say I’m wishing to test an IPV6 connection to irc.mozilla.org, I could issue something like the following:

/connect -6 irc.mozilla.org

That’s it! If it succeeds, then maybe I can add it to my server list with “/server add”, as discussed above and “/save” to the config. Maybe I want to test SSL over IPV6 on that network on a specific port. I could do this. Further, because I’ve already defined my networks, I can say something like:

/connect freenode

In this case, I’ll apply all the network settings AND server settings for the “freenode” connection. This keeps me from typing it over and over every time I wish to connect. Further, the network names themselves can be tab completed! Oh, how this makes life much more enjoyable!

At the end of the help document, you’ll notice a couple of additional commands. Namely “/disconnect” and “/rmreconns”. If you’re finished with a network, and wish to disconnect, then “/disconnect” would be what you want. For example, maybe you’re satisfied with your testing of IPV6 over SSL on irc.mozilla.org. Then, from your status window, you will need to tell Irssi that this is the connection you wish to disconnect. To do this, “^x” (control-x) will switch you servers until you reach the right one. Then, when you’ve switched to the right server you could issue:

/disconnect

Further, maybe a “/connect” isn’t working. Maybe you’re trying to reach a host that is currently down, it’s timing out, or the server on a different port than what you specified. As a result, Irssi won’t be able to connect to your preferred server, but it will keep trying. Eventually, maybe the host will become responsive, and a connection can be made. Maybe not. Regardless, Irssi will keep trying your “/connect” one way or the other. This might be undesirable, so running “/rmreconns” will remove any reconnections that Irssi is attempting to make. As with every other Irssi command, “/disconnect” and “/rmreconns” have a help doc.

Conclusion
So, that’s it. I hope this was helpful. If it was just noise, or much of it was confusing, I hope you walk away from this tutorial with at least two things:

1. /help
2. /save

If you can get those two commands deeply cemented in your brain, then you’ll be okay navigating Irssi and learning its ins and outs. Further, while there might be nothing technically wrong with editing the config by hand, Irssi provides powerful, powerful tools that can do it for you keeping the errors out, and the documentation for those tools, while not perfect, is vast and very complete. But, hopefully, you see now the relationship between “/network”, “/server”, “/connect” and “/channel”, and how you can tap into that power to make your Irssi experience more pleasurable.

Generating an OpenSSL Certificate
OFTC runs a forked version of hyperion-ircd that they call oftc-hybrid. It’s a patched version of hyperion that Freenode was running on their servers before the switch to ircd-seven. It supports IPV6, SSL, and CertFP with NickServ, that I’ll cover later in this post.

Before connecting to OFTC, we want to generate an OpenSSL certificate. This certificate will be used for authenticating to NickServ, and really isn’t related to setting up an SSL connection to OFTC. However, when you connect, you will be presenting OFTC with the generated certificate, and at that point, you will be able to add it to NickServ, because it’s been presented. If you already have your own personal certificate you want to use, then you can skip this step, and move on to connecting with SSL.

I’m going to assume you have OpenSSL installed. If you’re running any modern Unix-like operating system, such as GNU/Linux or one of the BSDs, chances are very high that it’s been installed by default. If not, install it, and continue with the rest of the post.

In this step, we’re going to generate our own self-signed personal OpenSSL certificate. So, fire up a terminal, type in the command below, and follow the on-screen instructions. The values you put here do not matter to OFTC in the least, so fill them in any way you wish. In my case, I’ll fill in the data for my personal certificate, but you fill in the values as you see fit. Replace “nick.key” and “nick.crt” with your IRC nick that you use for this connection.

cd ~/.irssi
mkdir certs
cd certs
openssl req -nodes -newkey rsa:2048 -keyout nick.key -x509 -days 365 -out nick.crt
Generating a 2048 bit RSA private key
writing new private key to 'nick.key'
-----
Country Name (2 letter code) [US]:US
State or Province Name (full name) [Texas]:Utah
Locality Name (eg, city) [San Antonio]:Ogden
Organization Name (eg, company) [Stealth3]:eightyeight
Organizational Unit Name (eg, section) [ISP]:OFTC
Common Name (eg, YOUR name) []:Aaron Toponce
Email Address []:aaron.toponce@gmail.com

Now, if you look, you’ll have two newly generated files: “nick.key”, which is your private key and “nick.crt” which is your public self-signed certificate. Because “nick.key” is your private key, you want to guard it appropriately. Its permissions should be modified to only be readable (and maybe even writable) by you, and you alone. Also, because we have both the private and public key set, let’s go ahead and combine the files into one PEM file that we’ll present to NickServ when connecting:

cat nick.crt nick.key > nick.pem
chmod 0400 nick.key nick.pem

Connecting with SSL
At this point, we are ready to connect to OFTC, and present our certificate to the server. So, fire up Irssi if you haven’t already:

irssi -!

Now that we’re in Irssi, we want to setup our SSL connections to OFTC. You should have ~/.irssi/certs/nick.pem available to send.

We will need to retrieve the CA certificate for verifying the server certificate. I personally like to put all my CA certificates in my certificates store, and this is where I deviate a little from the tutorial on the OFTC site. OFTC has their certificate signed by Software in the Public Interest, so we’ll need their CA certificate. Fortunately, Debian, Ubuntu, and many other GNU/Linux operating systems provide this certificate for us, so we just need to identify the location of the certificate, and plug that into Irssi. If you don’t have that certificate, refer to the tutorial on the OFTC site for obtaining it and installing it on your system.

So, with Irssi waiting for our command, let’s tell it out to connect to OFTC:

/network add oftc
/server add -auto -ssl -ssl_cert ~/.irssi/certs/nick.pem -ssl_verify -ssl_cafile /etc/ssl/certs/spi-cacert-2008.pem -network oftc irc.oftc.net 6697
/save
/connect oftc

When we successfully connect, we should see that OFTC has accepted our self-signed certificate in the MOTD, and it should also show that we are connected securely to the network with SSL:

16:20 [oftc] Irssi: Looking up irc.oftc.net
16:20 [oftc] Irssi: Connecting to irc.oftc.net [64.62.190.36] port 6697
16:20 [oftc] Irssi: Connection to irc.oftc.net established
16:20 [oftc] [charm.oftc.net]: *** Looking up your hostname...
16:20 [oftc] [charm.oftc.net]: *** Checking Ident
16:20 [oftc] [charm.oftc.net]: *** Found your hostname
16:20 [oftc] [charm.oftc.net]: *** No Ident response
16:20 [oftc] [charm.oftc.net]: *** Connected securely via TLSv1 AES256-SHA-256
16:20 [oftc] [charm.oftc.net]: *** Your client certificate fingerprint is 4A5463CE416649F72818B22945681D28250C1ACA
16:20 [oftc] >>> Welcome to the OFTC Internet Relay Chat Network eightyeight

Sweet! We’re connected securely, and OFTC accepted my client certificate by printing the fingerprint for me. If the fingerprint is not displayed, then OFTC has not accepted my certificate, and I need to review the steps outlined above, or on their site.

Authenticating to NickServ with SSL
From here on out, our connection is secured, and we can enjoy the safety that is encrypted packets. So, at this point, we need to register our nick with NickServ, if we haven’t already. It should be pointed out that Services has a complete help document provided. Messaging “help” to any of the Services bots will give you a break down of the available commands and their syntax. I would highly recommend becoming familiar with how to use the provided documentation.

/msg NickServ help
04:22 [notice(NickServ!services@services.oftc.net)] *** NickServ Help ***
04:22 [notice(NickServ!services@services.oftc.net)] ACCESS: Maintains the nickname ACCESS list.
04:22 [notice(NickServ!services@services.oftc.net)] CERT: Maintains the nickname client certificate list.
04:22 [notice(NickServ!services@services.oftc.net)] DROP: Releases your nickname for use.
04:22 [notice(NickServ!services@services.oftc.net)] ENSLAVE: Enslave a nickname to this master nickname.
04:22 [notice(NickServ!services@services.oftc.net)] HELP: Shows this help.
04:22 [notice(NickServ!services@services.oftc.net)] IDENTIFY: Identify your nickname.
04:22 [notice(NickServ!services@services.oftc.net)] INFO: Get information on a nickname.
04:22 [notice(NickServ!services@services.oftc.net)] LINK: Link this nickname to a master nickname.
04:22 [notice(NickServ!services@services.oftc.net)] LIST: Shows a list of nicknames matching a specified pattern.
04:22 [notice(NickServ!services@services.oftc.net)] RECLAIM: Release your nickname for you to use.
04:22 [notice(NickServ!services@services.oftc.net)] REGAIN: Release your nickname for you to use.
04:22 [notice(NickServ!services@services.oftc.net)] REGISTER: Registers a nickname for your usage.
04:22 [notice(NickServ!services@services.oftc.net)] SENDPASS: Send a password reset request.
04:22 [notice(NickServ!services@services.oftc.net)] SET: Set nickname properties.
04:22 [notice(NickServ!services@services.oftc.net)] STATUS: Shows the identified status of a nickname
04:22 [notice(NickServ!services@services.oftc.net)] UNLINK: Unlink this nickname from a master nickname.
04:22 [notice(NickServ!services@services.oftc.net)] *** End of NickServ Help ***

In this case, we’re interested in registering and then identifying. The syntax for registering is providing your password and email as arguments. Providing the correct email is key, so should you lose your password and you can no longer authenticate with SSL, you can have NickServ email you your password. So, I would recommend putting in a valid email here, and not some throw away string:

/msg nickserv register password username@example.com
/msg nickserv identify password

At this point, our nick is registered and we are identified to NickServ. If the nick you’re wishing to register is already registered, then you’ll either need to pick a different nick, or join #oftc on the network, and see if staff can assign that nick to you. At any event, you must be identified with a valid nick before you can proceed with the next steps.

Now that we are identified to NickServ, we need to add our hostmask to the access list. This is beneficial, so we won’t be asked to identify when we connect, which is what we want. So, we need to find our hostmask. This is simple enough by running a /WHOIS on yourself, and identifying your host string. So, it might be something like this:

/WHOIS eightyeight
04:29 [oftc]      nick  | eightyeight
04:29 [oftc]      host  | ~88@c-12-130-240-233.hsd1.mn.comcast.net
04:29 [oftc]     gecos  | eightyeight
04:29 [oftc]    server  | charm.oftc.net [Freemont, CA, USA]
04:29 [oftc]      info  | user has identified to services
04:29 [oftc]  hostname  | 12.130.240.233
04:29 [oftc]      info  | is connected via SSL (secure link)
04:29 [oftc]      idle  | 0d 0h 1m 48s [signon: Sat Jan 30 16:20:12 2010]

In this case, my host is “~88@c-12-130-240-233.hsd1.mn.comcast.net”. This is what I want to provide to NickServ:

/msg nickserv access add *@c-12-130-240-233.hsd1.mn.comcast.net

Good. Now we’re ready to add our self-signed certificate. Remember, when you connected, in the beginning of the MOTD, your certificate fingerprint was displayed. You will want to copy this output and paste it here. You can also use the “openssl” command to get the fingerprint of your cert, you will just need to remove the colons out of the string when providing it to NickServ. In my case, my fingerprint was 4A5463CE416649F72818B22945681D28250C1ACA, so I’m going to add that. Change the string for your fingerprint:

/msg nickserv cert add 4A5463CE416649F72818B22945681D28250C1ACA

That’s it! At this point, if you were to connect again (you must /disconnect and then /connect. /reconnect doesn’t apply the SSL settings, apparently (BUG?)), you will find that you will automatically identify to NickServ with your cert, and without a password. As you can imagine, this is highly secure. If you are not taking advantage of SSL, then your password can be sniffed on the wire, and your account could be compromised. In this case, we’re neglecting the password, and using public key cryptography instead to authenticate. I don’t know at this point if a MITM attack would be successful. So, bonus.

To see that it has succeeded, when you connect you should see the following at the end of the MOTD:

05:14 [oftc2] >>> You have set user mode +i
05:14 [oftc2] >>> You have set user mode +R
05:14 [oftc2] [notice(NickServ!services@services.oftc.net)] You are connected using SSL and have provided a matching client certificate
05:14 [oftc2] [notice(NickServ!services@services.oftc.net)] for nickname eightyeight. You have been automatically identified.

Wrap-up
Congratulations! You are now connected securely to OFTC via SSL and you have identified to NickServ successfully with your self-signed certificate. The major benefits of this method, is you can ditch any client-side identification scripts, which is always a bonus. Further, your packets are now encrypted between you and the OFTC servers. OFTC also utilizes server-to-server encryption, so if you’re physically connected to a server in the United States, and someone you’re in private message with is physically connected to a server in Europe, not a single plaintext packet is sent on the wire between your client and his (assuming he’s connected via SSL as well).

A final not on SSL connections, is your computer clock that you are running Irssi on needs to be accurate. It would be recommended to use NTP to keep your clock in sync with Internet time servers. If your clock is too far off, you won’t be able to negotiate the OpenSSL handshake, and as a result, not be able to take advantage of the encrypted traffic. Also, OpenSSL certificates need to be valid. If your certificate expires, then you will not be able to present it to the server, and as a result, not be able to authenticate to NickServ. The dates on expiration are up to you, but validity is important. You can see the dates of your certificate with the following command:

openssl x509 -noout -in nick.pem -dates

Enjoy the security.

Connecting with SSL
Freenode is listening for SSL connections on ports 6697, 7000 and 7070. I don’t know what the logic here is for that, but does it matter? A port is a port is a port. So, for Irssi, setting this up is rather simple.

/server add -auto -ssl -network freenode irc.freenode.net 6697

Boom! Done.

Now, if you want to verify the Freenode server SSL certificate against a certificate authority (CA), then you’ll need to download the CA certificate from the authority that signed the server certificate. In this case, its Gandi.net, and their CA certificate file can be found here: http://crt.gandi.net/GandiStandardSSLCA.crt. However, using the file in its native DER format for Irssi wasn’t working for me. So, using openssl, I converted the binary DER data file to PEM format, at which the Freenode certificate would properly verify:

cd /usr/share/ca-certificates
mkdir gandi.net
cd gandi.net
wget http://crt.gandi.net/GandiStandardSSLCA.crt
openssl x509 -inform der -outform pem < /usr/share/ca-certificates/gandi.net/GandiStandardSSLCA.crt > GandiStandardSSLCA.pem
ln -s /usr/share/ca-certificates/gandi.net/GandiStandardSSLCA.pem /etc/ssl/certs/GandiStandardSSLCA.pem

With the Gandi.net CA certificate installed in the standard CA certificates store, I modified my server string in Irssi:

/server add -auto -ssl -ssl_cacert /etc/ssl/certs/GandiStandardSSLCA.pem -network freenode irc.freenode.net 6697

Unfortunately, as much as I would like this to work, it doesn’t. I kept ending up with this error:

[freenode] Irssi: Connecting to irc.freenode.net [140.211.166.4] port 7070
Irssi: warning Could not verify SSL servers certificate:
Irssi: warning   Subject : /OU=Domain Control Validated/OU=Gandi Standard Wildcard SSL/CN=*.freenode.net
Irssi: warning   Issuer  : /C=FR/O=GANDI SAS/CN=Gandi Standard SSL CA
Irssi: warning   MD5 Fingerprint : F8:40:2C:D9:D6:46:1F:D0:38:5D:ED:21:69:8B:17:C4

Digging deeper, it appears it’s failing with:

2 X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT: unable to get issuer certificate
the issuer certificate could not be found: this occurs if the issuer certificate of an untrusted certificate cannot be found.

After a bit of hacking, and the help with Bazerka in #irssi, we found that my specific version of OpenSSL doesn’t like the certificate chain. Because Irssi is using these libraries, it took a bit of mucking about to find enough data points, that you need to be running an extremely recent SVN build of Irssi (there’s a bug with some SSL certificate verifications that affect us here), also with OpenSSL version 0.9.8k or later. I am not running either on Debian stable, so am I stuck not being able to verify the certificate Freenode gives me?

Well, not quite. The Gandi certificate is signed by UTN-USEFirst-Hardware, which in turn is signed by AddTrust External Root (if your browser has a CA certificates store, you can visit https://irc.freenode.net:7070, and get the details of the certificate there, or use “openssl s_client” to download it and examine the details). So, if you have the USEFirst and AddTrust CA certificates, then you can verify those instead with older versions of OpenSSL or Irssi, and you’ll be golden. So, if you have a CA certificate store, as most GNU/Linux distributions do, you can set the following instead:

/server add -auto -ssl -ssl_verify -ssl_capath /etc/ssl/certs -network freenode irc.freenode.net 6697

This will succeed, and when connected, you’ll see usermode “+Z” meaning you’re using a secure connection, and you’ve properly verified the server certificate Freenode is handing out. Notice the difference with “-ssl_capath” here and “-ssl_cacert” from above. This is key to making this work.

Authenticating with SASL
Okay, after setting up SSL with Freenode, the next task for me was using SASL authentication rather than a server password to authenticate to NickServ. It should be noted that using SASL authentication is entirely optional! You don’t have to use this method if you don’t want. However, using the SASL authentication script I’m going to point to in a second has one nice feature that might be of interest to you: using Blowfish encryption on your password, and sending that to NickServ, should you not be using an SSL connection at all. If you’re not interested in using an SSL connection, at least you can encrypt your password on the wire when authenticating using SASL.

Anyway, setting this up means getting Irssi in shape for SASL. By default. Irssi doesn’t support SASL authentication out of the box, so we need a Perl script to make it happen. You can find that Perl script here. After downloading the script, put it in your ~/.irssi/scripts directory, and link against it in the autorun directory. Something like this:

cd ~/.irssi/scripts/
wget http://freenode.net/sasl/cap_sasl.pl
cd autorun
ln -s ../cap_sasl.pl cap_sasl.pl

Now, you just need to load it in Irssi, and setup your username and password for authentication. A word of note here: when setting up SASL authentication, you need to be using your primary nick with NickServ, not any nick that you’ve linked against, or it will fail. I don’t know why this is, but that’s the case. So, in my case, my primary nick is “atoponce” and my secondary nick is “eightyeight”. I use my secondary nick for all my IRC sessions, but when using the SASL command below, you must use your primary nick. While we’re at it, we’ll save everything we’ve done up to this point in the config:

/RUN cap_sasl.pl
/sasl set freenode primary-nick password DH-BLOWFISH
/sasl save
/save

First, if you haven’t noticed already, you need some Perl libraries in place before you can run this script, namely Blowfish, DH and BIGNUM. If you’re on Debian or Ubuntu, you can install them with:

aptitude install libcrypt-blowfish-perl libcrypt-dh-perl libcrypt-openssl-bignum-perl

Notice, I”m using DH-BLOWFISH in my example. “PLAIN” is also completely valid there for your mechanism. Also, notice I’m using “/sasl save” to save the settings to disk. You’ll want this, so should you need to restart Irssi, everything will be in place, and you won’t have to go through this procedure again.

If you’ve followed this tutorial rather closely, when you connect, you should see something like the following at the beginning of the connection:

16:05 [freenode] Irssi: Looking up irc.freenode.net
16:05 [freenode] Irssi: Connecting to irc.freenode.net [140.211.166.4] port 6697
16:05 [freenode] Irssi: Connection to irc.freenode.net established
16:05 [freenode] [niven.freenode.net]: *** Looking up your hostname...
16:05 [freenode] [niven.freenode.net]: *** Checking Ident
16:05 [freenode] [niven.freenode.net]: *** Found your hostname
16:05 [freenode] [niven.freenode.net]: *** No Ident response
16:05 [freenode] Irssi: CLICAP: supported by server: identify-msg multi-prefix sasl
16:05 [freenode] Irssi: CLICAP: requesting: multi-prefix sasl
16:05 [freenode] Irssi: CLICAP: now enabled: multi-prefix sasl
16:05 [freenode] >>> eightyeight!88@oalug/member/pdpc.supporter.monthlybronze.eightyeight atoponce You are now logged in as atoponce.
16:05 [freenode] Irssi: SASL authentication successful
16:05 [freenode] >>> Welcome to the freenode Internet Relay Chat Network eightyeight

You want to see “SASL authentication successful” in the output. If it fails then you will still need to provide your password manually to NickServ. You will likely need to review the steps outline above finding anything you might have missed. Remember, you’re authenticating with your primary NickServ nick, not any others linked to it. In the output, you can see I’m authenticating with “atoponce”, but using “eightyeight” when I actually connect.

One last work about SASL authentication: you no longer need a server password if you’re utilizing this. Before, Freenode supported a server password that you could append to the end of your “/server” string for authentication. Freenode still supports this, although in “username:password” syntax rather than just “password”. But, SASL authentication overrides the need for a server password, so you can take that out of your settings. It’s not hurting anything if you leave it, but it’s not doing anything beneficial either.

Miscellaneous
With all that out of the way, I want to point out one major change that I welcome. That is the ability to join more than 20 channels simultaneously. Previously, with hyperion-ircd, you had to get Freenode staff to grant you usermode “+u” which gave you the ability to sit in more than 20 channels with one connection. If you’re an IRC addict like I am, 20 is pretty freaking limiting. However, ircd-seven now supports the ability to connect to 120 simultaneous channels. You can see this in the MOTD output when you connect (emphasis placed):

16:05 [freenode] >>> CHANTYPES=# EXCEPTS INVEX CHANMODES=eIbq,k,flj,CFLMPQScgimnprstz CHANLIMIT=#:120 PREFIX=(ov)@+ MAXLIST=bqeI:100 MODES=4 NETWORK=freenode KNOCK STATUSMSG=@+ CALLERID=g are supported by this server
16:05 [freenode] >>> SAFELIST ELIST=U CASEMAPPING=rfc1459 CHARSET=ascii NICKLEN=16 CHANNELLEN=50 TOPICLEN=390 ETRACE CPRIVMSG CNOTICE DEAF=D MONITOR=100 are supported by this server
16:05 [freenode] >>> FNC TARGMAX=NAMES:1,LIST:1,KICK:1,WHOIS:1,PRIVMSG:4,NOTICE:4,ACCEPT:,MONITOR: EXTBAN=$,arx WHOX CLIENTVER=3.0 are supported by this server

Very nice!

So, there you have it. SSL connectivity with SASL authentication and the ability to join up to 120 channels simultaneously on the new IRCD at Freenode. I personally welcome all these changes, and it’s nice to see that every IRC server I’m currently connected with provides a secure connection. Call me paranoid, but I’m enjoying SSL.

Hilight Window

See the irssi screenshot above. The section labeled “1″ is a split window called “hilight”. Anything that is hilighted (set using the /hilight command) will be logged to that window.

To do this, first load the script. The script I use is a modified version of cras’s hilightwin.pl that logs timestamps as well. It is available here: hilightwin.pl

Put the script in ~/.irssi/scripts/autorun/ and type /run autorun/hilightwin.pl in irssi.

Next, create the split window. This is done with the /window command. See /help window for details on how this works.

  /window new split
  /window name hilight
  /window size 6

The above commands will create a new split window (as opposed to a “hidden” window, which privmsg, channel, and status windows are by default), call it hilight (so the script knows where to send the information) with a height of 6 lines.

Now, have someone address you in a channel using “yournick: hello”. If you did everything correctly, it should be logged to the split window. If you want to have all lines containing your nick hilighted, type /hilight yournick. See /help hilight for advanced features. Use /layout save to save your layout settings and have irssi automatically recreate the split hilight window on startup.

For me, irssi is more than just an IRC client. It’s a complete messaging center. I access IRC, Jabber and push to microblogging sites, such as Facebook, Identi.ca and others. Because I’m running behind GNU screen, I want to be aware of any messages while I’m away. Of course, Irssi does this for you automatically, by putting your hilights in the status window. For me, that’s a busy window, and it’s easy to lose hilights if they sit long enough. So, I’d rather have the hilgihts go to a separate window. Enter that script listed above, along with splitting the window for immediate access.

Now you have a split screen window that your highlighted messages are going to. However, they’re also going to your status window when you’re away. This is known as your “awaylog”. You can change that setting if you want. By default, it logs ‘msgs hilight’. If you want to disable it, now that you have a new hilight window, you can set:

/set awaylog ""

Note, that your new hilight window will only log hilights, not msgs. For me, this is no big deal, because msgs are already in their own window by default anyway, and the point of this is to keep all the messages in one place. So, this is a win/win for me.

Along with this script, there is other script goodness that I take advantage of with this fabulous client. Listed below:

• anames.pl- Query the server to see who is away and who is not by running /anames. Prints out a list similar to /anames, but gives those whore are marked as away a different brightness to their nick.
• il.pl- Because I’m a microblogging nerd, I like to know in my status bar how many characters I’ve currently typed before I hit enter, to know whether or not I’m under the 140 character limit. Works like a charm, character-by-character.
• trigger.pl- This script rocks! Allows me to do search and replace with text in my client. I use it mainly for the Identi.ca Jabber bot. See this post for more details.
• usercount.pl- You can put the number of people in a channel, including the number of ops, halfops, voices, etc in your status bar.
• trackbar.pl- This puts a trackbar on your window where you last were in the conversation last time you were watching it. Very useful to pick back up where you left off in a conversation when you return to that window.
• screen_away.pl- Using GNU screen is solid with irssi. However, when I am away, I want to mark myself away with the server. So, all I have to do is detach screen, and this script will mark me away with my configured away message. No public announcements either.

Of course, I use a few others, such as the bitlbee scripts, but these are the heavy hitters. Must-haves for any serious irssi user/hacker.

I just discovered mutt, a fantastic email client. Well, technically, I didn’t “just discover it”, as I have played with it in the past, but never got far with it. You see, configuring mutt is a royal pain. On top of that, mutt is just an MUA (mail user agent), and does not provide an MRA (mail retrieval agent) or MSA (mail sending agent). So, not only do you need to install and configure mutt, but you also need to install fetchmail and sendmail or similar. This certainly isn’t attractive to the average user.

On Helios now, it has become my messaging machine. It’s running the following:

• Irssi: The only IRC client you’ll ever need.
  • Bitlbee: An IRC to IM gateway used for Jabber. Running as an extension in Irssi.
  • Irssi-otr: An Off-The-Record plugin used for client-to-client encryption on any protocol.
• Mutt: The only mail client you’ll ever need.
  • Links2: Used in combination with mutt to dump HTML email to text, making HTML cruft readable

Now, that I have my email and instant messaging configured and running in a terminal, all I really need is a browser. I can execute any command from the terminal, so I don’t need menus, and although I could use links, or some other text-based browser, using a GUI browser is needed for viewing images, video, sound, and other multimedia (this could be argued as to whether or not we need those things- I’m not going to entertain that argument).

So, from where I’m sitting, I don’t need much on my computer, which makes me wonder why I’m running a full featured desktop like GNOME or KDE in the first place. It may be time to slim things back down to Openbox or Fluxbox. Screenshots attached for your pleasure.

I had run the madcow theme in the past, but I wasn’t happy with a few aspects of it. For example, I didn’t like the nicks being right-aligned based on the last character of their nick. Because of this, the developer of the the theme chose a max length for the nicks that meant cutting off any nicks that extended past that max. Why not just left-align it to conserve space? Also, there were aspects of the theme that didn’t tie in well with itself. So, after several hours of hacking, I finally settled on my new theme. It’s not a big departure from the madcow theme, as I loved the color scheme and much of the formatting, and wanted to keep it. However, I also wanted to change what was driving me nuts about the theme. Now, I’m no Irssi theme hacker, so I’m sure there are better ways to reach some of the formatting decisions that I made, but it’s working well, so I’m happy.

I decided to name the theme 88_madcows, after my IRC nick ‘eightyeight’ and keeping homage to the madcow theme developed by dubkat. Below is a screenshot of the theme in action. If you would like to download it, I’ve provided a link as well. I would recommend running the following commands in your Irssi for maximum theme integration (I have usercount.pl, trackbar.pl and nicklist.pl installed):

/set hilight_color %g
/set hilight_act_color %R
/set trackbar_style %g

Full 1680×1050 screenshot here (using the Tango color scheme in gnome-terminal).
Theme download here.