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
- Built-in TLS support
- Built-in IPv6 support
Features intentionally not implemented:
- Automatic authorization using the PASS command is
not implemented (ii
-kflag). Use authorization using TLS client certificates (CertFP) instead. Most IRC networks support CertFP.
- 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".
Compatibility with ii
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 get or
GNU make. The
latter automatically configures
GOPATH and is the preferred way of
installing this software when packaging it for a distribution.
To install to the program using
go get run the following command:
$ go get github.com/nmeum/hii
To install to the program using
GNU make run the following commands:
$ make $ make install
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/.