Orchid

Orchid is a decentralized marketplace "for bandwidth"; providers run a server (in the srv-daemon folder) that talks to a decentralized directory that runs on Ethereum (in the dir-ethereum folder). On top of this marketplace, we happen to provide a VPN application (the app- and vpn- folders) as well as a lower-level client daemon (currently in cli-shared); but, as our software is (and has always been ;P) entirely open-source (under a "free software" license: the AGPLv3)--and, because we strive to use "off the shelf" transport protocols whenever possible (such as WebRTC and, maybe-weirdly, layered UDP)--you can remix our stack into anything you want! Users pay for service using "(streaming) probablistic nanopayments"--a "layer 2" Ethereum scaling solution we think of as somewhere between "one-to-many payment channels" and "probablistic roll-ups", based on some older (yet seminal) work into which we poured effort into economic incentive design and practical integration--that is "somewhat separate", in case you'd want to use it for something else (you can find the code for this in lot-ethereum).

Compiling Orchid

Many users would like to compile Orchid. Thankfully, Orchid is extremely easy to build... so easy, in fact, that a lot of people seem confused by a lack of complex instructions :(. Every single library dependency of Orchid is included as a git submodule (so don't forget to run "git submodule update --init --recursive") and is compiled by the Orchid build system, so there is no need for a lengthy DEPS list: there are no "external" steps (as you often see with many other C/C++ projects).

Of course, you do need to have the requisite build tooling installed... in addition to the standard set of C/C++ development tools (autotools, bison/flex, make, etc.) we specifically require clang (for which I'm truly sorry: maybe one day we'll support gcc) and ldd (neither binutils ld nor gold are sufficient). Some of the build scripts for our dependencies use Python (I think only 3.x), one insists on being built using meson/ninja, and we use a couple libraries that are written in Rust.

(At this point I will note, as this has come up multiple times: it is neither practical nor appropriate for Orchid's documentation to detail how to install any of these toolchains. The instructions are different for every operating system, are different for every single distribution of Linux, and are often even different for specific versions of a distribution. FWIW, developers already have most of this software installed; and, if you don't, these projects have their own documentation.)

That said, the "usual algorithm" of "try to build it, and if you get an error saying you are missing X, just install X" should work, so I'd just dive in (like, honestly, I'm shocked you are reading this); that said, if you are "feeling lucky", you can run env/setup-mac.sh (if using macOS) or env/setup-lnx.sh (if using Ubuntu/Arch), which are scripts that install everything on either macOS or (specifically and only) Ubuntu (and thereby can serve as "documentation" if you refuse to just dive in).

Given that you have a box capable of compiling other projects (as we aren't using anything "weird", really... meson is probably the rarest dependency we have, and it will be extremely obvious) you can then just go into any subfolder you want (such as app-{android,ios}, or cli-shared/srv-daemon and run "make". Seriously: it's that easy... if it breaks for some reason other than "you ran out of memory / disk space" or "command X not found" (which you can trivially solve), please file an issue.

Or, Using Docker

Alternatively, if your goal is merely to "build a copy of" Orchid--as a user who neither is prepared to install a compiler nor wants to trust any of Orchid, Apple/Google, or GitHub to give you "safe" binaries (but feel comfortable with the source code you were provided... how you might hope to do that part is definitely left up as an exercise to the reader ;P)--you can avoid installing anything (except Docker) by installing Docker and then running env/docker.sh instead of "make". You do still need to have checked out the full source code (including the submodules!).

(Of course, this now requires you to trust Docker itself--to be clear: if you look at env/docker.sh, you can see that it is starting with a bare official Ubuntu image and then installing Rust/clang/NDK/etc. from the official first-party sources, so this path doesn't introduce weird trust on any "random" third-party and certainly doesn't involve binaries from us in any way--which may or may not help with your particular trust scenario; but, frankly, this is kind of a "last resort" to allow non-developers to "build from source", so hopefully it is useful to consider.)