My thoughts in regard to the flaws of IRC clients.

Goals

I have high demands on IRC, because I like to track many places.

So far it has been difficult to find efficient, elegant, easy, yet powerful clients to fulfill my every need.

Now, I don’t think it is possible to ever reach “100%”.

But all the time being dissatisfied, I’ve tried to order my thoughts about the reasons for this,
and the approaches that would be necessary.

I’ve also realised that it is a difficult thing; and it seems to require careful planning.

If your code gets messy early on, doing things would seem to become almost exponentially more difficult.

I’ve inspected Irssi for a ways to bend the notify features in reach of my needs
and it is frigging impossible without major alterations in the core.

I’ve found that while everyone probably has dreamt of writing her own irc client at least once,
it is surprisingly difficult to get it done right — despite the simplistic protocol.

The protocol is amazingly simple,
yet it gets bended beyond.
And many people writing IRC servers, only check with the most popular client in that process.

Deciding how to show incoming data is the problem.

Main

There are two main points of access to information:

• when IRC is in background, you want to have a status area keeping you up to date of potentially relevant new posts, and
• when actually using IRC, you need to be able to get different views on the situation to grasp it in the fastest and easiest way possible.

Notify

Actually deciding when to notify you, is the first interesting, and also the easier thing to approach programmatically.

Another question is what parts of information to include in the notify (or how to present it in general).

Stuff to do would be,

• colour indicators;
• a “global” activity indicator without too much detail,
• indicators targeted at
  • windows,
  • collections,,
  • channels,
  • queries;
• excerpts of the relevant messages that triggered it.

Furthermore, we’d like to have an easy way to zap away unimportant hilights.
(Can be done with a simple global keybinding for example.)

As for the selection method itself, the right thing ™ is to give the user filter chains.
Problem with this is, things quickly become too complicated;
but simplifying it, will fail to satisfy myself as a power user.

Criteria are of course

• targets as mentioned above, as well as
• IRC specifics such as
  • known data about the user
    • hostname,
    • X account name,
    • …,
  as well as
• matching on
  • message content, and
  • message level.

Maybe it would be possible to represent this with some sort of iptables firewall-like rules.

A good manager for the rules is important,
and we’d want to have the possibility to set up these rules quickly, and setting some persistency for them.

For example, on Irssi, your almost only way to set up notifications is either through a global hilight message levels
or on text pattern matching.

It does not provide means for a situation such as entering a channel with your friends, where an important topic is discussed.

In other clients, you might be able to quickly flick notification for this window with something like /window notify on/off.

Or in mIRC, rightclick - and select one or a combination of Desktop/Flash/Beep.

Such settings usually don’t persist.
— I found this to be a very convenient and important way, and I call it “on the fly” rules. —

Of course you can then turn them into permanent ones if you want.

Views Pt.1

As for the views on the data, I require quick ways of “filtering”.

Basically, most clients that are out there,

• get an incoming stream of IRC data,
• apply some rules to it,
• write some string into whatever window
• and remember the window content.

I found that this is not the right thing to do.

Client/Server

The client/server model should be employed in the client as well.

Many people run either a BNC or use Irssi on like a shell account they
connect to remotely.

Running an IRC client on a shell is
actually totally stupid,
because for all your data display, scrolling, filtering
you have to cope with SSH lag.

Now, this might not be very relevant for some people
and maybe that’s also the reason why noone thinks about this,
but it is actually quite important to me.

I do like to have my IRC connection stored away on some always on server of some shell provider.

I also like to come back and get the same view on my data as I left.

But there are better ways to do this!

Of course there is still one benefit which is availability.

An application which first needs to be installed on the client, might be a problem.

Obviously, as soon as you have client/server, you automatically have both.

At least, if you write a console client.

I would like to make this “local” availability a common case.

I haven’t yet thought about this in detail,
but there is one funny thing I noticed:

