-- Leo's gemini proxy
-- Connecting to ayushnix.com:1965...
-- Connected
-- Sending request
-- Meta line: 20 text/gemini
When I created this gemini capsule and started writing posts in it, one of the lines on my home page was
> You can also find me on IRC going by the nick "ayushnix". I'm on libera.chat, OFTC, and tilde.chat. Unfortunately, I haven't set up a system to read any messages I might receive while I'm offline. I hope to resolve this issue soon.
For the past several years, I've been participating in IRC using the web chat software hosted by IRC networks on their home pages. I know, this isn't really how IRC is meant to be used in the long run and I did start maybe 4 years ago by using The Lounge, a self-hosted IRC web client which also acts like an IRC bouncer. I deployed it in a container using Docker (because it was the hot new thing at that time in my vicinity) and that worked for a while until stuff started to break or I had to make some changes and I realized that I didn't really know to manage containers. A few months ago, I tried to use soju (an IRC bouncer) and senpai (an IRC client) but wasn't able to set them up successfully with the minimal effort that I may have presented. I guess I'm the kind of guy who lets the items in his TODO list gets stale and then one day, when stuff starts to annoy me beyond my threshold, I go back to that stale TODO list item and complete it. This happened a few days ago when I was trying to talk on libera.chat using their web IRC client (gamja, not KiwiIRC) and it kept getting disconnected more than it usually does. It was time to use a proper IRC bouncer and a client, preferably which works on the terminal.
I usually associate software in the OpenBSD domain to be well designed and have high quality documentation, even though I've never really used OpenBSD in a VM or on bare metal. I admit that I'm biased but I'd say that it is somewhat justified considering the quality of their man pages and software like mandoc. I also know that pounce, calico, and catgirl aren't part of the core OpenBSD software but the author, June McEnroe, has a nice website and seems to have designed these software with OpenBSD in mind considering their support for the pledge(2) and unveil(2) system calls, although this obviously isn't a thing on Linux¹. Unfortunately, I ran into several issues trying to get pounce and calico to work, probably because I didn't find their documentation easy to understand.
One of the lines in the pounce man pages says that
> The local server portion of pounce requires a TLS certificate, which can be obtained for example by an ACME client such as acme-client(8).
This doesn't say that a self-signed TLS certificate will work as well. I know that if pounce is run on a remote server, like a VPS, and not in a LAN, a CA signed certificate should be used. However, when running pounce in a machine inside a LAN, a self-signed certificate is perfectly fine (assuming there aren't any untrusted devices in your LAN and if there are, they are partitioned behind VLANs). After spending some time on this, I was able to figure out that pounce runs fine with a self-signed certificate for itself.
One of the intentional features of pounce is that one instance of pounce will only connect to one IRC network. If you want to connect to multiple IRC networks, you'll need to run multiple instances of pounce. This can be done either by making different instances of pounce listen on different ports or by creating different UNIX domain sockets and having calico forward incoming TLS requests by an IRC client like catgirl to pounce using Server Name Indication. I started calico using the following command:
$ calico -H hostname.example.org /run/pounce/
My hostname isn't actually "hostname.example.org". I'm just adhering to RFC 6761. Rest assured, for the purposes of this article, the hostname on which I'm running pounce and calico is a subdomain of an apex domain.
While calico was running, I ran an instance of pounce with the value of "local-host" set to "oftc.hostname.example.org". This made pounce throw the following error:
0A000458:SSL routines::tlsv1 unrecognized name
and calico gave the following error:
calico: hostname.example.org: No such file or directory
I know that calico uses SNI to forward requests to pounce but I didn't understand how to proceed after reading these error messages. While talking to alexlehm in #meta on the tilde.chat IRC network, I realized that maybe I need DNS records on my router for sub-subdomains of hostname.example.org, such as oftc.hostname.example.org, which was the value of "local-host", although pounce wasn't really listening on that host (which was a source of confusion as well).
It’s not DNS There’s no way it’s DNS It was DNS.
While I was adding an entry in dnsmasq on my OpenWrt router for redirecting an address (*.hostname.example.org) to the IP address where I was hosting pounce and calico, June McEnroe herself showed up in the IRC channel and told me that doing that was the right call. After adding those changes, I was finally able to make pounce and calico work with catgirl. Phew!
Until this point, I was running pounce and calico as a foreground process in the shell on Alpine Linux, which is installed on my Raspberry Pi 4. This won't work because I need them to start automatically after a reboot. Unfortunately, the pounce-3.1-r1 apk package didn't provide any initscripts or configuration files for managing pounce instances. I didn't wanna give up at this point so I decided to create them myself, and maybe upstream it as well. To no one's surprise, this process didn't go over smoothly as well.
One of the nice features provided by systemd is creating template service units. These units have a "@" at the end of the file name, just before the file extension. One such service, which is probably present in all systemd based distributions, is the "user@.service" file. One can create multiple instances of this service by appending the name of instances after the "@" and before the file extension, such as "user@1000.service" for the user with a UID of 1000. Unfortunately (which is arguable for some people), OpenRC doesn't provide this feature as one might expect. However, it does support running multiple instances of a process. I asked for help on the #alpine-linux IRC channel about this and I was pointed to the OpenVPN initscript and the dnsmasq initscript in the Alpine Linux aports. We can create multiple instance of a service by creating symlinks to the original initscript. For example, if I want a pounce instance for libera.chat, I can create a symlink called "pounce.libera" which is linked to the "pounce" initscript. After doing this, we need different names for different processes of pounce. We can do that by adding the following shell script segment in the initscript for pounce:
instance_name="${RC_SVCNAME#*.}"
[ "$instance_name" != "pounce" ] \
&& name="pounce ($instance_name)" \
|| name="pounce"
"RC_SVCNAME" is a special variable that holds the name of the initscript file.
I also had trouble with the "output_log" and the "error_log" special variables. These variables were picking up the value "pounce.log", which was configured in "/etc/conf.d/pounce", rather than "pounce.libera.log", which was configured in "/etc/conf.d/pounce.libera", an regular file rather than a symlink. Someone helped me out again on the #openrc channel on libera.chat and I realized that the variables in "/etc/conf.d/pounce" would override variables in "/etc/conf.d/pounce.libera".
After feeling that I had a decent solution, I went ahead and raised a merge request for updating the pounce package in the testing repository of Alpine Linux.
After receving some suggestions about improving the APKBUILD file and adding "supervise-daemon" to manage the pounce process, I added more commits to my fork and Kevin Daudt (ikke on IRC) finally merged my request.
No, not really. There are several other user friendly IRC clients but I generally don't like using desktop GUI applications on Linux. I could've just used The Lounge as I once did but I don't want to use my web browser to talk on IRC either. We're already bloating our web browsers more than needed these days and I would like to avoid input latency while I type my messages and switch to another channel. If I was richer than I am now, I could've also paid $6/month for IRCCloud for a supposedly user friendly experience. But if I did any of that, this blog post wouldn't exist and I wouldn't know how to use IRC in the way that I wanted.
The next step is to use glirc and senpai and decide which IRC client I want to use as a daily driver.
UPDATE: I started using glirc on 14th August, the day after I wrote this post, and I love its interface. It presents an option to use a two column layout which aligns usernames in one vertical split and the messages in another. I hate it when user messages are displayed below nicknames in IRC. It looks like a mess. A hopped inside the #glirc channel on libera.chat and thanked glguy for making an awesome terminal IRC client.
---
¹: This may change in the future thanks to Justine Tunney's work.
---
Updated: 2023-08-15
Created: 2023-08-13
-- Response ended
-- Page fetched on Fri May 10 20:47:16 2024