RetroShare: peer-to-peer channels and a build you assemble yourself

Six channels over one core library and three front ends

RetroShare targets people who already know each other and want the traffic to run without a company sitting in the middle. The repository calls it a cross-platform Friend-2-Friend platform, and the feature line names file sharing, chat, messages, forums, channels and boards. None of that lives in a single binary. `retroshare-gui/` is the desktop client, `retroshare-service/` is the component named for running without a desktop, and `retroshare-webui` is the one entry written without a trailing slash, the same shape the three submodules use in the top level listing.

`libretroshare` sits underneath all three as its own checkout, which is why nothing compiles until the submodules are in place. `data/`, `supportlibs/`, `plugins/` and `tests/` fill out the rest of the tree, so assets, shared libraries, plugins and test code are as much a part of the checkout as the protocol itself. The default branch is `master`, and the GitLab pipeline badge builds that same branch, so a green Linux job tells you nothing about the state of any tag. The core is the same C++ everywhere; what changes per platform is the recipe that compiles it.

Cloning the repository and pulling three submodules first

The one command in the README sits under a heading called Get the source, and it is about submodules rather than installation. Clone RetroShare/RetroShare, change into the clone, then run:

git submodule update --init --remote --force libbitdht/ libretroshare/ openpgpsdk/

The three names are `libbitdht`, a distributed hash table library, `libretroshare`, the core that every front end links against, and `openpgpsdk`, an OpenPGP implementation. In git, `--remote` updates each submodule to the tip of its own branch rather than the commit RetroShare recorded, and `--force` throws away local changes inside those directories. After that step no universal build line appears anywhere, because each platform is handed off to its own guide file.

Nothing precedes that step either. There is no package name, no install target and no configure line in the README, so the only documented route to a running client starts at a submodule command and ends in a recipe for the system you happen to own.

Submodules tracked at their tips, so a clone is not a fixed point

Two clones taken a week apart can compile different `libretroshare` code against identical RetroShare sources, since the documented command resolves every submodule against its remote branch. The repository is not archived and the last push was on 2026-09-15, while the newest tag is v0.6.7.2 from 2023-11-30 and the one before it, v0.6.6, from 2021-03-13, so there is no tagged set of the three submodules to pin a build against.

The top level listing backs this up in a small way. Four entries are directories written without a trailing slash: `libbitdht`, `libretroshare`, `openpgpsdk` and `retroshare-webui`. Three of them appear in the submodule command and one does not, and nothing in the README says whether `retroshare-webui` is a fourth submodule or plain source that arrives with the clone. If it is a submodule, the documented command leaves it uninitialised and the web front end will not build.

Recording the three commits your build used is the only reproducibility lever this repository offers, because the root holds no lock file for them and the submodule command overwrites whatever you had.

Windows carries the Qt matrix, macOS carries only a guide

Five of the badges at the top of the README report builds, and none of them reports a macOS build. Three are Windows toolchain targets in GitHub Actions: MINGW64 with Qt5, UCRT64 with Qt5 and MINGW64 with Qt6, wired to the workflow files `ci-mingw64.yml`, `ci-ucrt64.yml` and `ci-mingw64-Qt6.yml`. The Qt6 job is named after the MINGW64 toolchain, so the newer Qt is exercised on one Windows environment and nowhere else. The two remaining badges are GitLab pipelines, one for `master` on GNU/Linux and one for `libretroshare` on GNU/Linux and Android.

Those five signals come from two providers, so reading them means switching between a GitHub Actions page and a GitLab pipeline page to find out why a job went red. macOS still has instructions, `MacOS_X_InstallGuide.md` under `build_scripts/OSX`, but no badge confirms that path still builds. A developer working on a Mac therefore has no CI signal to check a change against, and a shared C++ change can pass every visible job while breaking a platform that no badge touches.

GitHub Actions, GitLab CI and a Travis file in one root

Three continuous integration definitions live in the same checkout. The `.github/` directory holds the Windows workflows behind the Qt badges, `.gitlab-ci.yml` builds `master` on GNU/Linux, and `.travis.yml` sits in the root with no badge attached and no documentation describing what it compiles. A stale file that no badge reports is easy to overlook next to two active configurations.

The split shows up at review time. Each badge covers one platform and one toolchain pair, so a fully green set of jobs does not mean every supported platform builds. Android is covered only through the `libretroshare` pipeline rather than through the main repository, and the main repository's own build is confirmed on exactly one Linux target. Nothing in the README explains how a new platform gets a job, or which of the three files wins when two of them cover the same system.

qmake and CMake describe the same tree from different files

Two build systems cover the same sources. `RetroShare.pro` is the qmake project file, `retroshare.pri` holds the shared qmake settings, and `CMakeLists.txt` with `BUILD-cmake.md` serves the CMake path, so a newcomer has to choose one before reading any code. The README does not say which of the two the Linux guide uses.

What the README does point at is `build_scripts/`, a directory of per platform recipes with `Windows-msys2`, `build_scripts/OSX` and `Debian+Ubuntu` among them, each carrying its own install guide. Windows has two routes in there, `WindowsMSys2_InstallGuide.md` for the MSYS2 shell and `Windows-QtCreator-InstallGuide.md` for QtCreator, and the QtCreator file is the only place the README names an IDE. The wording in the README concedes that complete build documentation is missing, which is why the recipe directory rather than the main page carries the working command sequences.

A friend server in the tree with no runbook beside it

`retroshare-friendserver/` is a top level directory the README never mentions, and `libbitdht` is the component that would talk to it. Nothing in the repository files explains how a fresh node finds its first peer, and the root holds no Dockerfile and no compose file, so the bootstrap step is undocumented in both senses.

That gap matters because the feature list reads like a hosted service. File sharing, chat, messages, forums, channels and boards are all named, yet no README sentence says who can read a channel or who moderates a board, and the node you run is the node peers connect to directly. Two documented paths exist for people who will not compile: the RetroShare downloads page at `retroshare.cc/downloads.html` offers other builds, and a separate documentation site lives at `retrosharedocs.readthedocs.io`. Either route avoids the submodule problem above, and neither artifact is produced by building this tree. The homepage at `retroshare.cc` sits outside the repository too, so the binaries a user can grab are curated somewhere this checkout never shows.

A custom COPYING that GitHub cannot classify

GitHub labels the project licence as Other, and the two sources of that fact disagree on the file name: the project listing points at LICENSE while the root of the tree carries `COPYING` and a `LICENSES/` directory. Anyone who needs the exact grant has to read `COPYING` itself, and nothing here interprets it. `.reuse/` holds REUSE format metadata next to them, which is how per file terms get recorded without repeating them in every header, and `jsonapi-generator/` sits beside them with no description of how that generator joins a build.

Upgrade cost follows from the layout rather than from any policy. Because the three submodules move on their own branches, every rebuild can pull new code into `libretroshare`, `openpgpsdk` or `libbitdht` without a single line changing in the RetroShare sources you are reading. A rebuild months later inherits whatever those components carried on the day it ran, which is the second reason to write the three commits into your own notes before the first successful compile.

Editorial conclusion

RetroShare fits a small group that already trusts every member and is prepared to compile from source, and it fails everyone else. No install command, no friend server runbook and no macOS CI target exist anywhere in the repository, so a first build is a bet on submodule tips. Verify three things before adopting it: the recipe in build_scripts/Debian+Ubuntu, the prebuilt downloads linked from retroshare.cc, and the exact commits your libretroshare, libbitdht and openpgpsdk checkouts land on the day you build.

Frequently asked questions

Official sources

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