BitchX, is available, or easily installed as binary, so far on every Windows box, on every Linux box, on the HPUX at the HP labs, and on all the Suns at the university CS labs.

If you do it right and static, you can make a local client available as easily as a one file binary download.

On the other hand, I couldn’t get Irssi 0.8.10 to compile on the Sun
systems and gave up.

Another important thing to keep in mind is, that
not every place you will come to
has a complete build toolchain.

Of course, there is always the “rescue mode”: run it over SSH on your
box.

But preferable would be to be able to provide native clients
which do not need to be compiled first.

Since many places do not appreciate you installing software either,
it is important to make the custom clients undemanding.

Resorting to SSH is bad, because you do everything display wise on the server side.

Views Pt.2

Many things make a view.

“View” is just my broad term for describing everything that you see on
your screen.

For example, a layout where you have a surveillance channel on top, 10 lines height, and two general purpose channels on the left and right:
this would make up a “view”.

With a keypress, you get a new layout featuring different (or the same) windows, in another arrangement: another view.

A command further, you filter your messages — on the left, all your recent private messages, in the middle, everything that contains the word “irc”
(from selected sources): all of this together, a view.

In some window, you inflate all the messages from multiple sources into a single timeline — ircII style: also a view.

Something also expressed through views would be the ability to hide, and reshow, certain messages, such like
status/join/part/quit messages.

Views are also responsible for applying different charset recoding mechanisms depending on rules.

Note that you can have views inside of views.

Views can be divided into two categories:

• Screen layout views.
• Views acting upon window content.

(It might be better to give these two types distinct names, for example layouts and filters.)

The filters could probably work with the same kind of rules that is used
for the notify feature as described above.

Irssi has an /ignore option, but this is applying a destructible tool on my input data.

That is a very bad thing. Even things you ignore should be logged.

So in the end you usually opt to not ignore,
but still, you’d like to not get hilighted by this.
— Impossible, in Irssi.

Many things on IRC are decided by your client’s power.

For example, public away messages:

generally considered a bad thing, they’d be less so if people had better ways of dealing with them. If I had the power to stop them from giving me hilights, without
ignoring everything that contains the word “away”
(they might still be improper practice, but a great deal less annoying).

Irssi also introduced the feature of “message recoding” (changing message charsets, as if piping them through iconv), which is done at such core level, that it screws your logfiles and destroys messages.

Charset and encoding mess

While encoding mess might be an inherent irc flaw, my client must give me the ability to cope with it appropriately
(and not “demand that everyone switches to utf8”).

This means you must have the whole filter set available to decide encoding issues. There might be persons (or clients) always communicating
with a certain encoding.

There might be channels where a certain encoding is agreed upon.

There will be users speaking in a different charset than what is agreed upon.

It is possible to sensitively mix some charsets.

As underlying to the whole concept of filters, you must be able to correct your charset and encoding decisions in retrospect, and also be able to set different encodings for different moments in your timeline.
This means for example, if someone suddenly starts talking Shift_JIS, and you have not yet set up the correct filter chain to understand that, then if you do, you will be able to read all the text that’s been written.
But if the same user previously used JISXISO-2022-JP-3, then this new setup must not render that old correctly filtered text useless.

Or the lack of client side /list filtering in traditional clients, it’s just not up to date.

Another thing is “duplicate” part/quit messages across channels:

Usually, we want to see a quit message for a user in all affected windows that are supposed to show status messages, but we only want to get notified at max once if someone mass
parts prior to a quit.

Also, when we get shown “hilight notifications” for windows, in which
users parted or quitted, they should go away as soon as I have seen this
message in any of the affected windows.

Checking 10 channels just to see that userX has parted from all 10 of them
is just silly.

Another thing I want to do with these views is to start a private conversation in a shared timeline with the main chat (ircII style), and then be able to copy or move it to its own
window.

Here is a bonus:
an IRC client that makes it very difficult to misfire a message would be great.