💾 Archived View for gemini.abiscuola.com › gemlog › 2024 › 01 › 01 › irctk-100.gmi captured on 2024-03-21 at 14:50:20. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2024-02-05)
-=-=-=-=-=-=-
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.
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.
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:
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):
nc -c irc.libera.chat 6697
Or, if you are so advanced as to be able to use IPv6:
nc -6c irc.libera.chat 6697
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:
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.
Overall, this approach turned out to be a really nice way of reusing existing code, leveraging the platform security mechanisms in the meantime.
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:
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:
Enjoy!