Halloy: an IRC client in Rust for macOS, Windows and Linux

The problem Halloy solves, and for whom

IRC clients split into two camps. One camp is the old guard: mature, feature-heavy, and often carrying a toolkit that looks a decade old. The other camp is the terminal client, which is fast but forces you into a multiplexer if you want more than one network visible at once. Halloy sits between them. It is a graphical IRC client for macOS, Windows and Linux, written in Rust, and the README describes it as "focused on being simple and fast."

The audience is narrower than "anyone who uses IRC." Halloy is for people who already know what a network, a channel and a bouncer are, and who would rather write a config file than click through a wizard. The repository ships a config.toml at the top level, and the related searches around "halloy config" and "halloy themes" suggest that configuration is the part users actually go looking for. If you want a client that discovers servers for you, this is not that.

The second audience is the IRCv3 crowd. The README says the project strives "to be a leading irc client with a rich IRCv3 feature set," and then lists the capabilities it supports. That list is the real product statement. A client that implements chathistory, read-marker, message-redaction and typing behaves differently from one that treats IRC as plain text over a socket.

What the IRCv3 capability list actually buys you

The README enumerates the supported capabilities, and the interesting ones are the modern extensions rather than the basics. chathistory lets the client request scrollback from the server instead of showing an empty window when you join. read-marker synchronises where you stopped reading across clients. message-redaction handles deletion. multiline and typing make composition closer to what people expect from a chat app. metadata covers display-name, avatar, pronouns, homepage, color and status, which is how a client can show more than a nick.

The bouncer entries matter too. The list includes soju.im/bouncer-networks and soju.im/filehost, plus Monitor, extended-join, account-notify and away-notify. This tells you the client was built with a persistent-connection setup in mind rather than as a standalone connect-and-quit tool. Search interest in "Halloy soju" and "Halloy ZNC" points the same way: people are running Halloy in front of a bouncer.

What the README does not give is a compatibility matrix. It does not say which servers implement which capability, and it does not say what Halloy does when a server advertises nothing. Capability negotiation normally degrades gracefully, but the documentation here is a list, not a specification of fallback behaviour. If your network is an old ircd, you are reading the list and guessing.

Installing Halloy and connecting to a first network

The README does not put install commands inline. It points to an installation documentation page at halloy.chat, and it states that Halloy is also available from Flathub and the Snap Store. So the first step is to check that page for your platform, because the exact package name and channel are maintained there rather than in the repository README.

The README gives the Flathub listing as org.squidowl.halloy and the Snap Store listing as halloy, but it does not reproduce the install commands themselves. Follow the installation documentation for the exact command on your platform.

After installation, the working surface is the configuration file. The repository root contains config.toml, and the project documentation at halloy.chat covers its contents; the README itself does not reproduce the schema. The practical first use is to open that file, define a server entry and a nick, save, and restart the client so it re-reads the config. Because the README does not document the keys, treat the documentation site as the authority for field names rather than copying a snippet from a blog post. The related searches for "Halloy password" and "Halloy ubuntu" suggest people hit both the credential question and the packaging question early, which is consistent with a client whose setup lives in a file and whose install lives on a separate page.

Where Halloy is the wrong tool

The clearest limitation is the one the README creates by omission. There is no documented settings UI, no guided server list, and no inline config reference. A new user who does not know the config.toml schema has to leave the repository to find it. If you are setting up IRC for someone who will not edit a text file, Halloy is a poor fit.

The second limitation is the feature surface. The IRCv3 list is long, but it is a list of protocol capabilities, not of client features. Scripting, plugins and automation are not mentioned in the README at all. Users coming from scriptable clients will find no documented extension point here.

The third is platform packaging. Halloy is available from Flathub and the Snap Store, and the installation page covers the rest, but the README does not claim a package in every distribution's native repository. On a distribution without one of those channels, you are building from source, and the Cargo.toml shows a workspace with members data, ipc, irc and irc/proto plus an iced dependency pinned to 0.15.0-dev. That is a development-track GUI toolkit version, which is a real consideration if you plan to build repeatedly rather than install a release.

Finally, the tor feature is opt-in, not default. Cargo.toml defines default = ["iosevka-font"] and tor = ["data/tor"]. If anonymity through Tor is part of your threat model, you have to enable it deliberately, and the README does not explain how.

Halloy against a terminal client such as WeeChat

The honest alternative for a Rust-averse or terminal-first user is WeeChat. The difference is not cosmetic. WeeChat runs inside a terminal and is extended through scripts; Halloy is a native windowed application built on iced, with the GUI toolkit as a direct dependency in Cargo.toml. That means Halloy gets real window management, native fonts and the iosevka-font default feature, and it does not need tmux to show several networks side by side.

The cost runs the other way. A terminal client is scriptable and remote-friendly: you can attach to it over SSH. Halloy, as a windowed application, is not described that way in the README. If your workflow is a persistent session on a server that you attach to from anywhere, the terminal client is the more natural fit, and Halloy pairs better with a bouncer like soju than with an SSH session.

A second comparison point is the bouncer itself. Running soju or ZNC gives you scrollback and a stable presence regardless of client. Halloy's soju.im/bouncer-networks support means it can talk to that layer directly, so the two are complements rather than competitors. If you already run a bouncer, Halloy's capability list is the reason to pick it over a client that ignores those extensions.

Maintenance, licensing and upgrade cost

The repository is not archived, and the last push was on 2026-06-05. The release list shows a nightly build dated 2026-06-05, version 2026.8 dated 2026-07-26, and 2026.7.2 dated 2026-06-08. The version scheme is calendar-based, so 2026.8 is the release to look at for a current build, with 2026.7.2 as the preceding point release. A nightly channel exists alongside the dated releases, which means there is a build for people who want unreleased changes and accept the risk that comes with it.

Upgrade cost is low if you install from Flathub or the Snap Store, since those channels handle versioning for you. It is higher if you build from source, because the workspace pins iced to 0.15.0-dev and edition 2024, so a toolchain that satisfies those requirements is a prerequisite for every rebuild.

The licence is GPL-3.0-or-later according to the workspace package metadata, and the README states Halloy is released under the GPL-3.0 License, with details in the LICENSE file. For individual use this changes nothing. For anyone embedding Halloy in a distributed product, the copyleft terms are the thing to read before you plan around it. The repository also carries a CODE_SIGNING_POLICY.md and notes that free code signing is provided by SignPath.io, which is relevant if you are deciding whether to trust a downloaded binary or build your own.

Editorial conclusion

Adopt Halloy if you want a native IRC client that tracks IRCv3 capabilities closely and you are comfortable editing config.toml instead of clicking through a preferences dialog. Skip it if you need a graphical setup wizard for many networks, or if you rely on a bouncer feature the README does not list. Before committing, verify three things: that your distribution has a package on the installation page, that your network or bouncer supports the capabilities you depend on, and that the GPL-3.0-or-later terms fit how you intend to redistribute the build.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes