hii's Introduction

hii

A file-based IRC client inspired by ii(1).

Motivation

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 that are not supported by ii (e.g. various IRCv3 features, builtin TLS and IPv6 support, et cetera).

Status

I currently consider hii feature complete and use it myself daily in combination with insomnia and a per-server runit user service for automatically starting and supervising hii processes.

Features

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)
- Most IRC networks support CertFP
- This can be used in conjunction with the SASL EXTERNAL mechanism
Built-in TLS support
Built-in IPv6 support

Features intentionally not implemented:

Automatic authorization using the PASS command is not implemented (ii -k flag).
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.

Installation

The program can be installed either using go install or make.

go install

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.

make

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.

FAQ

Q: Sockets cannot be used with standard utilities such as grep(1). 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?

A: No.

License

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/.

hii's People

Contributors

Stargazers

Watchers

hii's Issues

Usability concepts

Hey there. I'm a long time ii user who has invested quite a bit of time in brainstorming how to improve its usability and writing my own version of an ii-like irc client. I've just found your project and wanted to share some of the concepts I came up with. It's mostly things which make front-end development a lot easier so I was surprised you don't do some of those things in hii. Maybe you find some of it useful.

For instance, it's very hard to figure out your own nick, which you need to know if you want to display your own messages differently or if you want to highlight messages mentioning your nick. It's way easier to do this in the back-end instead and simply prefix ones own nick (and surround every mention of it in messages from others) with some unprintable character. Not a pretty solution, but this is the easiest to parse in the front-end. You can pipe a snippet of a log to your front-end and it will be able to highlight your own messages even if you don't know what nick you used at the time.

My back-end writes quite a bit of information to different files. That includes a list of joined channels, own nick, (per channel) channel topic and channel users (nicklist). Since I was also afraid of too frequent writes, I have those files and the in-fifos reside in tmpfs/shm. I recently thought about extending this even further and ignore MOTD and other info messages send at the beginning of a connection and simply write them to separate files (motd & server_info). That way, connecting will only ever generate a handful of messages instead of the excessive log spam.

Another big usability problem with an ii-like client is keeping track of new private message channels (I will call it query). A solution is to manually check by using ls or something like inotifywait. Much easier to write a message to the root log if a new query channel was created. I also do this for highlights. That way it's easy to monitor important events in one central location.

For channel auto-join, I made the back-end execute external files for certain events like on_connect, on_highlight, on_join, on_query etc. It checks if the respective file is executable and runs it, handing over a bunch of useful arguments (mostly your own nick and the path to the in-fifo). I think this is the most KISS, unixey and flexible way of doing automation. For instance, I do my channel auto-join in on_connect (in my case simple #!/bin/sh) and mobile notification push-service in on_query and on_highlight. I have on_ctcp in case I want to reply to simple requests like VERSION, PING etc. With on_join it's also very easy to automatically open new tmux windows when joining channels.

With all of this, my front-end is quite usable which basically consists of a 63 loc awk formatter script and a couple lines in some of the on_* files.

Recommend Projects

nmeum / hii Goto Github PK