# Quassel: an IRC client you can detach from > Quassel is a graphical IRC client with a split architecture, where one or more clients attach to a central core that keeps the network connection and the backlog, so a client can close and reopen without losing the conversation. The core is configured on the command line and the project is free software under the GPL. **quassel/quassel** — Quassel IRC: Chat comfortably. Everywhere. - Repository: https://github.com/quassel/quassel - Website: https://quassel-irc.org/ - Stars: 792 · Forks: 226 - Language: C++ - License: NOASSERTION - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/quassel-quassel ## The split that defines the project Quassel is described as a modern, cross-platform, distributed IRC client, meaning that one client or several can attach to and detach from a central core, much like the popular combination of a screen multiplexer and a text based IRC client such as WeeChat, but graphical. That comparison is the clearest way to understand the architecture. Screen and a terminal client let you leave a session running on a server and reconnect to it later. Quassel does the same thing for a graphical client: the core holds the connection to the network and the scrollback, and the client is a view onto that state. The reason it matters is that IRC has a long memory. Your client is where the backlog lives in a single process IRC client, and closing it loses the scrollback and drops the connection, so you reconnect, catch up on what you missed by reading a lot of lines, and any message you did not read while away is gone for good. With a core, that history is on the server and is simply there when you come back. The project is free software, distributed under the GNU General Public Licence, and the README puts it plainly, free as in beer and as in speech, with an invitation to download it and see for yourself. The client is written in C++, and the project page is quassel-irc.org. ## The core is configured from the command line The core has a first run behaviour that is worth understanding before you deploy it. On the first run of the Quassel core, it waits for a client to connect and presents a wizard that allows you to create the database and one admin user for the core side storage. So the very first thing a client does is initialise the server, which is a slightly unusual but sensible design: the wizard has a graphical front end rather than a text configuration file to hand edit. After that setup, the README lists the three command line operations you will actually use. Adding more users is done with the core executable and an add user flag. Changing the password of an existing user takes a flag with the user name. And the core has a help flag that lists every available option. On some systems you may need to specify a configuration directory, for example when the core runs as a service and the default location is not writable or is not where you want the state. The README gives the example of pointing it at a directory under a system path. That is the whole operational surface. A Quassel core is a single process with a handful of flags, and the configuration that matters is the database it creates on that first run. ## Where to get a build, and how much to trust it The download story has three tiers, and the README is careful about the difference. Official stable builds are on the Quassel IRC download page. Those are the ones to use if you want a supported build. Untested automated builds are available for Windows and for macOS through a nightly build service, with the page attributing the setup to the maintainer who set it up. The README is explicit that these are untested, and it also points out that if you are logged in to GitHub you can pick any build from the continuous integration tab instead, which is the same thing with more choice. Then there are unofficial builds and testing versions contributed by several community members, listed in the project wiki under unofficial builds. The three tiers tell you something about the state of the project. There is a stable release line that is maintained for downloads, a nightly stream that tracks the branch, and a community layer on top for platforms and configurations the team does not build. The release notes live on the project homepage and in the change log file in the repository, so both the packaged release and the development branch are documented. ## Translations, packaging and the repository layout The repository layout is that of a mature desktop application, and it shows the platforms the project covers. There is a src directory for the implementation, an interfaces directory for the user interface definitions, a data directory for the data files, icons and pictures for the artwork, a translation directory for the localised strings, a third party directory for vendored code, a cmake directory and a top level CMakeLists file for the build. The build system is CMake, with a clang format configuration for the C++ style, and the Doxyfile means the API documentation is generated with Doxygen. Packaging is present for more than one ecosystem. There is a snapcraft file with a wrapper script for the Snap format, which matters because IRC is a use case where a confined package has obvious appeal. On Windows there is a craft settings file for the build pipeline, and the third party directory and the git modules file point at dependencies that are pulled in rather than vendored directly. The translation workflow is the usual open source one. The po directory holds the message catalogues, and the configuration directory at the root is the Transifex one, which is the platform many projects use to let translators contribute without a git workflow. The dev notes directory suggests the internal documentation lives beside the code. Version information comes from a template file that the build fills in, so the version number exists in exactly one place. ## Getting help and reporting problems The getting involved section is short and specific, and the first line is the one that tells you what kind of project this is. IRC is the preferred means of getting in touch with the developers. The Quassel IRC Team can be contacted on the Quassel channel on Libera Chat, or on the German channel. If you have trouble getting Quassel to connect, you can use the web client for Libera Chat instead of installing a client, which is a considerate thing for a project whose own client some users cannot install. For problems, the bug tracker is a separate site at the Quassel project's own bug system, and the README makes a point that is worth repeating: GitHub issues are not used, but pull requests are accepted. So the division is deliberate. Discussion happens on IRC, bug reports go to the tracker, and code changes come in as pull requests on GitHub. That is an unusual split by current standards, where most projects funnel everything through GitHub issues, and it is the shape of a community that formed on IRC before GitHub issues became the default. There is also a developer mailing address, and the README signs off as the Quassel IRC Team. The project wiki is where the deeper documentation lives, and the README recommends the getting started guide there for anyone setting up a core. ## The maintenance question, stated plainly The facts about maintenance need to be stated carefully, because they pull in two directions. The release tags are Quassel 0.14.0 from 2022-01-01, and the two release candidates before it, 0.14-rc2 from 2021-10-12 and 0.14-rc1 from 2021-01-03. So the newest tagged release in the repository is from the start of 2022. And yet the last push to the repository was on 2026-06-27, which is far more recent. So the branch is being worked on, and the change log in the repository is where those changes are recorded. The practical reading is that the project is maintained on the branch rather than by cutting new tagged releases, which is common for a client whose stable line is widely packaged by distributions. If you install from a distribution package you will get the stable line, and if you want the branch you need to build it yourself or take one of the nightly or community builds. That gap between the tagged release and the branch is the single most important thing to check before you commit to this project, and it is also the most likely reason to reach for a different client. Two further details from the README bear on expectations. The nightly builds are described as untested, and the community builds are unofficial. Neither is a reason to avoid the project, but both are reasons to test rather than deploy blindly. And the overall tone of the readme, with its invitation to new users in the channels and its bug tracker and mailing list, is that of a mature community project rather than one in decline. ## Conclusion Quassel suits an IRC user who wants a graphical client without losing the channel history every time their laptop sleeps, since the core keeps the connection and the backlog and the client is a view onto it, and it suits anyone running a persistent IRC presence on a small server. It is the wrong choice if you want a single self-contained application with no server to run, and it is the wrong choice if your priority is a modern client with active development, since the last tagged release in the repository is 0.14.0 from 2022 even though the branch is still being worked on. Verify first which upstream releases your package provides, whether the nightly builds are acceptable for you given they are described as untested, and that the bug tracker rather than GitHub issues is where your report will be seen. ## FAQ ### What is Quassel IRC? It is a modern, cross-platform, distributed graphical IRC client, where one or more clients attach to and detach from a central core that holds the connection and the backlog, comparable to using screen with a text client but graphical. ### How do I create a user on a Quassel core? On the first run the core waits for a client and presents a wizard to create the database and one admin user, after which you add more users with the add user flag and change a password with the change user pass flag. ### Where should I report a Quassel bug? On the Quassel bug tracker at bugs.quassel-irc.org. The README states that GitHub issues are not used, while pull requests are accepted, and that IRC on Libera Chat is the preferred way to reach the developers. ### Which Quassel builds are officially supported? Official stable builds are provided on the Quassel IRC download page. Untested automated builds for Windows and macOS are published through a nightly build service, and community members contribute unofficial builds and testing versions listed in the wiki. ## Sources - [Issues](https://github.com/quassel/quassel/issues) - [Project website](https://quassel-irc.org/) - [quassel/quassel on GitHub](https://github.com/quassel/quassel) - [README](https://github.com/quassel/quassel/blob/master/README.md) - [Releases](https://github.com/quassel/quassel/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/quassel-quassel