CoyIM makes XMPP safe by default, and admits where it is not

The design goal is a user who will never open a settings screen

CoyIM is a chat client for the XMPP protocol, written in Go and built on the agl/xmpp-client library with the coyim/otr3 implementation for encryption. It adds a graphical interface, and that is where the project puts its emphasis: it defaults to safe and secure options, and the stated ambition is that even the highest risk users could use it without making any configuration changes.

That ambition shapes the design more than any feature list. OTR is enabled, Tor is used by default, and the client will only use the Tor Onion Service for a known server. TLS and TLS certificates are used to verify the connection, and none of that requires configuration. The stated reason for using Go is to avoid many common types of vulnerabilities that come from using unsafe languages, which is a language level argument for memory safety in a client that parses network input from strangers.

For most users this is invisible, and that is the point. A secure messenger that asks you to pick between two encryption modes on first launch has already lost a fraction of its users. CoyIM removes the decision instead of documenting it.

OTR, Tor and certificate verification are three separate layers

It is worth separating what the README claims into its three parts, because they protect against different things and fail in different ways.

OTR is the message layer. The project ships its own implementation in the coyim/otr3 dependency, and the README states that this code has been audited with good results. The otrclient directory at the top of the repository is the on-disk side of that, and the presence of a dedicated OTR directory tells you the encryption path is a first class part of the codebase rather than an add-on.

Tor is the transport layer. Using Tor by default hides the local network position of the user from the server, and the extra rule that the client only uses the Tor Onion Service for a known server narrows that further: for a server you have not approved, the connection goes through the regular Tor circuit rather than attempting an onion address.

TLS and certificate verification cover the connection to the server itself, including the case where you are connecting over Tor.

The three layers are complementary, which is exactly why the missing audit on the rest of the client matters. The audited component is one link in a chain.

The first launch wizard imports settings and OTR keys

Running CoyIM means downloading the executable from the project homepage and running it. Arch Linux users can install it from the AUR instead, which the README highlights with a bold note.

On first launch a wizard appears. Its purpose is migration. If you already run a Jabber client configured for OTR encryption, the wizard imports your account settings, your OTR keys and your contacts fingerprints, so you do not have to re-key a contact list by hand. The README notes that if you skip the wizard you can still import later through Accounts -> Import.

The Pidgin case is called out specifically, because migrating from Pidgin is the most common path and the file locations are not obvious. The relevant files live in the .purple directory in your home folder.

This import flow is the single most practical feature in the project for a new user, and it is also the one that quietly determines whether OTR actually works for you. A contact whose fingerprint you have never verified cannot be trusted by the protocol, and no import wizard fixes that. The project directs readers to a features page on its website for the full list of what is and is not supported.

Building from source needs Go 1.24, GTK 3.12 and a Make target

The documented build requirements are Go 1.24 or higher and at least GTK+ 3.12, with the GTK installation depending on the operating system. The go.mod file agrees, declaring go 1.24.0 with a toolchain line pinning go1.24.10.

The system dependencies for Debian and Ubuntu systems are a single apt-get line, and macOS has its own set of three brew commands:

sudo apt-get install gtk+3.0 libgtk-3-dev ruby

brew install gnome-icon-theme
brew install gtk+3 gtk-mac-integration
brew install ruby

With the dependencies in place, the build itself is two make targets:

make deps
make build

The README is explicit that go get might work but is not a supported method.

One detail in the Makefile is worth knowing if a build fails on a newer system. The file probes the installed GLib, GTK, Pango and Cairo versions with pkg-config and derives build tags from them, and there is an explicit downgrade path: when GTK 3.24 is installed but its patch level is below 14, the build tag falls back to gtk_3_22, because a new variable was introduced at 3.24.14 and older patch levels will not compile with gotk3. That is the kind of accommodation that tells you the project has been built against a wide range of desktops.

Reproducible builds are supported, but only for Linux on AMD64

