Irssi review: the modular text mode IRC client, from Meson build to /HELP

What Irssi solves, and who is still typing in a terminal

Irssi is a text mode chat client. The README describes it as modular and says IRC support is built in, which is the distinction that matters: IRC is not a plugin you install, it is the core protocol, and everything else arrives as a module. The repository lists third party modules for ICB, SILC, XMPP, PSYC and Quassel, each maintained outside the main tree. So the target user is someone who wants IRC first and other networks only if a separate module exists and still builds.

The second constraint is the interface. There is no window, no mouse, no notification tray. The client draws into a terminal, and it is designed to be left running inside a multiplexer. That is the whole appeal for a certain kind of user: one process, one config file, one set of key bindings, reachable over SSH from anywhere. It is also the reason the project is the wrong choice for anyone who wants chat to look like a modern desktop application.

The project has been around long enough that its documentation is split between the website and the client itself. The README points at the new users guide, a questions and answers page, and the built-in /HELP command, and says the latter has all the details on command syntax. In practice /HELP is where you end up for anything specific, because the website cannot keep pace with every setting.

How the client is put together: C core, Perl scripts, protocol modules

The top level of the repository shows the shape of the thing: src/ holds the C sources, scripts/ and themes/ hold the bundled Perl scripts and colour schemes, docs/ holds documentation, and tests/ and fuzz-support/ exist alongside them. meson.build and meson_options.txt sit at the root, which tells you the build system is Meson and that optional features are toggled through build options rather than a configure script.

The dependency list in the README is short and old: glib 2.32 or greater, OpenSSL, Perl 5.8 or greater for Perl support, and terminfo or ncurses for the text frontend. Perl is listed as the scripting layer, and the scripts site linked from the README is the distribution point for community scripts. That combination, a C core with a Perl extension API, is why Irssi scripts tend to be small files that hook into signals and commands rather than full applications.

Themes are separate from scripts. The README links a themes gallery, and the themes/ directory in the repository holds the defaults. A theme controls colour and formatting; a script controls behaviour. Keeping those two apart means you can restyle the client without touching logic, which is a cleaner split than clients that let a single plugin redefine both.

One design consequence is worth stating plainly. Because IRC lives in the core and other protocols live outside it, the quality of non-IRC support depends on whoever maintains that module, not on the Irssi release cycle. The README lists those modules as third party, which is an accurate description and also a warning about where to file bugs.

Installing Irssi and connecting to a server for the first time

The README gives two source installation paths. The development path clones the repository and builds with Meson and Ninja, and it states the minimum versions as Ninja 1.8 and Meson 0.53. The commands are exactly these:

git clone https://github.com/irssi/irssi
cd irssi
meson Build
ninja -C Build && sudo ninja -C Build install

The build directory is named Build, and the install step needs root because it writes into the system prefix. If you would rather not install system wide, the README does not document an alternative prefix in the excerpt above; the INSTALL file is where the project says details live.

For a release tarball the procedure is nearly the same, with a signature check the README asks you to perform before unpacking:

tar xJf irssi-*.tar.xz
cd irssi-*
meson Build
ninja -C Build && sudo ninja -C Build install

Once installed, you start the client and connect. The README does not spell out the connect commands, but it does say the built-in /HELP has all the details on command syntax, so that is the reference to trust rather than any tutorial. The configuration lives in a file named irssi.conf, which appears at the top level of the repository as the sample configuration. The README does not document the exact search path the client uses for that file, so confirm it against your own installation before editing a copy you expect to be read.

Themes and scripts are added after the client runs, from the themes gallery and the scripts site the README links. Neither is part of the build.

Where Irssi gets awkward: configuration, packaging and protocol limits

The honest limitation is that Irssi expects you to configure it in text. There is no settings dialog and no validation layer that catches a typo before the client starts. The README points to /HELP for syntax, which means the authoritative reference is inside the running program, not on a web page you can search. If you are the kind of user who wants a preferences window, this is a mismatch, not a learning curve.

The second limitation is packaging lag. The most recent release listed for this repository is 1.4.5, dated 2023-10-03, while the last push to master was on 2026-09-23. That gap is normal for a mature C project, but it means distribution packages can sit on an older release for a long time, and a feature you read about in the repository may not be in the binary your package manager installs. Building from source is the way around it, and the README documents that path.

The third is protocol scope. IRC is in the core. Everything else is a third party module, and the README names ICB, SILC, XMPP, PSYC and Quassel as the available ones. If your team has moved to a protocol with no module, Irssi is not the tool, regardless of how comfortable you are in a terminal. The README does not claim a module for anything beyond that list.

Finally, the licence field on the repository is NOASSERTION, and the repository carries a COPYING file. That combination means you should read COPYING yourself rather than assume a standard licence from the metadata.

Irssi versus WeeChat: two terminal clients, two extension models

The comparison people reach for is WeeChat, and the difference is not cosmetic. WeeChat is built around a plugin architecture in C with its own scripting interfaces, and it treats multiple protocols as plugins from the start. Irssi inverts that: IRC is the core, and the module system is the extension point for everything else.

That inversion has practical consequences. On Irssi, the scripting language documented in the README is Perl, and the scripts site is the hub. On WeeChat, scripting is available through several languages and plugins are first class citizens. If your team already writes Perl and wants small hook scripts, Irssi's model is the shorter path. If you want to add a protocol and treat it as equal to IRC, WeeChat's design is closer to that goal.

A second difference is configuration philosophy. Irssi's settings live in irssi.conf and are edited as text. WeeChat also stores settings in files but exposes a large runtime command surface for changing them. Neither is objectively better; they suit different habits. The tiebreaker is usually which one your existing scripts and muscle memory already target.

The README does not compare Irssi to WeeChat or to any other client, so treat this section as a description of the two extension models rather than a verdict from the project.

Maintenance, upgrades and what the licence metadata does not tell you

The repository is not archived, and the last push to master was on 2026-09-23, so the codebase is receiving commits. The release cadence is slower: 1.4.3 in October 2022, 1.4.4 in March 2023, and 1.4.5 in October 2023. For anyone deploying Irssi, that means the practical upgrade unit is the distribution package, and the practical fallback is a source build from the tarball the README tells you to verify with a signature check.

Upgrade cost is low if you stay on packaged releases and do not carry local patches. It rises if you build from source, because you are then responsible for Meson and Ninja versions (the README states Ninja 1.8 and Meson 0.53 as minimums) and for the glib, OpenSSL, Perl and ncurses dependencies. It rises again if your setup depends on community Perl scripts, since those live outside this repository and are not covered by its release process. A script that breaks after a Perl upgrade is your problem, not a bug in the Irssi tree.

On licensing, the repository metadata reports NOASSERTION, which is a signal that the machine readable field was not filled in, not that the project is unlicensed. The COPYING file at the top level is the document that matters. Read it before you redistribute a build, and if you are embedding Irssi in a product, have someone qualified read it with you. This article is not legal advice and cannot substitute for that.

Editorial conclusion

Adopt Irssi if you want an IRC client that runs inside a terminal or a tmux session and whose configuration is a text file you can version. Do not adopt it if you need a graphical interface, a built-in bouncer, or a protocol that is not IRC and has no third party module. Before committing, verify three things: that your distribution's Irssi package is 1.4.5 or that you can build from source with Meson and Ninja, that irssi.conf is the file your build actually reads, and that the Perl scripts you depend on still load under your Perl version.

Frequently asked questions

Official sources

1. irssi/irssi on GitHub
2. Issues
3. Project website
4. README
5. Releases