Concord: a Rust TUI client for Discord

What Concord replaces, and for whom

Discord ships a desktop client built on Electron and a browser client. Both expect a mouse, a window manager, and a few hundred megabytes of memory. Concord is the opposite bet: a single Rust binary that draws the same conversations into a terminal cell grid using ratatui, the same library family behind many Rust TUIs. The README describes it as "a feature-rich TUI client for Discord, written in Rust with ratatui", and the Cargo.toml package description is the narrower "A terminal user interface client for Discord".

The audience is narrow on purpose. If you keep a tmux session open on a remote box, or you work on a machine where a browser tab per server is unwelcome, a text client removes a context switch. The feature list goes further than a minimal chat reader: voice calls with push-to-talk, noise suppression, watching and broadcasting screen shares, forum and media post browsing, message search, and inline image rendering. That is a lot of surface area for a terminal program, and it is the reason the install section is longer than a single cargo command.

How Concord talks to Discord and draws to your terminal

Concord is not a protocol reimplementation. The dependency list shows reqwest with rustls, cookies, gzip, brotli and zstd, plus reqwest_cookie_store and cookie_store. In practice that means Concord speaks to Discord over HTTP with a cookie jar and compressed responses, the way a web client would, rather than through a separate gateway library. Authentication follows from that: token, email and password with MFA, or a QR code scanned from the mobile app.

Rendering is split between two crates. ratatui handles the layout and widgets, and ratatui-image handles images. On startup, according to the README, Concord queries the terminal to detect the best available graphics protocol. The supported set is Kitty Graphics Protocol, iTerm2 inline images, Sixel, and halfblocks as a fallback that works anywhere but draws block characters instead of pixels. That detection step is the single most environment-dependent part of the program: the same binary looks different in Kitty, foot, and a bare xterm.

Voice and streaming sit on native code. cpal is listed with the pulseaudio and realtime features for audio capture and playback, and davey appears alongside it. Screen sharing uses native H.264 hardware encoding where available: VA API on Linux, VideoToolbox on macOS, Media Foundation on Windows, with a software fallback when hardware encoding is unavailable. That is why the release notes matter here. The README states plainly that release builds include voice playback and stream broadcasting, which implies a source build can be compiled without them.

Installing Concord and logging in with a token

The README lists five install paths. Cargo compiles locally, Homebrew and npm pull a package, Nix has both a nixpkgs attribute and a flake reference, and Gentoo goes through a community overlay that the README notes is not yet in GURU. The shortest path, if you already have a Rust toolchain, is:

cargo install concord --locked

The --locked flag pins the dependency versions in Cargo.lock. Cargo.toml requires Rust edition 2024 and rust-version 1.90, so an older toolchain will refuse the build rather than fail later. If you would rather not compile, the release installer script is documented for Unix and PowerShell, and the README says the installer places concord under $CARGO_HOME/bin.

On Linux the binary links against system libraries. The README gives per-distribution commands, for example:

# Debian or Ubuntu
sudo apt install libasound2 libegl1 libpipewire-0.3-0 libva-drm2 libva2 xdg-desktop-portal

Screen sharing additionally requires the portal backend for your desktop environment. Skip that and voice may work while broadcasting does not.

For login, the README recommends token authentication over email or QR, because those two flows may trigger a CAPTCHA challenge on Discord's side that Concord cannot solve. You can paste a token interactively, or set an environment variable before launching:

CONCORD_TOKEN=your-token concord

The README states that CONCORD_TOKEN overrides every credentials.store mode, meaning auto, keychain and plain. By default tokens go to the system keychain when one is available, and in auto mode Concord falls back to its state directory when keychain storage is unavailable. That fallback is worth knowing about before you run it on a shared machine.

Inside the client, the README documents a fuzzy channel switcher bound to Space, Space, with a leading * in the query to search servers instead. Message search uses /. Voice shortcuts are leader-prefixed, for example <leader>vs to share a screen. External media playback is off by default and must be enabled from the Display options menu; it requires mpv on your PATH.

Where Concord is the wrong tool

The README is candid about the login flows, and that candour is the first limitation. Email, password and QR logins can hit a CAPTCHA that the project states it cannot solve, so the recommended path is pasting a token. A token is a credential with the full authority of your account. Anyone who can read your shell history, your environment, or the state directory in the auto fallback mode has your account. That is a real operational cost, not a footnote, and it is the main reason to think twice before putting Concord on a shared or multi-user host.

