cloudhead
27f39514d4
Private repos are implemented by extending the identity document with a `visibility` attribute, that can either be `"public"` (default) or `"private"`. In case of `private` visibility, only the delegates are allowed to view the repo, as well as any DIDs added to the allow list. To implement repo visibility, we simply block fetches from and announcements to peers for whom the repo should remain invisible. Private repos are also not announced in the `inventory` message, since the full list of peers that *may* have the repo is retrievable from the repo identity. This could cause errors if eg. a peer who is allowed to view the repo doesn't actually have it. However this is an ok trade-off for now to keep the complexity low. For repos to truly be private, it's important that the RIDs don't leak either. Finally, we modify `radicle-httpd` for now to only list public repos. Eventually, we would want to change this depending on whether an allowed peer is authenticated with the service or not. --- It's also worth mentioning why this approach was taken, vs. end-to-end encryption. The reasons are as follows: 1. Nodes that do not have access to a private repo will generally not want to replicate encrypted data that they cannot examine or use. 2. The chosen solution is trivial, while encrypting git objects isn't. 3. Performance of the chosen solution is much better, there is no overhead. 4. Privacy of the chosen solution is better: RIDs are never leaked, and neither is the existence of a private repo, nor who has access to it. There is one downside: Paying for storage of private repos is no better in terms of privacy than what GitHub offers. Hosting providers will have access to your private repos, if this solution is used.
❤️🪵
Radicle Heartwood Protocol & Stack
Heartwood is the third iteration of the Radicle Protocol, a powerful
peer-to-peer code collaboration and publishing stack. The repository contains a
full implemention of Heartwood, complete with a user-friendly command-line
interface (rad) and network daemon (radicle-node).
Radicle was designed to be a secure, decentralized and powerful alternative to code forges such as GitHub and GitLab that preserves user sovereignty and freedom.
Installation
Requirements
- Linux or Unix based operating system.
- Git 2.34 or later
- OpenSSH 9.1 or later with
ssh-agent
📀 From binaries
Requires
curlandtar.
Run the following command to install the latest binary release:
sh <(curl -sSf https://radicle.xyz/install)
📦 From source
Requires the Rust toolchain.
You can install the Radicle stack from source, by running the following commands from inside this repository:
cargo install --path radicle-cli --force --locked
cargo install --path radicle-node --force --locked
cargo install --path radicle-remote-helper --force --locked
Or directly from our seed node:
cargo install --force --locked --git https://seed.radicle.xyz/z3gqcJUoA1n9HaHKufZs5FCSGazv5.git \
radicle-cli radicle-node radicle-remote-helper
Running
Systemd unit files are provided for the node and HTTP daemon under the
/systemd folder. They can be used as a starting point for further
customization.
Additionally, a Dockerfile is included under both crates.
For running in debug mode, see HACKING.md.
Contributing
See CONTRIBUTING.md and HACKING.md for an introduction to contributing to Radicle.
License
Radicle is distributed under the terms of both the MIT license and the Apache License (Version 2.0).
See LICENSE-APACHE and LICENSE-MIT for details.