CoyIM supports reproducible builds for Linux on AMD64, with instructions in the REPRODUCIBILITY.md file for building and verifying them. The repository layout backs this up with a reproducible directory and a digests directory, and the Makefile derives its version and build metadata from git state rather than from a checked in string: it reads the current commit, takes the most recent tag that contains it, and stamps the current date and a GMT timestamp.

That matters more than it might sound for a security tool. A privacy client distributed as a binary is asking users to trust that the binary they download matches the source anyone can read. Reproducible builds remove that trust requirement for the one platform and architecture pair that supports them, letting a user rebuild the artifact and compare it byte for byte.

The scope is narrow, and the documentation is honest about it. Linux on AMD64 is one combination. A macOS or Windows user, or someone on ARM Linux, gets no such guarantee from this project, and the platform specific build hooks in the repository (hooks_osx.go and hooks_other.go) point at how much of the codebase is platform dependent.

The repository also carries an AppArmor profile in coyim.apparmor, a Tails installation script, and an OpenPGP policy file, which together suggest the project is oriented toward the hardened Linux environments its user base lives in.

The security warning is the most honest paragraph in the README

The README carries a section titled Security warning, and it is worth reading in full because it undercuts the project's own marketing in the same document. It says the project is still being worked on, that the code for the OTR implementation has been audited with good results, and then that the rest of CoyIM still has not received an audit. It adds that this is worth keeping in mind if you are using CoyIM for something sensitive.

That last clause is the operative one. The audit covers one component, the rest is unaudited, and the intended audience includes people for whom a compromise is serious.

The rest of the repository is consistent with a project that takes its threat model seriously rather than as marketing. There is a THREAT_MODEL.md at the top level, a PHILOSOPHY.md, a SUPPORTED_XEPS.md listing the protocol extensions that are supported, an ENCRYPTED_FILETRANSFER.md for file transfer, and a GTK_TRICKS.md for platform specific behaviour. There is also a .gosec.config.json for the Go security linter and an openpgp-policy.toml for the OpenPGP component.

None of these files substitute for an audit of the client itself. They show the shape of the security argument, which is more than most chat clients offer.

The release history is old and the source is not

Here is the tension in the project's status. The last push was on 2026-07-10, so the source has been touched recently. The last tagged release, v0.4.1, dates from 2022-09-19, with v0.4 in February 2022 and v0.3.11 in April 2019.

So the repository is not abandoned and it is not shipping regular binaries either. The go.mod dependency list supports the first half of that reading: several pinned dependencies carry pseudo-versions with 2025 and 2026 dates, including coyim/otr3 at a March 2026 commit and coyim/gotk3osx at a December 2025 commit, and golang.org/x/crypto sits at v0.47.0. Those are recent versions of security relevant libraries, which means the source tree is being kept current even though no release has been cut since 2022.

What that means for an adopter is that the binary you would install from a package manager may not be the binary the source currently produces. The AUR entry and the homepage binaries date from before the recent source changes, so the version a user installs may lag the current source tree.

The licence is GPL version 3 for the project and all source files unless otherwise noted, and the LICENSE.xmpp-client file covers the separately licensed xmpp-client component that the project builds on. The project's licence is recorded as a custom one that GitHub cannot classify, so the actual terms are in the LICENSE file, and the README points at the GPL version 3.

Editorial conclusion

CoyIM fits researchers, journalists and anyone whose threat model includes someone reading the network traffic, because the defaults already give you OTR, Tor and certificate verification without touching a settings screen. It is the wrong tool if you need an actively reviewed messenger with a release cadence, since the last tagged release was v0.4.1 on 2022-09-19 even though the source has moved since, and it is the wrong tool if you need the non XMPP features of a modern client. Before you rely on it, check the two things the project itself flags: the README states that the OTR implementation has been audited while the rest of the client has not, and the last push was on 2026-07-10, so read the current THREAT_MODEL.md and the audit summary rather than the marketing claim of safe defaults.

Frequently asked questions

Official sources

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