qaul: an off-grid mesh messaging app built as a Flutter shell over a Rust core

A peer to peer mesh that needs no internet link

qaul is described in one line as an internet independent wireless mesh communication app, and the name itself, written as a transliteration of the Arabic word for saying, is the only branding the project uses.

The technical claim is about the network, not the interface. In a mesh network, devices relay traffic for each other, so a group of phones or laptops within radio range can reach one another and stretch coverage outward as the number of participating nodes grows. The topic list names the technologies involved: BLE for Bluetooth low energy, wifi, p2p, mesh, p2p-network and p2p-chat, alongside the platforms android, ios, linux, macos and windows.

That combination of radios is what makes the deployment story specific. Bluetooth low energy gives short range and low power, which suits phones and small sensors, and wifi gives longer range at higher power, which suits laptops and fixed nodes. A mesh network in practice runs over both, and the practical question for any deployment is which radios are actually available on the devices in the field.

The documented use case is communication where the usual infrastructure is absent, which means the value of the project is in the networking rather than in the chat. That framing also explains the licence, discussed below.

The Rust core sits under a Flutter user interface

The repository layout describes the architecture more clearly than the short readme does, and the primary language listed for the project is Dart with Rust also in the tree.

At the top level there is a rust/ directory, a qaul_ui/ directory, and an iOS/ directory. The primary language being Dart rather than Rust points to the user interface being the larger half in terms of code, while the rust/ directory holds the part of the system that has to be careful about concurrency, because the networking layer in a mesh has to handle several peers, multiple radio interfaces and reconnection at the same time.

A protobuf/ directory at the root indicates a binary wire format rather than a JSON one. That is the right call for a protocol spoken between devices, since a schema-driven format keeps the message definitions in one place and lets several implementations in different languages agree on the encoding. The utilities/, tools/ and tests/ directories suggest the shared helpers, the developer tooling and the test suite are kept apart from both halves of the application.

The metadata/ directory is likely the per platform packaging information, and docs/ holds the documentation sources for the site the project points people at. The plan.md file at the root is worth noting separately, because a checked-in plan is a rare and useful thing to find in a project: it records what the maintainers intend to do rather than only what has already happened.

AGPLv3 for users, a copyright transfer for contributors

The licensing is unusually thorough, and it is split in two.

For users and for anyone who distributes the software, qaul is published under the AGPLv3, the GNU Affero General Public License version 3 or later. The project states that it is fully free and open source software, and points to a licenses folder for in depth information on the licences involved. The Affero variant of the GPL was chosen for network software, and its practical effect is that a modified version offered over a network must also release its source.

For contributors, the terms are different and stricter. By committing or contributing, you agree to transfer the full copyright of your contributions to the Verein zur Förderung von offenen Community-Projekten in Switzerland, whose English name is the Open Community Project Association. The readme enumerates exactly what the transfer includes: the right to distribute the work, the right to modify it, the right to enforce the copyright, the right to change the licence of the work, the right to transfer ownership, and all exploitation rights.

The point of that enumeration is that it is a full copyright assignment rather than the usual in copyright model, where the contributor keeps ownership and the project gets a broad licence. A Contributor License Agreement is referenced, and the readme points to it in the licenses folder.

For an organisation evaluating the project, this distinction decides things early. Consuming qaul under AGPLv3 is a different question from contributing to it, and the second one commits your employer to giving up ownership of what you write for the project.

Release candidates for the 2.0 line, with the branch still moving

The release history shows a 2.0 line that has not settled yet. The three most recent tags are v2.0.0-rc.9 from 2026-10-12, v2.0.0-rc.8 from 2026-08-30 and v2.0.0-rc.7 from 2026-08-10. The rc suffix means release candidate, so the project is still choosing what a stable 2.0 looks like.

The spacing is informative. The gap between rc.8 and rc.9 is roughly six weeks, while rc.7 to rc.8 was about three, and the gaps are not shrinking on a predictable schedule.

The repository is not archived, the default branch is main, and the last push was on 2026-10-17, five days after the newest tag. A CHANGELOG.md at the root is where the release level changes are recorded.

The presence of version tags across the platforms listed as topics, and of an iOS directory alongside the mobile and desktop targets, points to one codebase shipping to several destinations rather than separate applications that happen to share a name. The CircleCI badge at the top of the readme and the circleci_config/ directory at the root are the build side of that, and the CircleCI configuration tree at the root is where the per platform build definitions live.

The repository carries the usual governance files and a few unusual ones

A few of the top level entries tell you what the maintainers take seriously.

SECURITY.md and CODE_OF_CONDUCT.md are both present, which is the minimum a project handling peer to peer traffic should have, since any node on a mesh is reachable by the other nodes. The lefthook.yml file at the root configures Git hooks, which is a way of enforcing commit message format and pre-commit checks locally rather than relying on a server-side gate that only complains after a push.

The .syft/ directory points to the SBOM tooling, since a directory named after a software bill of materials generator is where a project keeps the configuration that produces a list of the components it ships. For an application that distributes binaries to phones and laptops in places with unreliable connectivity, being able to enumerate what is inside those binaries is a practical concern rather than a compliance exercise.

The .github/ directory holds the issue and pull request templates and any workflow definitions, .vscode/ holds the editor configuration, and .circleci/ holds the CircleCI configuration. The .gitconfig file at the root is unusual enough to mention, since a repository level git config can enforce line endings or commit template defaults for every clone.

The docs/ directory is where the documentation site that the readme links to is built from, and the readme itself is deliberately thin, deferring to that site for installation and usage instructions.

What the readme does not tell you

The documentation in the repository is a pointer, not a manual. The readme consists of the project name, a two line description, the licence statements, the contribution terms and links, which means that installation, configuration, how to get two devices talking over BLE, how the routing works, and what the wire format looks like all live in the hosted documentation rather than in the checkout.

That is a normal choice for an application with many platforms, since a single markdown file cannot usefully cover Android, iOS, Linux, macOS and Windows. The cost is that the repository alone is not enough to evaluate the project. You cannot read the code and know what the mesh protocol does; you have to fetch the documentation site or read the Rust source.

It also means the parts of the system that matter most for trust, the peer discovery behaviour, the encryption, and the permissions a phone app requests for Bluetooth and location, are not visible in what is published here. For a project whose whole premise is carrying communications over a network nobody controls, that is the part to check before recommending it for anything sensitive.

The honest summary is that qaul is a well organised, actively developed cross platform mesh application with a serious licensing setup and a release process still in the candidate phase. Whether it suits a given deployment depends on the documentation site and on the deployment details the repository does not cover.

Editorial conclusion

qaul suits a team building field communications, community networks or disaster response tooling, or a developer who wants to read a Dart and Rust mesh networking project that ships on every desktop and mobile platform at once. It does not suit a product team expecting a stable release, since the recent tags are all v2.0.0 release candidates, and the AGPLv3 licence plus the contributor agreement that transfers copyright to a Swiss association are conditions you need to accept before building on it. Before adopting it, read the documentation site referenced from the repository, and if you intend to contribute, read the Contributor License Agreement and the licenses folder before your first commit.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. Project website
3. qaul/qaul.net on GitHub
4. README
5. Releases