A file-based IRC client inspired by ii(1).
I originally only intended to write a frontend for ii instead of completely rewriting it from scratch. However, while working on the frontend I noticed that I couldn't implement certain features in the frontend without changes to the backend (ii). I briefly considered patching ii but ultimately decided for a rewrite.
During the rewrite various features have been implemented which could have been moved to separate tools, such as TLS support, hence the name harmful ii (hii).
New features (compared to ii):
- Memory safety
- A proper IRC protocol implementation through girc
- Support for automatically joining channels on startup
- Support for IRCv3.2 monitoring
- Support for a per-channel nick list using a UNIX domain socket
- Support for recording messages mentioning the users
- Support for authentication using TLS client certificates (CertFP)
- Built-in TLS support
- Built-in IPv6 support
Features intentionally not implemented:
- Automatic authorization using the PASS command is
not implemented (ii
- Shortcut commands, e.g.
/j. If you need them write yourself a shell script for mapping shortcut commands to real commands.
While hii has more features than ii it is still supposed to have a limit feature set and shouldn't "expand until it can read mail".
Backwards compatibility with ii wasn't a goal. While the directory structure is mostly backwards compatible everything else is pretty much different. This is the case because proper backwards compatibility would have been a lot of work and I personally didn't need it.
The program can be installed either using
go install or
To install to the program using
go install run the following command:
$ go install github.com/nmeum/hii@latest
Note that this will not install additional documentation files, e.g. man pages.
To install to the program using
make run the following commands:
$ git clone https://github.com/nmeum/hii.git $ cd hii $ make && make install
This will also install documentation files to the correct location and may thus be preferable when packaging this software for a distribution.
Q: Sockets cannot be used with standard utilities such as
Why are nick names served using a unix domain socket anyhow?
A: Several ways of implementing a nick list have been considered. Using a regular file has various obvious disadvantages. For instance, the file would need to be truncated every time the nick list changes, which causes a lot of file system operation. Using a FUSE for serving the nick list was also briefly considered, however, while this would allow interaction with standard utilities it would require linking against FUSE and would complicate things quite a bit. Serving nicks using a unix domain socket seemed to be a reasonable compromise.
Q: Why are mentions recorded in a separate file? Can't this be implemented using inotify, kqueue, … in the frontend?
A: While this might certainly be possible it would complicate the frontend code quite a bit. Implementing this in the backend was fairly easy and only required a few changes. Additionally, neither kqueue nor inotify are mandated by POSIX.
Q: Can feature X/Y/Z be added to hii?
This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
You should have received a copy of the GNU General Public License along with this program. If not, see http://www.gnu.org/licenses/.