Dino: an XMPP chat client for the Linux desktop, built with GTK and Vala

What Dino is, and the XMPP problem it addresses

Dino is an XMPP messaging app for Linux, written in Vala and using GTK. The README describes it as supporting calls, encryption, file transfers and group chats. XMPP is a federated protocol: your account lives on a server you or someone else runs, and clients talk to that server rather than to a company's central service. That means the client is only one half of the experience. Dino's job is to be the desktop half on Linux, and the repository topics list Linux desktop, GTK 4, Jingle, OMEMO and VoIP alongside the more obvious chat labels.

The audience is narrow on purpose. Someone who already has an XMPP address and wants a GTK application that looks like the rest of their desktop, rather than a browser tab or an Electron shell. The README points new users at prebuilt packages in the project wiki, and the project keeps a public XMPP channel at [email protected] for discussion. There is no web client and no mobile client in this repository; the top-level entries are the desktop application, its libraries and its plugins.

That narrowness cuts both ways. A federated client cannot fix a server that drops messages, and it cannot make your contacts install a Linux application. Dino's value is concentrated in the interface and the protocol implementation, and everything about account creation, server choice and federation reach sits outside the repository. If you are evaluating it, evaluate it as the last mile of a setup you have already decided on.

How the repository is put together

The layout tells you more about the architecture than the README does. The top level contains libdino/, main/, plugins/, qlite/, xmpp-vala/ and crypto-vala/. That split is the design: xmpp-vala/ handles the protocol, libdino/ holds the shared application logic, main/ is the GTK application itself, and plugins/ contains optional features. crypto-vala/ is a separate library for the encryption side, which is consistent with the OMEMO topic on the repository.

qlite/ is a small database layer, which is where message history and account state would live. The presence of a dedicated SQLite wrapper rather than a general ORM suggests the storage needs are simple and the authors wanted to keep the dependency surface small. Vala compiles to C and uses GObject, so the whole application is a native binary that links against GTK rather than shipping a runtime engine. For a chat client that runs all day, that is the main practical argument in its favour: memory use and startup are determined by GTK and the C libraries underneath, not by a bundled browser.

The protocol stack being a separate directory matters if you intend to contribute. A bug in message delivery and a bug in the account settings dialog live in different trees, and the README asks contributors to discuss larger changes in the project channel before opening a pull request.

There is also a meson_options.txt at the top level, which is where build-time choices are declared, and a dino.doap file, the DOAP descriptor that application directories and packaging tools read. Neither is described in the README, but their presence tells you the project expects to be packaged by distributions rather than only built by hand. The plugins/ directory is the extension point; the README does not enumerate what ships there, so the directory itself is the reliable source.

Installing Dino and sending a first message

The README does not give installation commands. It says to have a look at the prebuilt packages linked from the project wiki, under Distribution Packages. That is the intended path for most users: install from your distribution, launch Dino, and add your XMPP account in the application.

If no package exists for your system, the README gives the build steps directly. First install the dependencies listed on the wiki's Build page, then run Meson from the repository root. The three commands below are copied from the README: they configure the build into a directory named build, compile it, and then run the resulting binary from the build tree.

Building from source with Meson

The README's build section is three lines. It assumes you have already installed the dependencies from the wiki, which is where the real work is: GTK, Vala, and the other libraries the project links against are not listed in the README itself.

meson setup build
meson compile -C build
build/main/dino

The first command creates the build directory and detects the toolchain. The second compiles it. The third runs the binary in place, without installing it system-wide. If the configure step fails, the error will name the missing dependency, and the wiki's Build page is the place to check what you still need.

Note that this runs the development build, not an installed application. The README contains no meson install step and no mention of where files would be placed, so anything beyond running it from the build tree is undocumented in the repository root. For a first real use, the sequence is: run the binary, add your account, and send a message. The README does not walk through account setup, so the application's own dialogs are the guide.

Where Dino is the wrong choice

The first limitation is the platform. This is a Linux application using GTK. The README says so in its first sentence. If any of your contacts or colleagues use Windows, macOS, Android or iOS, Dino cannot be their client, and you will be relying on them to pick something else on the same XMPP server.

The second is the dependency burden of building it yourself. The README delegates dependencies to a wiki page, which means the build is not self-describing. On a distribution with current GTK and Vala packages this is routine; on an older or unusual system it can turn into dependency archaeology. For a user who just wants to chat, the prebuilt packages are the sane route, and the project's own README treats them as the default.

