IRCTk 1.0.0

I know that my blog has been pretty quiet in the last months. But I'm a busy dad doing busy daddy things in this period, and I haven't had a chance to work on a bunch of stuffs, nor writing interesting articles for my blog.

However, I've spent a couple of weeks alone and I was able to, finally, complete the first stable version of an IRC client I was working on for a while.

IRCTk

This client is nothing new. In particular the GUI, at this point in time, is pretty basic by modern standards. In fact, I focused my efforts for the 1.0 version to get the foundations of the client right, in particular it's transport subsystem and the extensions subsystem.

A multi-process approach

> Just use nc(1) to get it running quickly :-)

>

> -- op, while discussing the initial design.

From the quoted half-joke by op, came the idea to make IRCTk able to use any custom transport a user, or programmer, could think of. This means that, in the case of IRCTk, the IRC protocol became a messaging protocol between the transports and the main application. This opens the opportunity for:

Writing custom transports for the networking layer itself.

Using any programming language for those transports.

Writing things like translation layers for various chat protocols (think about a custom matrix-to-irc program).

Leveraging the security features of the platform the program is running on (things like ASLR, sandboxing etc..).

The fact that IRC is a line-based protocol, makes everything much, much easier. For instance, establishing a communication channel with a canonical IRC server, on OpenBSD, using TLS is as easy as (libera chat, in the example):

Or, if you are so advanced as to be able to use IPv6:

With the communication between IRCTk and netcat, handled by a two-way pipe. As simple as it sounds, on OpenBSD nc(1) has the following properties:

It uses the nice libTLS library.

It's sandboxed through pledge(2) and unveil(2).

It runs in a separate address space, and given that every transport is in a separate process, ASLR becomes effective, even when running different instances of the same binary.

Every "server" is managed by a different transport program.

This makes the setup, security-wise, much better than a canonical single-threaded application, or a multi-process application with the fork(2) dance to get a multi-process setup. The other big advantage of this kind of setup, is that the GUI part uses the TCL ability to do non-blocking I/O on the pipes file descriptors, while it does not matter what the transports, or the extensions, uses. This means that, in effect, apart from leveraging the capabilities of a modern, multi-core machine, the GUI doesn't block due to I/O issues on one or more of the transports, or extensions. This is a huge advantage given that TCL is single-threaded and any kind of blocking I/O would freeze the whole application. Also, this lets programmers writing transports or extensions, to write their programs in the simplest way possible, without worrying of the consequences on the main process.

Writing extensions

Overall, this approach turned out to be a really nice way of reusing existing code, leveraging the platform security mechanisms in the meantime.

Going forward

For a bit, IRCTk 1.0 will remain out there, mainly because I have other things going on in my life right now, so I don't have the rush to release a new version soon. However, the roadmap for 1.1 is already published:

IRCTk 1.1 roadmap

IRCTk backlog

It's possible that some elements will be added there, but one thing is for sure: the next version will be focused on improving the UI, mainly, with some preparation (completing IRCv3 support), for the following releases, given that I would like to be able to show images inline and such.

Completed the version 1.1, I'll start to work on writing custom transports, like a matrix-to-irc one or whatever other chat protocol I would like to support.

The project forum is available to submit ideas and ask any kind of question or support:

The forum

Enjoy!