Media support is the second boundary. External playback depends on mpv being installed and in your PATH, and YouTube playback depends on your local mpv setup such as yt-dlp support. Concord does not bundle a player. Inline images depend entirely on terminal protocol detection; on a terminal that only offers halfblocks, images degrade to block characters. If your terminal is a plain xterm without Sixel compiled in, you get the fallback.

The third boundary is the one the README is silent on. There is no documented stability policy, no statement about what happens when Discord changes its API, and no rollback guidance. The repository has a CHANGELOG.md and release cadence is visible in the release list, but the README does not document rollback, deprecation windows, or which Discord API version Concord targets. If you need a client with a support contract or a written compatibility guarantee, this is not it.

Finally, this is not a lighter Discord for everyone. The runtime requirements include macOS 13 or later and a list of native packages on Linux. On a headless server with no audio stack, voice and streaming are dead weight, and you would want the source build without them.

Concord against a browser client and against a scripted bot

The obvious alternative is the official Discord client, desktop or web. The difference is not features, it is the interface model. Discord's client is a renderer with a full widget toolkit; Concord is a cell grid. Discord gives you notifications, a tray icon, per-server unread badges and a settings UI that a non-technical user can navigate. Concord gives you keyboard-driven navigation, a fuzzy switcher, and the ability to run inside tmux over SSH. If your work happens in a terminal, that trade is worth it. If it does not, it is not.

A second alternative is a bot or a script using a Discord library, which is a different shape entirely. A bot authenticates as its own account, cannot read your direct messages, and cannot act as you. Concord is a user client: it logs in as you, with your token or credentials, and shows your servers. That distinction matters for anything involving moderation or automation. If you want to script reactions to messages, a bot is the correct tool and Concord is not.

A third comparison is to other terminal chat clients that speak protocols like IRC or Matrix. Those have stable, documented protocols and can be reimplemented freely. Concord depends on Discord's own endpoints, which the project does not document in the README. The upside is that you get Discord's actual content, including embeds, stickers, custom emoji and forum posts. The downside is that the compatibility surface is owned by someone else.

Maintenance, upgrade cost and the licence question

The repository is not archived, and the last push was on 2026-09-15, with v2.5.21 released the same day and v2.5.20 and v2.5.19 earlier that month. That is a fast release cadence, and the CHANGELOG.md plus cliff.toml in the repository root suggest changelog generation is automated. Fast releases are not the same as a stability promise, though. Nothing in the README describes deprecation policy or a supported version window, so an upgrade can change behaviour without a documented migration path. If you pin a version, pin it deliberately.

Upgrade cost is dominated by the build, not the binary. Cargo.toml pins rust-version 1.90 and edition 2024, so a toolchain bump can be required before a new release compiles. The dependency list is long and includes native-linked crates: cpal with pulseaudio, keyring, arboard with wayland-data-control, and the H.264 stack behind screen sharing. A source build therefore inherits the health of those system libraries, and the README's build dependency lists differ per distribution, with NASM required on macOS Intel and on Linux, and the MSVC toolchain plus Visual Studio 2022 Build Tools on Windows.

On licensing, there is a discrepancy worth resolving before you ship anything. Cargo.toml declares license = "GPL-3.0-only". The repository metadata reports NOASSERTION, which usually means a licence file that a detector could not classify. The top-level LICENSE file is the place to look. GPL-3.0-only is a copyleft licence with obligations that attach to distribution, so if you plan to redistribute a modified build, read the LICENSE file rather than the metadata field. This is a description of what the files say, not legal advice.

Editorial conclusion

Concord suits engineers who already live in a terminal, are willing to paste a Discord token instead of using email and password, and can install the native audio and video libraries it links against. It is the wrong choice if you need a documented stability policy, a graphical client, or a login flow you can hand to a non-technical colleague: the README itself recommends token authentication because email and QR logins can hit a CAPTCHA it cannot solve. Before adopting it, verify three things on your own machine: that your terminal reports a graphics protocol other than halfblocks, that mpv is on your PATH if you want video playback, and whether your distribution packages the runtime libraries listed in the README. The licence field in Cargo.toml reads GPL-3.0-only, while the repository metadata reports NOASSERTION, so confirm which applies before you redistribute a build.

Frequently asked questions

Official sources

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