halloy: a Rust IRC client with thirty-four IRCv3 capabilities and a font as its default feature

Simple and fast is the entire pitch

The description is two clauses long and both are about restraint. Halloy is an open-source IRC client for macOS, Windows and Linux, focused on being simple and fast. There is no feature narrative around that, and the readme has no architecture section, no configuration reference and no screenshots beyond a link to an xkcd comic in a section titled Why. What it does offer is a documentation site at halloy.chat and an invitation to join the halloy channel on libera.chat for questions or help, which tells you where the real explanation lives. The footer of the file links the iced project, which is the graphical framework the interface is built on, so the client is a desktop application rather than something that runs in a terminal.

Thirty-four capabilities, four of them formatted differently

The capability list is the readme's body, and it is long enough to be a specification. It runs from account-notify and away-notify through batch, bot mode, cap-notify, channel-context, chathistory, chghost, echo-message, extended-join, invite-notify, labeled-response, message-redaction, message-tags, metadata, Monitor, msgid, multi-prefix, multiline, network-icon, no-implicit-names, react, read-marker, reply, sasl-3.1, server-time, setname, Standard Replies, typing and userhost-in-names, ending with UTF8ONLY, WHOX and the two soju entries. One formatting detail survives the cleaning: the last four entries are wrapped in inline code while every other one is plain link text. Nothing in the file says which capabilities are required or which degrade gracefully.

Metadata carries six keys, including pronouns and colour

One capability is expanded rather than just named. The metadata extension is listed with its own set of keys: display-name, avatar, pronouns, homepage, color and status. That is a client-agnostic way of carrying profile information on a channel, and the list is the interesting part because it reveals what the interface can show about a person beyond a nickname, including a preferred display name and a colour.

Two capabilities are specific to the soju bouncer

The last two entries are the reason a network operator might care about this client. One is a bouncer networks capability under the soju.im namespace, which lets a client see the list of networks a bouncer holds, and the other is soju.im/filehost under the same namespace. Neither is part of the IRCv3 specification proper; both are extensions to a particular bouncer implementation. So the client speaks ordinary IRCv3 with about thirty extensions, plus two that only mean something if the server behind the connection is that particular bouncer. The presence of SASL 3.1 in the same list points the same way, toward networks with modern authentication.

Three distribution channels and two installer directories

Installation is delegated to documentation rather than described, with a link to the installation page on halloy.chat. Beyond that the file names the channels: a Repology badge showing packaged versions, Flathub under the identifier org.squidowl.halloy, and the Snap Store. The repository carries the packaging itself, with an inno directory for a Windows installer toolchain. There is also a NIGHTLY file at the root next to VERSION, which is the visible sign that the nightly channel is a distinct thing from the date-named releases, matching a release list where 2026.9 and 2026.8 sit alongside a separate nightly entry.

The default feature is a font, and Tor is an opt-in flag

The manifest is short and its feature table is unusual:

[features]
default = ["iosevka-font"]
iosevka-font = []
tor = ["data/tor"]

A default feature that bundles a font tells you the client ships its own typeface rather than depending on one installed on the machine, and the empty feature body means it is a pure on or off switch with no configuration. The tor entry is different in kind: it forwards to the tor feature of the data crate, so enabling it is a one-flag decision that pulls in the dependency. Everything else in the table is absent, which means there is no feature flag for the IRC capabilities, no toggle for the bouncer extensions, and nothing to configure per platform from the build side.

Four workspace crates, edition 2024, and a version of 0.1.0

The workspace is small and its members say what the client is made of:

[workspace]
members = ["data", "ipc", "irc", "irc/proto"]

A data crate, an inter-process communication crate, an irc crate and a protocol crate inside it, with the interface code outside them in the package itself. The workspace package block sets edition 2024, three named authors, and the licence as GPL-3.0-or-later, which is slightly more permissive in wording than the GPL-3.0 named in the readme and in the repository metadata. The workspace version is 0.1.0 while the released tags are date-named, so the crate version in the manifest is not the version a user installs from Flathub, and there is no mapping between the two stated anywhere in the file.

The HTTP client is configured by hand, with socks and proxies

One dependency entry is worth reading closely because it explains how the client reaches a network. The HTTP client is declared with default features turned off and an explicit list of features instead: charset, http2, json, the rustls-no-provider TLS feature, socks, stream and system-proxy. Two of those are the answer to a question the readme does not ask. Socks support is what lets the client work through a local proxy or a bouncer tunnel, and system-proxy is what lets it respect the proxy already configured on the machine. The GUI framework is a prerelease, pinned to a 0.15.0 development version with its own default features disabled, which tells you the client tracks a moving target upstream. Around those sit small crates for colour, relative timestamps and fuzzy matching.

Editorial conclusion

halloy fits someone who wants a native IRC client on a modern desktop and cares about the extension set a network advertises, particularly if that network runs a soju bouncer, since two soju-specific capabilities are supported. It does not fit a user who wants a mobile client or a terminal-only client, since none is described. Before you rely on it, check four things: whether your network advertises the capabilities you actually use, since the client can only use what the server offers, whether the release you install is the date-named channel such as 2026.9 or the separate nightly build, whether the prerelease version of the GUI framework it tracks is acceptable to you, and whether the tor feature and proxy-aware HTTP client cover the network you need to reach.

Frequently asked questions

Official sources

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