The third is federation itself. Dino is a client, so your account, your message history on the server, and your ability to reach other people all depend on the XMPP server you register with. The README does not describe server setup. If you do not already have an XMPP account, choosing Dino is only half a decision; the other half is choosing a server, and that is outside this repository entirely.

The fourth is documentation depth. The README is a signpost, not a manual. It does not list supported XMPP extensions, does not state which servers are known to work, and does not document a migration path for local history between versions. If your evaluation depends on knowing exactly which protocol features are implemented, the repository root will not answer that; you would have to read xmpp-vala/ or ask in the project's channel.

Alternatives and how they differ

The closest comparison is another native XMPP client for the same desktop, Gajim. Both speak XMPP, both are GTK applications, and both are packaged by distributions. The difference in approach is visible in the toolkits: Dino is written in Vala and targets GTK 4, while Gajim is a Python application. That choice affects packaging and startup more than features. Dino's Vala and GObject stack produces a compiled binary; Gajim's Python stack is easier to modify in place but pulls in a Python runtime and its dependencies.

A second alternative is a multi-protocol client such as Pidgin or Kopete, which can connect to XMPP alongside other networks. Dino deliberately does not do that. It is an XMPP client and nothing else, which is why its protocol code lives in xmpp-vala/ rather than in a plugin for someone else's framework. If you need one window for several networks, Dino is the wrong shape. If you want one network done in a native Linux application, the narrower scope is the point.

The third option is a web client. It runs anywhere and installs nothing, at the cost of running inside a browser. Dino's README does not mention a web client, and the repository contains none. The trade is explicit: a native binary with a smaller runtime footprint against a client that works on machines you do not control.

Licence, maintenance and the cost of upgrading

Dino is licensed under GPL-3.0. The README carries the standard notice: the program is free software under version 3 of the GNU General Public License, distributed without warranty. For a desktop chat client this is the ordinary arrangement, and it does not restrict your use of the application. It does matter if you plan to redistribute a modified Dino, because the GPL's source obligations apply to derivatives. That is a description of the licence text, not legal advice; read the LICENSE file in the repository if your situation is unusual.

On maintenance, the repository is not archived. The last push was on 2026-08-21. The release history shows v0.5.1 on 2025-11-15, v0.5.0 on 2025-04-11 and v0.4.5 on 2025-02-24, so the project has shipped point releases within the last year and a half.

The upgrade cost depends on how you installed it. Distribution packages upgrade with the rest of your system and may lag the upstream releases. A build from source upgrades by pulling the repository and repeating the Meson commands, which means re-resolving dependencies whenever the project adds one. The README does not document a migration path for local message history between versions, so if your history matters to you, that is something to confirm before upgrading a build you rely on. The GPL also means that if you patch Dino for internal use and then distribute it, you take on the corresponding source obligations; a purely private build does not raise that question.

What the README does not tell you

Several things a prospective user would want are simply absent. There are no screenshots in the text beyond the linked image, no list of supported XMPP extensions, and no statement about which servers or services are known to work. The README points at the wiki for building, debugging and translations, which means the repository root is a signpost rather than a manual.

The contribution section is more specific than most: pull requests are welcome, issues labelled good first issue are suggested as a starting point, and larger changes should be discussed in the project's XMPP channel first. There is also a debugging page on the wiki that the README asks you to read before reporting a bug, and a translations page. If you are evaluating Dino as a user rather than a contributor, the practical takeaway is that the documentation lives at dino.im and in the wiki, and the README is an entry point to both.

One consequence is that the README cannot be used to judge feature completeness. It names four capabilities in one sentence and stops. Whether a given XMPP extension is implemented is a question for the source tree or the project channel, not for the repository root. Treat the README as a pointer and budget time for the wiki before you decide.

Editorial conclusion

Adopt Dino if you want a native GTK XMPP client on Linux and you are comfortable either installing a distribution package or building with Meson from the wiki's dependency list. Do not adopt it if you need a client on Windows, macOS, Android or iOS, or if you want a chat network that is not XMPP. Before committing, verify that a package exists for your distribution, that your server supports OMEMO and Jingle if you rely on encryption and calls, and that your GTK 4 and Vala toolchain is new enough for the current master branch.

Frequently asked questions

Official sources

1. dino/dino on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases