Abaddon: the C++ Discord client whose roadmap outran its own README

What the feature list is actually selling

The README opens with ten bullets and the first two are the argument: `Not Electron` and `Voice support`. That ordering is a reply to the two objections alternative Discord clients hear most, and it tells you what kind of project this is before any build instruction appears.

The rest of the list is quietly more capable than the stereotype suggests. It claims embeds, images and replies; kick, ban and unban; role modification on both members and roles; invite and emoji management; and an audit log. Also DM and group DM creation, user profiles with notes and mutual servers, unread and mention indicators, and a set status control. Animated avatars, server icons and emoji, with a note that they can be turned off.

Two bullets carry an asterisk that is easy to skim past. Thread support is marked as having known inconsistencies, and the emoji bullet is followed by a footnote about how emoji are substituted. Both are honest limitations rather than omissions, and both are discussed further below.

The metadata fits the pitch. C++, GPL-3.0, 2,224 stars and 94 forks, last pushed 2026-09-09, not archived. The fork count against the star count suggests a project people run rather than one people contribute to, and 111 open issues is a real backlog for a single-maintainer codebase.

The rewrite the README does not mention

The release notes contradict the build instructions, and this is the most important thing to understand about the repository before you install anything.

v0.2.3, published 2026-02-09, opens by announcing that a Qt6 rewrite is under way, with functional parity targeted at roughly a month out. The stated reason is blunt: the GTK codebase combined with MSYS2 on Windows caused so many headaches that the maintainer burned out on it. That note also says end-to-end encrypted voice will not be implemented in Abaddon, which Discord would enforce from March 1, and that the rewrite would support it instead.

Then v0.2.4, published 2026-04-06, opens with `I said I wouldn't but for a handful of reasons I basically had to` and adds DAVE E2EE voice call support anyway, alongside OpenBSD resource path handling and Flathub tweaks. The promised exclusive feature of the replacement shipped on the old codebase two months after the promise, and the rewrite is still described as coming.

The README does not reference any rewrite. It documents CMake, Ninja and MSYS2 for a GTK client, with no note that the architecture is being replaced. A reader who installs from these instructions is choosing the older design on purpose or by accident, and the repository does not say which.

Five build recipes and what they reveal about portability

Manual building is the recommended path on every platform except Windows, and each platform gets its own dependency list. Windows uses MSYS2 with a Ninja generator and Release info:

cmake -GNinja -DCMAKE_BUILD_TYPE=RelWithDebInfo ..
ninja

Linux instructions are distro-specific and unusually honest about it. Ubuntu and Debian get a single apt line:

$ sudo apt install g++ cmake libgtkmm-3.0-dev libcurl4-gnutls-dev libsqlite3-dev libssl-dev nlohmann-json3-dev libhandy-1-dev libsecret-1-dev libopus-dev libsodium-dev libspdlog-dev

Arch gets the equivalent pacman call. Void is the outlier: it installs a core set with xbps-install and then builds nlohmann/json from source through meson, six commands to get one header-only library. Fedora gets dnf, plus a note that older releases want `gtkmm30-devel` instead of `gtkmm3.0-devel`. FreeBSD gets a single `pkg install` line.

The dependency set tells you what the client actually does. gtkmm and libhandy for the interface, libcurl for HTTP, SQLite for local state, libssl plus libsodium and libsecret for cryptography and keyring access, Opus for voice, spdlog for logging. Every one of those is a native library, which is the concrete meaning of the not-Electron bullet.

Resources live in two folders under `res`, with `fonts` needed on Windows, and `abaddon.ini` is read from the working directory first and then from `~/.config/abaddon/abaddon.ini`. CSS and resources can also load from `~/.local/share/abaddon`.

Impersonating the web client, in writing

The fifth feature bullet is the most unusual thing in the README: it identifies to Discord as the web client, unlike other clients, so it is less likely to be falsely flagged as spam. A footnote explains the mechanism.

Abaddon tries to make Discord believe it is a legitimate web client by using a browser user agent, sending the same IDENTIFY message the official web client sends, using API v9 endpoints throughout, and avoiding endpoints the web client does not normally call. The footnote is candid that this is not complete. The web client sends telemetry through the `/science` endpoint and in request headers, which uBlock origin stops, and a few smaller inconsistencies remain.

The README gives the whole section its own heading and expands on why. Discord disables accounts and forces password resets when it decides a user is a spam bot or compromised, and third-party clients provoke that decision more often than the official app. It notes that joining or leaving servers is the usual trigger, and it links the account appeal path.

This is the part of the project with a genuine ethical weight, and the README does not pretend otherwise. Deliberately mimicking a client to pass an abuse heuristic is a decision a maintainer makes about their users' account risk, and documenting it in the open is better than the alternative many alternative clients choose.

Two footnotes that admit the seams

A README that documents its own sharp edges is worth more than one that lists only successes, and Abaddon has two footnotes doing that work.

The first covers emoji rendering. Unicode emoji are substituted manually on non-Windows platforms instead of being drawn by GTK, and the behaviour flips with the `stock_emojis` setting. On Windows, a CBDT-based font using Twemoji is bundled so GTK can render them natively. In other words, the emoji you see on Linux are not the emoji path Windows takes, which is the kind of cross-platform divergence that only shows up once you switch machines.

The second covers threads. The README states there are inconsistencies with thread state in some more uncommon cases, then attributes them to fundamental issues with Discord's own thread implementation. That is a claim you cannot fully verify from outside, and it is the sort of sentence that can be either an honest diagnosis or a shield. The fact that it appears next to an explicit warning rather than in place of one is the better sign.

There is also a hard limit worth naming. The README's guidance on token acquisition is a single line linking to a comment on an unrelated issue in DiscordChatExporter. For a client that stores credentials directly, that is thin documentation, and it is another reminder of single-maintainer scope.

What the tree says about the rewrite

The directory listing is short and points at a conventional C++ project. There is a `.clang-format`, a `CMakeLists.txt`, a `cmake/` directory, `ci/`, `src/`, `res/` and `subprojects/`, which matches the README's instruction to clone with `--recurse-submodules="subprojects"`. A checked-in `compile_commands.json` suggests a clangd or IDE workflow, with no separate editor config directory to do it.

Two entries do not fit a C++ application. `.readme/` holds the screenshots referenced in the table at the top, and `.lapce/` is the configuration directory for Lapce, an editor built on the same CRTP architecture as Zed rather than a file layout convention. Both are developer tooling rather than product surface, and both are signs of one person making their own environment reproducible.

The release line tells the rest of the story. v0.2.2 shipped in June 2025 with stages, voice-channel chat and a long fix list including voice itself, crashes, identify messages and a DBus id change to `io.github.uowuo.abaddon`. v0.2.3 followed in February 2026, v0.2.4 in April, and the last push was in September 2026 with no new release since. The repository is being worked on while the version the README documents is the version being replaced, and the gap between those two facts is the real state of this project.

Editorial conclusion

The most useful thing about Abaddon is that it is legible. Six of its ten feature bullets are things official clients barely do well, the build recipes are copy-pasteable per distro, and the author documents his own rough edges in footnotes instead of hiding them. What it is not is settled: v0.2.3 announced a Qt6 rewrite to escape the GTK and MSYS2 toolchain, and v0.2.4 shipped a feature that release had said would only ever arrive in the replacement. Clone the tree if you want to read the CMake wiring and the 111 open issues; pull a release build only if you are deliberately choosing the older architecture, and check the `stock_emojis` setting before you conclude your emoji are broken.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. Releases
5. uowuo/abaddon on GitHub