-
- {#if hero}
- 
- {/if}
-
-
-{:else if isGlossary}
+{#if isGlossary}
Learn
-
+
Get started
Guides
diff --git a/src/marketing/docs/guides/getting-started.md b/src/marketing/docs/guides/getting-started.md
deleted file mode 100644
index 51cdf9f60..000000000
--- a/src/marketing/docs/guides/getting-started.md
+++ /dev/null
@@ -1,401 +0,0 @@
----
-title: Getting Started with Radicle
-subtitle: A quick start guide to getting up and running with Radicle
----
-
-
-
-
- Getting Started | Radicle
-
-
-
-
-# Getting started with Radicle
-
-This quick start guide will take you through the basic installation and usage of the Radicle toolchain.
-
-## Installing the Radicle toolchain
-
-Radicle is an ecosystem for code collaboration over a decentralized network.
-You can start by installing the command-line toolchain, which includes:
-
-- the Radicle CLI (`rad`): the command-line interface for managing your identity, repositories, issues, and patches
-- the Radicle node (`radicle-node`): the daemon that connects to the peer-to-peer network and replicates repositories
-- a [Git remote helper] (`git-remote-rad`): the program Git calls to push and fetch from Radicle repositories with the `rad://` URL prefix.
-
-An [installation script](#install-script) is provided, or you can use your favorite package manager from the list below.
-
-You can check that you have successfully installed the toolchain and see what version you are using by running:
-```
-$ rad --version
-```
-
-### Install script
-
-The quickest way to get started:
-
-```
-$ curl -sSLf https://radicle.dev/install | sh
-```
-
-This installs the toolchain into `~/.radicle/bin` and adds it to your `PATH`.
-
-### From source
-
-> Requires the Rust toolchain.
-
-You can install the Radicle toolchain from source, by running the following
-commands from inside this repository:
-
- cargo install --path crates/radicle-cli --force --locked --root ~/.radicle
- cargo install --path crates/radicle-node --force --locked --root ~/.radicle
- cargo install --path crates/radicle-remote-helper --force --locked --root ~/.radicle
-
-Or directly from our seed node:
-
- cargo install --force --locked --root ~/.radicle \
- --git https://seed.radicle.dev/z3gqcJUoA1n9HaHKufZs5FCSGazv5.git \
- crates/radicle-cli crates/radicle-node crates/radicle-remote-helper
-
-### Debian / Ubuntu (apt)
-
-```
-curl -LO https://radicle.dev/apt/radicle-archive-keyring.deb
-sudo apt install ./radicle-archive-keyring.deb
-echo "deb [signed-by=/usr/share/radicle/radicle-archive-keyring.asc] https://radicle.dev/apt release main" \
- | sudo tee -a /etc/apt/sources.list
-sudo apt-get update && sudo apt-get install radicle
-```
-
-### Homebrew
-
-```
-$ brew install radicle
-```
-
-### Arch Linux (pacman)
-
-Install [`radicle`](https://archlinux.org/packages/extra/x86_64/radicle/) via pacman.
-
-### Nix
-
-Install [`radicle-node`](https://search.nixos.org/packages?show=radicle-node&query=radicle) from Nixpkgs.
-
-### Windows
-
-Currently, the best way to install on Windows is building it [from source](#from-source).
-
-### Binary download
-
-Pre-built binaries and verification instructions are available on the [download page](/download).
-
-## Creating your Radicle identity
-
-Before using Radicle, you need to create an identity — a cryptographic key pair that uniquely identifies you and your node on the network:
-
-```
-$ rad auth
-```
-
-You will be prompted for an **alias** (a human-readable name for your node) and a **passphrase** to protect your key pair:
-
-```
-Initializing your radicle 👾 identity
-
-✓ Enter your alias: alice
-✓ Enter a passphrase: ********
-✓ Creating your Ed25519 keypair...
-✓ Adding your radicle key to ssh-agent...
-✓ Your Radicle DID is did:key:z6Mkux1...
-✓ You're all set.
-```
-
-Your [DID] (Decentralized Identifier) is your unique identity across the network.
-You can view it at any time with `rad self`.
-
-```
-$ rad self --did
-did:key:z6Mkux1...
-```
-
-> 👻
->
-> Your passphrase and private key **cannot be recovered** if lost.
-> Store them somewhere safe.
-> Losing access to your key means losing your identity and any repositories associated with it.
-
-> 🧠
->
-> Radicle uses `ssh-agent` to cryptographically sign data that is pushed to the network.
-> After you have initialized your identity, `rad auth` will allow you to add the private key to the `ssh-agent`.
-
-> 🧠
->
-> Radicle does not currently support using a single identity across multiple devices, nor rotating keys.
-> Each device requires its own identity.
-
-## Your node and the network
-
-Radicle is a decentralized code forge — there is no central server.
-You participate in the network by running a node, which connects to other nodes to discover and replicate repositories.
-
-To start your node, run:
-
-```
-$ rad node start
-```
-
-You can then check that it is running and connected to other nodes:
-
-```
-$ rad node status
-✓ Node is running with Node ID z6Mkux1… and listening on 0.0.0.0:8776.
-
-╭────────────────────────────────────────────────────────────────────────╮
-│ Node ID Address ? Since │
-├────────────────────────────────────────────────────────────────────────┤
-│ z6Mkv7G… seed.example.xyz:8776 ✓ ↗ 3m │
-│ z6MkszH… radicle.example.net:8776 ✓ ↗ 3m │
-│ z6Mko5W… garden.example.org:8776 ✗ ↗ 2m │
-╰────────────────────────────────────────────────────────────────────────╯
-```
-
-The status table shows your connections to other nodes on the network.
-A `✓` indicates that your node is connected to the other node.
-Conversely, an `✗` indicates that you are disconnected from the other node.
-The arrow `↗` indicates an outbound connection (a connection that you initiated), whereas `↘` indicates an inbound connection (one that the other node initiated).
-
-You can stop your node at any time by running:
-
-```
-$ rad node stop
-```
-
-> 🧠
->
-> It is also possible to manage your node as a [systemd] service.
-> An example systemd user service is available in the [heartwood repository][systemd-service].
-
-> 🧠
->
-> Your node configuration lives in `~/.radicle/config.json` — see the [User Guide](/guides/user) for details on customizing your setup.
-
-[systemd-service]: https://radicle.network/nodes/iris.radicle.network/rad:z3gqcJUoA1n9HaHKufZs5FCSGazv5/tree/systemd/user/radicle-node.service
-
-## Your first repository
-
-Radicle is built on top of Git, so any existing Git repository can be published to the network.
-To publish your first repository, you can navigate to the repository and run `rad init`.
-
-When initializing the repository, you will have an option to choose its “Visibility”.
-A `public` repository means that this repository will be announced to the network by your node.
-Once the project has been announced and replicated, **deleting this repository is nearly impossible**.
-
-Instead, if this is a repository that you do not wish to announce to the network and/or wish to test out Radicle with,
-then choose `private`.
-Note that the workflow for a `private` repository differs from `public`, and you can see how it works by [following the User Guide](/guides/user#3-selectively-revealing-repositories).
-
-```
-$ cd /path/to/my-project
-$ rad init
-
-Initializing radicle 👾 project in .
-
-✓ Name: my-project
-✓ Description: A short description of my project
-✓ Default branch: main
-✓ Visibility: public
-✓ Project my-project created.
-
-Your project's Repository ID (RID) is rad:z3gqc…
-You can show it any time by running `rad .` from this directory.
-
-✓ Project successfully announced to the network.
-```
-
-
-
-Your repository is now on the Radicle network!
-You can see which nodes have replicated your repository by using `rad sync status`.
-
-```
-$ rad sync status
-╭──────────────────────────────────────────────────────────────────╮
-│ Node ID Alias ? SigRefs Since │
-├──────────────────────────────────────────────────────────────────┤
-│ (you) alice ✓ a1b2c3d 3m ago │
-│ z6Mkv7G… seed.example.xyz ✓ a1b2c3d 2m ago │
-│ z6MkszH… rad.example.net ✓ a1b2c3d 2m ago │
-│ z6Mko5W… garden.example.org ✗ f4e5d6c 1d ago │
-╰──────────────────────────────────────────────────────────────────╯
-```
-
-A `✓` means the node is in sync with your latest changes, while `✗` means it is out of sync.
-
-To push new changes, just use Git as usual:
-
-```
-$ git push
-```
-
-If you ever think the node has not announced changes, or that it needs to fetch changes, then you can always manually synchronize with the network:
-
-```
-$ rad sync
-```
-
-> 🧠
->
-> You can also set your repository’s visibility to `private` during `rad init`.
-> Private repositories are only replicated to nodes you explicitly allow.
-> See the [User Guide](/guides/user#3-selectively-revealing-repositories) for details on managing access.
-
-## Cloning a repository
-
-You can clone any repository from the network using its Repository ID (RID).
-For example, to clone Heartwood, the Radicle protocol implementation itself:
-
-```
-$ rad clone rad:z3gqcJUoA1n9HaHKufZs5FCSGazv5
-✓ Seeding policy updated for rad:z3gqcJUoA1n9HaHKufZs5FCSGazv5 with scope 'followed'
-✓ Fetching rad:z3gqcJUoA1n9HaHKufZs5FCSGazv5 from z6Mkk4R…SBiyXVM..
-✓ Fetching rad:z3gqcJUoA1n9HaHKufZs5FCSGazv5 from z6Mksmp…1DN6QSz..
-✓ Creating checkout in ./heartwood..
-✓ Repository successfully cloned under ./heartwood/
-╭────────────────────────────────────╮
-│ heartwood │
-│ Radicle Heartwood Protocol & Stack │
-│ 8 issues · 14 patches │
-╰────────────────────────────────────╯
-```
-
-This fetches the repository from connected peers and creates a working copy, just like `git clone`.
-The difference is that Radicle will first ask the network for the repository, and clone it from the first available node.
-
-## Your first issue
-
-Once you are working within a Radicle repository, it is easy to open an issue, whether your node is running or you are offline.
-
-Running `rad issue open` will open your editor, and you will be prompted to write the title and body of the issue.
-Similar to commit messages, the first line is taken as the title of the issue, and below that is the body.
-
-You can easily list issues using `rad issue list`, or show an issue with `rad issue show`.
-
-Here is an example of an issue in the `heartwood` repository:
-
-```
-╭───────────────────────────────────────────────────────────────────╮
-│ Title contributing: Feedback from the community │
-│ Issue b163597fae51a3f076d654294f695803dd5e221c │
-│ Author ade z6MkwGo…yS2aagA │
-│ Status open │
-│ │
-│ Derived from the Zulip conversation. │
-│ │
-│ - [ ] First contribution guide │
-│ - [ ] "good first issues" label usage │
-│ - [ ] Issue / Patch templates │
-│ - [ ] Source code overview map │
-│ - [ ] Increase time-to-first-feedback for new contributors │
-│ - [ ] Frequent and recurring open session for community to attend │
-│ - [ ] Local CI checks │
-╰───────────────────────────────────────────────────────────────────╯
-```
-
-## Your first patch
-
-At this stage, you will likely want to propose changes to a repository.
-As mentioned before, Radicle is built on top of Git, which means your `git` (or `jj`) workflow does not need to change too much.
-
-The `git-remote-rad` binary allows you to push changes to a special reference called `refs/patches` in the `rad` remote.
-When the remote helper sees this happening it will prompt you with your editor to write a title and body for the patch.
-Similar to commit messages, the first line is taken as the title of the issue, and below that is the body.
-
-The most common Git revision to push to `refs/patches` is the `HEAD` revision.
-This will create a patch starting from the commit you are currently on, and the base of the patch will be the latest commit of your default branch (chosen during `rad init`).
-From your command line you would run:
-
-```
-$ git push rad HEAD:refs/patches
-```
-
-In fact, this is so common that we would recommend adding the following to your `.git/config`:
-
-```
-[alias]
- patch = push self HEAD:refs/patches
-```
-
-Which allows you to create a new patch by running `git patch`.
-
-At any point, you can view a repository’s patches using `rad patch`, or you can show a specific one with `rad patch show`.
-
-Here is an example of a patch in the `heartwood` repository:
-
-```
-╭──────────────────────────────────────────────────────────────────────────╮
-│ Title fetch: Update gix packages │
-│ Patch 76f1369e7bab4126e97b175bcddea58f55f3c741 │
-│ Author fintohaps (you) │
-│ Head aed9c2603884a8cd76c433262657d72289bd36bb │
-│ Base caee776c388ffac2ea55cc9d1e3d7fa108ca6df5 │
-│ Commits ahead 1, behind 0 │
-│ Status open │
-│ │
-│ Several vulnerabilities were found in the gix packages[^1][^2][^3]. │
-│ │
-│ Update the packages to their latest versions which include the fixes. │
-│ │
-│ The only required change is in `ls_refs`. │
-│ `RefPrefixes` was introduced and this fixes the issue with `ref-prefix`. │
-│ This should now improve the ls-refs stage and only return references │
-│ that the client is asking for, as opposed to all references. │
-│ │
-│ [^1]: https://github.com/radicle-dev/heartwood/security/dependabot/38 │
-│ [^2]: https://github.com/radicle-dev/heartwood/security/dependabot/39 │
-│ [^3]: https://github.com/radicle-dev/heartwood/security/dependabot/36 │
-├──────────────────────────────────────────────────────────────────────────┤
-│ aed9c26 fetch: Update gix packages │
-├──────────────────────────────────────────────────────────────────────────┤
-│ ● Revision 76f1369 @ caee776..aed9c26 by fintohaps (you) 5 hours ago │
-╰──────────────────────────────────────────────────────────────────────────╯
-```
-
-We never write the perfect set of changes the first time (or at least I do not), so you may need to update a patch after you have modified or added new commits.
-The process is similar to before; however, the reference you target with the remote helper should now contain the identifier of the patch.
-For example, to update the patch above, you would run:
-
-```
-$ git push rad HEAD:patches/76f1369e7bab4126e97b175bcddea58f55f3c741
-```
-
-For convenience, another way is to create a branch called `patches/76f1369e7bab4126e97b175bcddea58f55f3c741` and run:
-
-```
-$ git push rad patches/76f1369e7bab4126e97b175bcddea58f55f3c741
-```
-
-Alternatively, you can create an upstream branch that points to `patches/76f1369e7bab4126e97b175bcddea58f55f3c741`.
-In fact, `rad patch checkout` will do this for you.
-
-## Next steps
-
-Now you know enough about Radicle to be dangerous!
-
-If you want to learn more about how to collaborate, set up your own seed, or dive into the protocol details, then here are some useful links:
-
-- **Collaborate** — Learn about issues and patches in the [User Guide](/guides/user#2-collaborating-the-radicle-way)
-- **Install [Radicle Desktop]** — A simple, intuitive way to interact with the Radicle network
-- **Run a seed node** — Help the network by seeding repositories with the [Seeder Guide](/guides/seeder)
-- **Understand the protocol** — Dive into how Radicle works in the [Protocol Guide](/guides/protocol)
-
-We are a growing community who love to help out when we can.
-If you need help or want to chat to us further about everything Radicle, join us on [Zulip](https://radicle.zulipchat.com)!
-
-[Git remote helper]: https://git-scm.com/docs/gitremote-helpers
-[DID]: https://www.w3.org/TR/did-1.0/
-[systemd]: https://systemd.io/
-[Radicle Desktop]: /install
diff --git a/src/marketing/docs/guides/protocol.md b/src/marketing/docs/guides/protocol.md
deleted file mode 100644
index 45da99c34..000000000
--- a/src/marketing/docs/guides/protocol.md
+++ /dev/null
@@ -1,532 +0,0 @@
----
-title: Radicle Protocol Guide
-subtitle: How Radicle works under the hood
----
-
-
-
-
-
- Protocol Guide | Radicle
-
-
-
-
-# Radicle protocol guide
-
-Heartwood, the latest generation of the [Radicle](/) protocol establishes a sovereign data network for code collaboration and publishing, built on top of [Git][git]. In Radicle, users maintain local copies of their repositories of interest and related social artifacts such as issues and patches. Instead of depending on a centralized service like GitHub, each participant in Radicle operates a node that is capable of running on a personal computer, and is connected via a peer-to-peer network.
-
-Nodes, identified by [public keys][pkc], host and synchronize Git repositories across the network, using a novel gossip protocol for peer and repository discovery, alongside Git’s [protocol][git-v2] for data replication. In combination, this allows nodes to locate, replicate, and verify any repository published to the network, provided at least one other peer seeding the repository is online. Since Radicle is built on Git, it can easily interoperate with existing tools and workflows.
-
-Radicle’s architecture is [local-first][local-first], ensuring continuous access to one’s repositories directly from their device, regardless of internet connectivity. Repositories have unique identifiers and are self-certifying, meaning all actions, from committing code to adding a comment to an issue, are performed locally and [cryptographically signed][signing], allowing peers to verify authenticity and data provenance once propagated to the network. This allows trust to be established without reliance on a centralized authority.
-
-Radicle is designed for extensibility, allowing for diverse use cases without necessitating modifications at the protocol level. This guide delves into the capabilities of Radicle’s initial release, which has a focus on code collaboration and code publishing. Nonetheless, a range of other applications is foreseen in the future and possible today, including knowledge sharing, project coordination, and data set collaboration.
-
-## Introduction
-
-Git, the most widely-used distributed version control system, enables users to maintain and modify personal copies of data repositories, commonly for source code control. Its structure for direct user-to-user collaboration, while feasible, is often cumbersome since Git primarily focuses on version control rather than collaboration. As a result, users frequently opt for centralized [forges][forges] like GitHub or GitLab, which offer enhanced interfaces and collaborative tools on top of Git, such as project management and code review. This dependency, however, can result in vendor lock-in since it places a project’s social artifacts (e.g. issues, comments, pull requests) out of user control, potentially compromising data sovereignty and other user freedoms.
-
-Traditional self-hosted forges like [Gitea][gitea] or [Forgejo][forgejo] provide more sovereignty but often lead to fragmented collaboration environments, as users must create separate profiles for each hosted instance. This simultaneously limits a project’s exposure to the wider open source community, a key advantage of platforms like GitHub, which have grown significantly due to network effects. This isolation can impact the visibility and collaborative potential of projects that choose traditional self-hosted solutions.
-
-The Radicle protocol, in contrast, extends Git’s capabilities with a decentralized identity system, novel gossip protocol, and integrated social artifacts, forming a _self-hosted network for code collaboration_. Radicle locates, serves, and replicates Git repositories -- including artifacts -- across a [peer-to-peer][peer-to-peer] network while maintaining data authenticity via cryptographic signatures, so peers can directly exchange data without the need for a trusted third party. This enables communities to both self-host and share their repositories across a distributed protocol, contributing to the emergence of a new sovereign network for code collaboration and more.
-
-## Nodes
-
-Radicle is a [peer-to-peer][peer-to-peer] system, which means that there is no traditional client-server model. Peers on the Radicle network are referred to as _nodes_, and are indistinguishable from users at the protocol level. Nodes, identified by their [Node ID](#node-identifiers-nids) (NID) -- an [Ed25519][ed25519] public key -- are responsible for seeding Git repositories, each identified by a unique [Repository ID](#repository-identifier-rid) (RID). The seeding process involves both hosting the repository data and synchronizing changes with other nodes. Every Radicle user, irrespective of their role or activity, runs a node on their device. No specialized equipment is necessary for operating a node as a typical end-user; nodes can run on a personal computer without requiring a server.
-
-
-
-### Seeding repositories
-
-Whenever a user clones, initializes, or opts to seed a repository, their node’s seeding policy is changed to reflect their choices. This policy establishes the repositories they are interested in and sets the rules for data retention, and synchronization, allowing users to have direct control over which repositories are kept on their device and offered to the network.
-
-The typical end-user may choose to only seed the repositories they are actively collaborating on. However, more dedicated users may opt to run an always-on **seed node**, offering their infrastructure to the wider Radicle network or to their community. Seed nodes significantly enhance the network’s capacity to provide continuous access to a broad range of repositories. They can vary in their seeding policies, from _public seed nodes_ that openly seed all repositories to _community seed nodes_ that selectively seed repositories from a group of trusted peers.
-
-
-
-### Node identifiers (NIDs)
-
-
-
-Radicle node identity is based on [public-key cryptography][pkc], which makes it easy to verify the authenticity of messages within the network through [digital signatures][signing]. This also allows for consistent identification even as a user’s physical address varies. When setting up a node, users generate their unique key pair, an [Ed25519][ed25519] public and private key, the public part of which is encoded and shared as a [Decentralized Identifier][did] (DID). Creating a node identity requires no permission or coordination: the key pair can be created while offline without providing an email address or any personal identifying information.
-
-
-
-
- Example Node ID encoded as a DID using the
-
-
-It is important to safeguard one’s private key, as if it is either lost or compromised, one will have to generate a new node identity. A changeable, non-unique **alias** can optionally be associated to each node, for easier human identification across the network.
-
-
-
-### Running a node
-
-To run a node and connect to the network, users install Radicle client software that is lightweight and suitable for use on both end-user devices and seed nodes. The reference implementation can be found in the Radicle [Heartwood][heartwood] repository, and is actively maintained by a small team of engineers.
-
-
-
-The Radicle _stack_ is comprised of both the network client and a command line interface (CLI), which can be optionally supplemented with a web frontend. Radicle is released under the open source MIT and Apache 2.0 licenses, to encourage the development of diverse clients and applications. All client software adheres to the Radicle protocol specification, as outlined in the [Radicle Improvement Proposals][rips] (RIPs) repository, ensuring consistent functionality across implementations.
-
-
-
-## Peer-to-peer protocol
-
-Radicle adopts a local-first, peer-to-peer (P2P) architecture, which draws inspiration from Secure Scuttlebutt (SSB) and Bitcoin’s [Lightning Network][ln].
-
-Nodes on the Radicle network subscribe to repository data they are interested in, and peers announce updates that in turn trigger fetches for the underlying content. Just like SSB and Lightning, updates are [gossiped][gossip] on the network until they reach all interested peers.
-
-Peer connections in Radicle are secured thanks to a [Noise protocol][noise] handshake. Radicle uses the [Noise XK][noise-xk] pattern specifically, just like the Lightning Network with the Node ID as the _static key_. This requires nodes to know the Node IDs of their peers before connecting to them, which takes place through the exchange of peer information over the gossip protocol.
-
-Unlike SSB’s focus on social networking via append-only logs, Radicle focuses on code collaboration by incorporating Git’s [object model][git-odb] and [transfer protocol][git-pack] into a peer-to-peer context. This architecture not only leverages Git’s proven efficiency and reliability but also gives users complete autonomy over their social artifacts. Radicle’s peer-to-peer architecture, in contrast to federated systems, ensures no centralized points of failure, allowing the network to persist as long as users operate nodes.
-
-
- 
- A set of connected peers forming a gossip network.
-
-
-### Gossip protocol
-
-The Radicle networking layer is designed as a gossip protocol, where messages are relayed between peers to build routing tables that aid in repository discovery and replication. The core functionality is achieved with three message types, each fulfilling a distinct role:
-
-**Node Announcements** are used for broadcasting Node IDs and physical addresses on which a node is publicly reachable, to facilitate peer discovery.
-
-| Node Announcement | |
-| ----------------- | ------------------------------------- |
-| **`version`** | `u8` - Supported protocol version |
-| **`features`** | `u64` - Advertised node capabilities |
-| **`timestamp`** | `u64` - Message timestamp (unix time) |
-| **`alias`** | `u8[]` - Non-unique alias (UTF-8) |
-| **`addresses`** | `Address[]` - External addresses |
-| **`nonce`** | `u64` - Nonce used for DoS protection |
-| **`agent`** | `u8[]` - User-agent (UTF-8) |
-
-**Inventory Announcements** are used for broadcasting repository inventories and constructing the routing table which maps out what repositories are hosted where.
-
-| Inventory Announcement | |
-| ---------------------- | ------------------------------------- |
-| **`inventory`** | `RepoID[]` - Repository inventory |
-| **`timestamp`** | `u64` - Message timestamp (unix time) |
-
-**Reference Announcements** are used for broadcasting updates to repositories, relayed only to nodes interested in the relevant repository.
-
-| Refs Announcement | |
-| ----------------- | ------------------------------------------------------- |
-| **`rid`** | `RepoID` - Repository that was updated |
-| **`refs`** | `{NodeID, OID}[]` - Updated signed refs (`rad/sigrefs`) |
-| **`timestamp`** | `u64` - Message timestamp (unix time) |
-
-
-
-To prevent endless propagation, nodes drop any message already encountered. However, for the sake of broadcasting messages to new nodes, gossip messages may be temporarily stored and replayed to nodes joining the network for the first time, or after a long period of being offline.
-
-Each announcement includes the originating _Node ID_ along with a _cryptographic signature_ and _timestamp_, allowing network participants to verify the authenticity of messages before relaying them to peers.
-
-
- 
- Announcement message structure.
-
-
-> **Tip**: Refer to [RIP-1][rip-1] to learn more details about Radicle’s networking protocol.
-
-### Transport encryption & privacy
-
-Connections between peers in the Radicle network are encrypted using a [Noise][noise] protocol handshake. This begins with two peers performing a [Diffie-Hellman][ecdh] key exchange to agree on a shared session key that is used for the duration of the connection.
-
-Radicle uses the [XK][noise-xk] handshake pattern, which requires the connection responder’s _static key_ to be known in advance by the initiator. This _pre-sharing_ takes place over the gossip network via the `NodeAnnouncement` message, since the static key is simply the Node ID.
-
-
-
-
- 
-
-
-Once the static key is known, a connection to the node can be initiated securely, by generating an ephemeral key from the static key, using Diffie-Hellman. The last step involves the initiating node sending its own static key over the secure channel.
-
-
- 
-
-
-After the handshake phase is completed, all data exchanged between peers is fully encrypted and benefits from strong [forward secrecy][fs], ensuring secure and private communications across the network.
-
-> **Tip**: Radicle also supports [Tor][tor] addresses. Users can leverage Tor to hide their IP address from peers, and connect to `.onion` addresses on the Tor network.
-
-### Replication via Git
-
-While gossip is used to exchange metadata, actual repository data is transferred via replication using the [Git protocol][git-pack]. The process begins with a node establishing a secure connection to one or more of the repository’s seeds, upon receiving a _reference_ or _inventory_ announcement of interest.
-
-Once connected, the node initiates a Git _fetch_ protocol, which involves negotiating which objects should be sent or skipped by the remote node. The objects are then downloaded into the node’s storage, making them accessible to other nodes via the same process.
-
-Since Radicle uses a [framing][framing] protocol for all its sessions, the fetch protocol is able to take place over the same physical connection between nodes as the gossip protocol. This allows for a more efficient use of resources and avoids certain problems with [NATs][nat]. Although Git’s protocols are typically connection-based, Radicle’s design allows for multiple concurrent Git fetches to take place over a single connection.
-
-
-
-
- 
- Connection multiplexing in Radicle.
-
-
-### Bootstrap nodes
-
-A node joining the network for the first time will not know any peers. Hence, it’s useful to pre-configure network clients with addresses of well-known nodes that can be used to initiate or _bootstrap_ the peer discovery process and build an address book.
-
-Radicle’s reference implementation is pre-configured with two bootstrap nodes that are connected to if the address book is empty: `iris.radicle.network` and `rosa.radicle.network`. These are nodes run by the Radicle team and have large address books that are shared with connecting peers.
-
-In the bootstrapping process, nodes connect to an initial set of bootstrap nodes and once they establish a connection, use the regular peer discovery mechanism to find more peers.
-
-### Federation vs. peer-to-peer
-
-Federation allows for a degree of sovereignty, as each node can set its content policies, but user experience and identity are ultimately tied and mediated by these nodes’ administrators rather than by the users themselves.
-
-> **federation** /ˌfɛdəˈreɪʃn/ _n._
->
-> _(Computing)_ A system architecture where multiple independent servers or nodes operate under a common set of standards and protocols, allowing them to share data, resources, and functionalities across boundaries while maintaining autonomy. This model enables interoperability and collective services among diverse systems without fully centralizing control, thereby enhancing privacy, scalability, and resilience. Each node in a federated network can set its policies, manage its users, and control its data.
-
-
-
-Although federated models promote a level of decentralization, they face unique challenges, such as when node operators decide to block other nodes, taking that choice away from its users and restricting the free flow of information.
-
-Federated systems also face challenges related to incentives; specifically, when the operational costs of maintaining a node exceed the perceived benefits, node operators are often compelled to shut down. This can disrupt access for users, undermining the platform’s reliability and the continuity of service.
-
-While Radicle seed nodes face similar challenges, this has little bearing on the end user: seed nodes are interchangeable and offer an undifferentiated service; they are not tied to a user’s identity or access to the network.
-
-
- 
- Federation (left) vs. peer-to-peer (right).
-
-
-## Repositories
-
-**Repositories** are central to the Radicle network, serving as the primary data abstraction and object shared between peers. A repository in Radicle is fundamentally a Git repository, supplemented with a unique repository identifier (RID) and metadata essential for validating the authenticity of its contents.
-
-Radicle repositories, which can be either public or private, can accommodate diverse content including source code, documentation, and arbitrary data sets. All repositories are initialized with an [identity document](#identity-document) from which a unique Repository ID (RID) is derived.
-
-The identity document is where repository permissions and ownership are defined, as well as identifying metadata such as name and description.
-
-### Delegates
-
-Repositories are managed and owned by what are called _delegates_. A delegate is an individual, group, or bot, identified by a [DID][did]. Delegates are responsible for critical tasks such as merging patches, addressing issues, and modifying repository permissions. A repository always begins with one delegate, its creator, and can eventually grow to multiple delegates.
-
-### Identity document
-
-Before a repository can be published on Radicle, it needs to be initialized with an _identity document_. This JSON document, stored under the `refs/rad/id` reference in Git, encapsulates key metadata such as the repository’s name, description, and default branch. It also includes the DIDs of the repository’s delegates and the _threshold_ of delegate signatures required to authorize changes to the repository’s default branch.
-
-
-
-Here’s an example of the identity document for the [heartwood][heartwood] repository:
-
-```json
-{
- "delegates": ["did:key:z6MknSLrJoTcukLrE435hVNQT4JUhbvWLX4kUzqkEStBU8Vi"],
- "threshold": 1,
- "payload": {
- "xyz.radicle.project": {
- "name": "heartwood",
- "description": "Radicle Heartwood Protocol & Stack",
- "defaultBranch": "master"
- }
- }
-}
-```
-
-### Private repositories
-
-Radicle supports **private repositories** where access is restricted to a designated group of trusted peers. This is achieved by setting the `visibility` attribute in the identity document. For example, the following snippet sets the visibility to _private_, while also allowing a specific peer to have access to the repository.
-
-```json
-{
- ...
- "visibility": {
- "type": "private",
- "allow": ["did:key:z6Mkt67GdsW7715MEfRuP4pSZxJRJh6kj6Y48WRqVv4N1tRk"]
- }
-}
-```
-
-This ensures only nodes in the privacy set can replicate and access the data, maintaining confidentiality. While the data is not encrypted at rest, these repositories rely on selective replication through the _allow list_ for privacy, which renders them invisible and inaccessible to other nodes in the Radicle network.
-
-Note that repository delegates _always_ have access to their private repositories.
-
-### Repository identifier (RID)
-
-To ensure uniqueness and easy identification of repositories, a stable and globally unique identifier, known as the Repository Identifier (RID), is assigned to each repository. The RID is deterministically derived from the initial version of the repository’s identity document. This process involves using Git’s `hash-object` function to produce a 160-bit SHA-1 digest of the document. This is then encoded using [multibase][mb] encoding with the `base-58-btc` alphabet, and prefixed with `rad:`, making it a valid [URN][urn]:
-
-
- Example Repository ID for the heartwood project.
-
-
-Since the RID is derived from the _initial_ version of the repository’s identity document, the document is able to change while the RID remains the same.
-
-[urn]: https://datatracker.ietf.org/doc/html/rfc8141
-[mb]: https://w3c-ccg.github.io/multibase/
-
-> **Tip**: Refer to [RIP-2][rip-2] for more details about how repository identity works in the Radicle protocol.
-
-## Local-first storage
-
-Storage is designed in such a way that it’s easy to transfer data between peers over the network using an unmodified Git protocol. Radicle repositories are simply Git repositories stored in a special location on disk. Peer data is stored within the same repository using Git [namespaces][gns], where Node IDs are used as the namespace. This allows storage to be managed through a partitioned approach where each user maintains their own _namespace_ of a repository, as well as namespaces of other users they have an interest in, all within the same Git repository. These copies are then shared among users across the network.
-
-We can view a peer’s namespace as their “soft-fork” of the repository. It is their own space for making changes to the repository without affecting other namespaces. The peer is the _sole owner and writer_ of this namespace, identified, and verified, by their Node ID.
-
-### Working vs. stored copy
-
-Storage is accessed directly by the node to report its inventory to other nodes, and by the end user through either specialized tooling or the `git` command line tool. Users are typically interacting with two repository copies: the _working copy_, and a remote _stored copy_ that is interacted with via `git push` and `git fetch`, using Radicle’s [git-remote-helper][grh].
-
-This workflow is akin to what most developers are used to, when synchronizing changes between their working copy, and the `origin` remote, which is typically a repository on a hosted Git forge.
-
-Changes to the stored copy are automatically propagated to the network when the user is connected to the internet, but can also be made while offline. This local-first design not only enhances the user experience by making offline work frictionless, but also eliminates the need for centralized servers.
-
-
- 
- Synchronizing the working copy with the stored copy of a repository.
-
-
-### Storage layout
-
-Radicle’s storage layout is designed to support multiple repositories and multiple peers per repository. Each repository is a _bare_ Git repository, stored under a common base directory, identified uniquely with its Repository ID or RID. Instead of each of the repository’s peers storing data in a separate Git repository with a separate [object database][git-odb] (ODB), peer data is stored within the same Git repository using Git [namespaces][gns].
-
-
-
-For each peer, including the local peer, their unique Node ID (NID) is used as the namespace. Thus, each peer has its own namespaced references (eg. `refs/heads`, and `refs/tags`), while sharing the underlying objects (i.e. commits and blobs) with other namespaces via a shared object database. This design ensures only one copy of each object is stored across all repository namespaces.
-
-Since the underlying storage uses Git, the storage layout below is represented as a file tree on the file-system, with `` representing the storage root, or top-level directory under which all repositories are stored on a user’s device. For every repository, each peer associated with that repository must have a separate, logical Git source tree -- which contains all the usual reference categories. This _logical repository_ is also known as the repository _namespace_ or _view_, and allows nodes to maintain local data for all peers in the same physical repository.
-
-```
- # Storage root containing all repositories
-├─ # Storage for first repository
-│ └─ refs # All Git references locally stored
-│ └─ namespaces # All peer source trees or "namespaces"
-│ ├─ # First node's source tree
-│ │ └─ refs # First node's Git references
-│ │ ├─ heads # First node's branches
-│ │ │ └─ master # First node's master branch
-│ │ └─ tags # First node's tags
-│ │
-│ └─ # Second node's source tree
-│ ├─ refs # Second node's references
-│ └─ ...
-├─ # Storage for second repository
-│ ...
-└─ # etc.
- ...
-```
-
-Though this storage tree is browsable by the user with standard file system commands, it is not meant to be interacted with directly by users, for risk of corrupting the data. Additionally, Git is free to pack the objects, which means they may not always appear as individual files.
-
-> **Tip**: Refer to [RIP-3][rip-3] to learn more about storage in the Radicle protocol.
-
-### Git URL scheme
-
-The Radicle protocol uses its own URL scheme to point to specific repository namespaces in the network. This allows the Git `fetch` and `push` commands to operate on the correct namespace when fetching or pushing code.
-
-
- Example URL for repository
-
-
-The Radicle [remote helper][grh] is what allows Git to interpret URLs with the `rad://` scheme. By using this scheme, the user instructs Git to invoke the `git-remote-rad` executable during `git push` or `git fetch`, which allows the user to interact with the network through the storage layer.
-
-For example, the above URL would map a push to the `master` branch to the following path under the local storage root:
-
-```
-//refs/namespaces//refs/heads/master
-```
-
-If a Node ID is not specified in the URL, Git will interact with the repository’s canonical references, also know as the authoritative repository state. This is the state agreed on by the repository [delegates](#delegates).
-
-
- Example URL for repository
-
-
-
-## Trust through self-certification
-
-Unlike centralized forges such as GitHub, where repositories are deemed authentic based on their location (e.g. `https://github.com/bitcoin/bitcoin`), in a decentralized network like Radicle, location is not enough. Instead, we need a way to automatically verify the data we get from _any given location_. This is because peers in a decentralized network may be dishonest. Radicle’s approach hinges on the self-certifying nature of its repositories, anchored in the repository [identity document](#identity-document).
-
-### Canonical branches
-
-When repositories are hosted in a known, trusted location, updating the repository’s canonical branch (eg. `master`) is simply a matter of pushing to that repository’s branch. Permission to push is granted to a small set of maintainers, and any one maintainer is allowed to update the branch.
-
-In Radicle, lacking a central location where repositories are hosted, the canonical branch is established _dynamically_ based on the signature **threshold** defined in the repository’s identity document. For example, if a threshold of two out of three delegates is set, with the default branch set to `master`, and two delegates have pushed the same commit to their `master` branches, that commit is recognized as the authoritative, canonical state of the repository.
-
-> **Note**: Currently, only the branch specified under the `defaultBranch` attribute of the identity document is set automatically based on a signature threshold. In the future, additional branches may be supported.
-
-### Self-certifying repositories
-
-Together, a repository’s RID and its identity document create a cryptographic proof that serves as the basis for verifying all repository states leading up to its current state. For this reason, we say that Radicle repositories are _self-certifying_: the process of verification doesn’t require any inputs other than the repository itself.
-
-For repositories to be self-certifying, delegates authenticate every change to the repository data and metadata via cryptographic signatures. This includes all Git references published to the network.
-
-#### Signed refs
-
-To enable the verification of Git references beyond commits to the source code, Radicle automatically signs the entirety of a node’s references every time they change. This signature is then placed in a Git blob under a special branch referenced under `refs/rad/sigrefs`, along with the references that were signed.
-
-
- Example
-
-
-
-
-Signed refs are key to establishing a repository’s canonical state and are updated whenever there are changes to a repository.
-
-Given an RID and a Radicle repository clone, anyone can retrieve the initial identity document and authenticate all subsequent repository updates without a trusted third party. This verification model draws inspiration from [The Update Framework][tuf] (TUF), a framework designed to secure software update systems.
-
-## Collaborative Objects
-
-In the Radicle protocol, Collaborative Objects (COBs) play an important role in supplementing Git with social artifacts such as issues, code reviews and discussions, which are not inherently supported by Git. Typically, these artifacts are only found on centralized platforms like GitHub or GitLab, or their self-hosted counterparts.
-
-In Radicle, COBs allow for social artifacts to be stored directly inside a repository, and replicated between peers. This means that social artifacts inherit the same properties as source code: they are local-first, user-owned, and cryptographically signed.
-
-Radicle includes three predefined collaborative object types to support code collaboration: _Issues_, _Patches_, and _Identities_, but users have full control to customize them or extend Radicle with entirely new COB types.
-
-- **Issues** (`xyz.radicle.issue`) are used for tracking bugs or feature requests, and support discussions, labeling and assigning.
-- **Patches** (`xyz.radicle.patch`) are used to propose changes to a branch, and support reviews, versioning of changes and discussions.
-- **Identities** (`xyz.radicle.id`) are used to represent identity documents.
-
-
-
-COBs are identified by a unique type name in [reverse domain name notation][reverse-dns] and a unique Object ID.
-
-### Concurrency & consistency
-
-In a system with no central server, operation concurrency is the norm. If two users comment on an issue at the same time, those comments will reach peers in the network at different times and in different orders. To maintain a good user experience, it’s important that these factors don’t determine the issue’s final state. All users must eventually converge to the same exact state and see the same thing.
-
-To achieve this, Radicle makes use of Git’s native synchronization primitives, and encodes COBs as a set of commits in a [directed acyclic graph][dag] (DAG). The identity document is represented by one such commit graph that is disjoint from any other COB or source code branch. Issues are represented as a graph that points to the identity document graph – allowing for inspection of the document at evaluation. Patches are a graph that combines pointing to both the identity document and source code commits. This combination allows for checking if the patch is merged, for example.
-
-This representation gives Radicle a few things for free:
-
-1. Data integrity is guaranteed by Git.
-2. Synchronization is handled by Git.
-3. Causal dependencies can be modeled as commit parent-child relationships.
-
-It may be useful to think of Radicle’s usage of Git commit histories as a form of [conflict-free replicated data type][crdt] (CRDT). When the histories of two peers are synchronized, the commit graphs are simply _unioned_ with each other in a non-destructive, idempotent way.
-
-
-
-
- 
-
-
-Then, to materialize the state that is displayed to the user, this new graph is _reduced_ in [topological order][topo], starting from the root of the graph and going up to the tips. This ordering happens to be [causally consistent][causality], ensuring that changes that have observed other changes are traversed in causal order. Since topological ordering may yield _partial_ orders in the face of concurrency, a merge function is also defined, the simplest of which is to traverse the partially-ordered graph vertices sorted by their commit hash. If a merge function cannot be defined, a COB may be configured to treat this as a _conflict_ which can be bubbled up to the user.
-
-
-
-In summary, this mechanism supports multiple users independently interacting without coordination. Each COB records the initial version of an object and tracks all subsequent modifications made across the network. Each modification is stored as a separate Git _commit_ object to ensure that the CRDT change graph is compatible with Git’s fetch protocol. To retrieve the current state of an object, the system replays all the changes to the object in a deterministic and causally-consistent order.
-
-### Extending COBs
-
-Radicle’s predefined COB types are stored under the `refs/cobs` hierarchy. These are associated with unique namespaces, such as `xyz.radicle.issue` and `xyz.radicle.patch`, to prevent naming collisions.
-
-This hierarchical arrangement under `refs/cobs` not only houses Radicle’s predefined COBs but also accommodates user-defined ones. For example, if a user or organization were to define a new COB type under their domain, it might look something like `com.acme.task`, for some hypothetical “task” COB under the `acme.com` domain.
-
-This extensibility allows for an unlimited set of new collaboration primitives to be defined by users, without requiring coordination with the broader network or user-base.
-
-## Conclusion
-
-The Radicle Heartwood protocol introduces a new approach to code collaboration and hosting rooted in sovereignty. Built upon Git’s well-established protocol, Radicle can easily interoperate with existing systems and workflows that are already familiar. Users have full control and ownership over their identity and data. Repositories are self-certifying data structures, meaning updates are cryptographically signed and can be verified by anyone, without needing a trusted third party. Every user in Radicle is self-hosting while remaining connected to a wider network. Radicle is highly extensible with its Collaborative Objects that enable full control and customization over workflows and datatypes, while also opening the possibility for Radicle to support a wider range of functionalities, potentially extending far beyond code collaboration.
-
-
-
-[gitea]: https://about.gitea.com/
-[forgejo]: https://forgejo.org/
-[git]: https://git-scm.com/
-[gns]: https://git-scm.com/docs/gitnamespaces
-[grh]: https://git-scm.com/docs/gitremote-helpers
-[git-pack]: https://git-scm.com/docs/pack-protocol
-[git-odb]: https://git-scm.com/book/en/v2/Git-Internals-Git-Objects
-[git-v2]: https://git-scm.com/docs/protocol-v2
-[tor]: https://torproject.org/
-[ed25519]: https://ed25519.cr.yp.to/
-[reverse-dns]: https://en.wikipedia.org/wiki/Reverse_domain_name_notation
-[tuf]: https://theupdateframework.github.io/specification/latest/
-[noise]: http://www.noiseprotocol.org/noise.html
-[noise-xk]: https://noiseexplorer.com/patterns/XK/
-[ssb]: https://en.wikipedia.org/wiki/Secure_Scuttlebutt
-[ln]: https://en.wikipedia.org/wiki/Lightning_Network
-[gossip]: https://en.wikipedia.org/wiki/Gossip_protocol
-[causality]: https://en.wikipedia.org/wiki/Causal_consistency
-[dag]: https://en.wikipedia.org/wiki/Directed_acyclic_graph
-[topo]: https://en.wikipedia.org/wiki/Topological_sorting
-[rip-1]: https://radicle.network/nodes/seed.radicle.xyz/rad:z3trNYnLWS11cJWC6BbxDs5niGo82/tree/0001-heartwood.md
-[rip-2]: https://radicle.network/nodes/seed.radicle.xyz/rad:z3trNYnLWS11cJWC6BbxDs5niGo82/tree/0002-identity.md
-[rip-3]: https://radicle.network/nodes/seed.radicle.xyz/rad:z3trNYnLWS11cJWC6BbxDs5niGo82/tree/0003-storage-layout.md
-[nat]: https://en.wikipedia.org/wiki/Network_address_translation
-[framing]: https://en.wikipedia.org/wiki/Frame_(networking)
-[fs]: https://en.wikipedia.org/wiki/Forward_secrecy
-[ecdh]: https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange
-[rips]: https://radicle.network/nodes/seed.radicle.xyz/rad:z3trNYnLWS11cJWC6BbxDs5niGo82
-[heartwood]: https://radicle.network/nodes/seed.radicle.xyz/rad:z3gqcJUoA1n9HaHKufZs5FCSGazv5
-[did]: https://www.w3.org/TR/did-core/
-[seed]: /guides/seeder
-[peer-to-peer]: https://en.wikipedia.org/wiki/Peer-to-peer
-[forges]: https://en.wikipedia.org/wiki/Forge_(software)
-[local-first]: https://www.inkandswitch.com/local-first/
-[signing]: https://en.wikipedia.org/wiki/Digital_signature
-[pkc]: https://en.wikipedia.org/wiki/Public-key_cryptography
-[crdt]: https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type
-
-
diff --git a/src/marketing/docs/guides/seeder.md b/src/marketing/docs/guides/seeder.md
deleted file mode 100644
index 0664bc552..000000000
--- a/src/marketing/docs/guides/seeder.md
+++ /dev/null
@@ -1,528 +0,0 @@
----
-title: Radicle Seeder Guide
-subtitle: How to run a Radicle seed node
----
-
-
-
-
-
- Seeder Guide | Radicle
-
-
-
-
-# Radicle seeder guide
-
-To seed is to give back. By seeding repositories on the Radicle network, you offer bandwidth, storage, and data availability to Radicle users.
-
-In this guide, we’ll go through the various steps required to set up a Radicle _seed node_ on a Linux system. Seeding only requires an internet connection, a public, static IP address, and modest hardware.
-
-We’ll cover public seed nodes with an _open_ seeding policy, as well as community seed nodes with more _selective_ policies.
-
-## Introduction
-
-The term _seed node_ originally comes from [BitTorrent][bittorrent]. In the BitTorrent protocol, nodes that possess the data for a given torrent file and begin uploading it to peers are called _seeders_.
-
-In Radicle, while all users contribute to the network by seeding data, the term _seed node_ specifically refers to a server that is accessible through the internet and hosts content for peers. Seed nodes need to remain online and accessible to provide their service to the network.
-
-### The need for seed nodes
-
-While a peer-to-peer network without seed nodes is feasible, it is impractical. This is because regular “user” nodes go online and offline all the time, so finding a user from which to download a certain piece of content can be challenging, or even impossible if all users with that content are offline.
-
-Therefore, a healthy peer-to-peer network necessitates at least _some_ highly available nodes that participate in the network like regular peers, but seldom go offline. These are called seed nodes.
-
-> By running a _permissive_ node (see below for further explanation), you are contributing to the growth and resilience of the Radicle network, but it is important to be aware of the potential implications of hosting data in a permissionless network. Use your best judgment. If you have any concerns, consider starting with the selective seeding policy, described in the following section, and expanding as you become more comfortable with the network.
-
-## Getting started
-
-For this guide, we’ll focus on setting up a seed node using `systemd`. If you’re running a different service manager, you should be able to follow along just fine, as we’ll be explaining the steps. Using a service manager is not required, but highly recommended.
-
-### What you will need
-
-To run a Radicle seed node, you will need a server with:
-
-- `curl`
-- `git`
-- `systemctl` version `232` or newer
-- `sudo` privileges
-- A DNS name pointing to your server
-
-### Server
-
-If you already have a VPS (Virtual Private Server) or home server running a Linux distribution, you should be all set. If not, any VPS will do. Between 1-2GB of RAM with a shared CPU and 10GB of disk space should be enough to get started. Once you’ve logged into your server, proceed with user setup and installation. For this setup process, you’ll need `sudo` capabilities.
-
-> **Tip**: If you have trouble choosing a VPS, we recommend getting a small instance on [Hetzner][hetzner] or [Digital Ocean][do]. These are priced fairly and have good documentation and support.
-
-[hetzner]: https://www.hetzner.com/
-[do]: https://www.digitalocean.com/
-
-### User setup
-
-If you wish to create a new user under which to run the seed node services, this is the time. In this guide, we’ve chosen to run our services under a user called `seed`. Radicle data and configuration will be stored under this user’s home folder. This ensures that if your Radicle services were to be compromised, the attacker would have very limited access to your system.
-
-Here’s an example user setup with `seed` as the user and group name:
-
-```bash
-sudo groupadd --system seed
-sudo useradd --system --gid seed --create-home seed
-```
-
-If you’re administering your server via a non-root account, you’ll want to add it to the `seed` group as well:
-
-```bash
-sudo usermod -a -G seed $(whoami)
-```
-
-### Installation
-
-For a seed node, you will need to install at minimum the Radicle CLI (`rad`), and network daemon (`radicle-node`).
-
-To install these, head over to the [download](/install#cli) page and follow the instructions there. You will have to download, verify and extract the binaries and manuals to your preferred location.
-
-For this guide, we recommend installing Radicle under `/usr/local`. This will require you to have write permissions to `/usr/local/bin` and `/usr/local/man`. You can give yourself these permission by changing ownership of these directories to the current user and group:
-
-```bash
-sudo chown $(whoami): /usr/local/{bin,man,man/man1}
-```
-
-You should then be able to extract the archive you downloaded and verified with:
-
-```bash
-tar -xvJf --strip-components=1 -C /usr/local/
-```
-
-Finally, login as the `seed` user and proceed with installation:
-
-```bash
-sudo su seed
-```
-
-To check your installation, run the `rad` command, and confirm where your Radicle home is with the `rad path` command.
-
-To offer web browsing and HTTP access to your seed node, you will additionally need to run `radicle-httpd`, the HTTP daemon. We’ll cover this after we’ve set up our basic node.
-
-### Creating a profile
-
-Once the Radicle binaries are installed, we can create a Radicle _profile_. This consists of an Ed25519 key pair and a directory under which Radicle stores user data.
-
-```bash
-rad auth --alias seed.radicle.example
-```
-
-The above command will create a profile with the given node _alias_ in `~/.radicle`, or `$RAD_HOME` if set. We recommend setting your alias to the domain name that points to your node’s host.
-
-For seed nodes, it’s not generally necessary to set up a passphrase for your key, so you can simply skip that prompt by pressing _enter_.
-
-
-
-> **Tip**: If you wish to set a passphrase anyway, you will have to set the `RAD_PASSPHRASE` environment variable in your node’s `systemd` unit file.
-
-Once your profile is initialized, a decentralized identifier (DID) will be output. The part after the `did:key:` prefix is your Node ID. This is how your seed node will be identified on the network. The Node ID is the public part of the Ed25519 key pair generated above, via `rad auth`.
-
-You can view information about your Radicle profile by running `rad self`. The `--nid` and `--alias` flags can be used to return the Node ID and alias.
-
-## Configuring your node
-
-There are a couple of things we need to set up a seed node.
-
-First, we must set the node’s default _seeding policy_.
-
-The seeding policy tells the node which repositories and reference namespaces to fetch and offer to the network. For _public seed nodes_, a _permissive_ seeding policy is often set, such that _all data_ on the network is stored and replicated.
-
-Second, we must set an _External Address_ for the node to be reached on the network. This address will be advertised to peers, allowing them to connect to your seed node. Generally, this will be a DNS name with port `8776`, for example `seed.radicle.example:8776`.
-
-Here’s an example minimal configuration file with a permissive seeding policy and an external address set:
-
-```json
-{
- "node": {
- "alias": "seed.radicle.example",
- "listen": ["0.0.0.0:8776"],
- "externalAddresses": ["seed.radicle.example:8776"],
- "seedingPolicy": {
- "default": "allow",
- "scope": "all"
- }
- }
-}
-```
-
-> In the above example the server listen to any IPv4 interface. If your host supports only IPv6 or if you want to support both IPv4 and IPv6, replace `0.0.0.0` with `[::]`.
-
-Your node is configured with a file named `config.json` in your Radicle home directory. You can get the full path of the config file with the `rad self --config` command. Additionally, you can output the current configuration with `rad config`. Attributes that aren’t set in `config.json` will take on default values. You can open your configuration file for editing with `rad config edit`.
-
-Let’s start by configuring your seeding policy.
-
-### Seeding policies
-
-The most important setting when it comes to seeding is your _default seeding policy_. This setting will determine what content your seed node fetches and replicates on the network when it encounters a repository it doesn’t know or hasn’t been given special instructions for.
-
-The setting is configured under the `node.seedingPolicy` field in your configuration (`~/.radicle/config.json`). You can open your configuration file directly using the `rad config edit` command, or use your preferred editor. You can also enter the following command to display your current default policy:
-
-```bash
-rad config get node.seedingPolicy
-```
-
-When a seeding policy is _not set_ for a specific repository or node, the default policy is applied, hence the importance of this setting.
-
-Broadly, there are two options for the default policy.
-
-#### A _permissive_ seeding policy
-
-A _permissive_ or “open” policy is said to be _fully-replicating_, meaning your seed will try to have a full copy of all repository data available on the network.
-
-An example of a node with this policy is `iris.radicle.network`, a node operated by the Radicle team, for the Radicle community.
-
-This is a good default for seeders who want to support the network without having to think about it too much.
-
-Set `node.seedingPolicy.default` to `allow` and `node.seedingPolicy.scope` to `all` to configure your node this way.
-
-```json
-{
- "node": {
- ...
- "seedingPolicy": {
- "default": "allow",
- "scope": "all"
- }
- }
-}
-```
-
-#### A _selective_ seeding policy
-
-A _selective_ or “restricted” policy requires you, the operator, to _manually allow repositories to be seeded_. This means that the node will ignore all repositories, except the ones that are pre-configured to allow seeding.
-
-An example is the `seed.radicle.xyz` node, which only seeds Radicle team repositories.
-
-This is a good policy for communities, teams, companies and individuals who want to limit the data hosted by their seed, or node operators who want to require some form of authentication or payment for seeding.
-
-Set `node.seedingPolicy.default` to `block` to enable this, and call `rad seed` to configure `allow` policies for specific repositories you want to seed. Your seed node won’t seed anything until you explicitly allow it to.
-
-```json
-{
- "node": {
- ...
- "seedingPolicy": {
- "default": "block"
- }
- }
-}
-```
-
-#### Setting a repository’s seeding policy
-
-To override the default policy for a specific repository, the `seed` or `block` commands are used.
-
-For example, in the case of a _permissive_ seeding policy, where the default is `allow`, we can explicitly _block_ certain repositories from being seeded:
-
-```bash
-rad block rad:z9DV738hJpCa6aQXqvQC4SjaZvsi
-```
-
-This will override the default policy and ensure that this repository is never replicated on your node.
-
-On the other hand, in the case of a _selective_ seeding policy, where the default policy is `block`, we can decide to _allow_ a repository to be seeded by calling `rad seed`. For example:
-
-```bash
-rad seed rad:z3gqcJUoA1n9HaHKufZs5FCSGazv5
-```
-
-This will override the default `block` rule for this one specific repository.
-
-To remove an override configured for a repository in either case, `unseed` can be used:
-
-```bash
-rad unseed rad:z3gqcJUoA1n9HaHKufZs5FCSGazv5
-```
-
-For both cases, the default policy will apply if a seeding policy is not defined for a repository.
-
-#### Viewing seeding policies
-
-You can view your node’s _default policy_ by entering `rad config get node.seedingPolicy`.
-
-To view the policy of a specific repository, use the `rad inspect` command. For example:
-
-```bash
-rad inspect rad:z3gqcJUoA1n9HaHKufZs5FCSGazv5 --policy
-```
-
-This will return the default policy if you haven’t set a specific policy for that repository.
-
-Finally, to view all seeding policies that have been configured on repositories, simply enter `rad seed` with no options.
-
-### Addressing
-
-Now that you’ve configured your seeding policy, it’s time to consider how your node is addressed on the network.
-
-#### Your external address
-
-You should set your node’s external address. This is a public address, typically a DNS name that points to your node. Though a single external address is sufficient, you are free to set up to 16 external addresses.
-
-You’ll find this setting in your configuration file, under `node.externalAddresses`. External addresses are JSON strings of the form `:`, for example `seed.radicle.example:8776`, where `` is a DNS name, and `` is usually `8776`.
-
-```json
-{
- "node": {
- ...
- "externalAddresses": ["seed.radicle.example:8776"]
- }
-}
-```
-
-Once at least one external address is set, you’re ready to start your node for the first time.
-
-#### Your node address
-
-For others to be able to connect to your node directly, they need your _Node Address_. This is a combination of your Node ID and your External Address.
-
-If you’ve configured one or more external addresses, simply entering the following command from the `seed` user will output your node addresses:
-
-```bash
-rad node config --addresses
-```
-
-Share this with others, and they will be able to connect to your node using `rad node connect `, or by adding your address to their configuration, under the `node.connect` field.
-
-#### DNS-based service discovery
-
-If you would like to facilitate discovery of your node via DNS, you can do so via [DNS-Based Service Discovery (DNS-SD)][dnssd]. This requires you to set three DNS records per node you are running.
-
-1. A `SRV` record, which communicates the external address of your node (DNS name and TCP port number).
-2. A `TXT` record, which communicates the Node ID of your node.
-3. A `PTR` record, which makes the other two records discoverable.
-
-Taken together, the `SRV` and `TXT` records contain all the information required to reconstruct your node address.
-
-Suppose the node address you want others to discover is `z6MkXB…Z6sTAz@seed.radicle.example:58776` and the domain name you want it to be discovered for is `radicle.example`, then the three DNS records required are:
-
-```
-seed._radicle-node._tcp.radicle.example. 3600 IN SRV 32767 32767 58776 seed.radicle.example.
-seed._radicle-node._tcp.radicle.example. 3600 IN TXT "nid=z6MkXB…Z6sTAz"
-_radicle-node._tcp.radicle.example. 3600 IN PTR seed._radicle-node._tcp.radicle.example.
-```
-
-With most nameservers, there are shorter versions to denote these records, like dropping TTL and record class, as well as abbreviating names by omitting the origin. The variant above is purposely verbose to avoid ambiguity. Of course, you may choose different values for the TTL.
-
-With these records set, anyone can discover your nodes from the domain name `radicle.example`. This method of discovery is ideal if you maintain a set of nodes, and want to have them discovered by a group of people, such as your collaborators or coworkers. It also works if your nodes addresses and/or ports change frequently.
-
-To find out more about the the interpretation of `SRV` records, refer to [RFC 2782][srv].
-
-## Running your node
-
-Before setting up your node as a system service, it’s a good idea to run it once to make sure everything is working properly. Enter the following command to start your node in the foreground:
-
-```bash
-rad node start --foreground
-```
-
-You should see log output as your node starts to sync with the network. If there are any errors or issues connecting to the network, you should see errors in the output.
-
-If the node started without problem, stop it with `Ctrl-C`, and exit the `seed` session by entering:
-
-```bash
-exit
-```
-
-This should return you to the original session you opened via SSH.
-
-### Configuring your node’s system service
-
-Though it’s possible to simply run the Radicle node as a background process, it’s recommended to set up a service to ensure the node is started on boot.
-
-In this guide, we will only cover setup using `systemd`, but the process is fairly similar for other service managers.
-
-The first thing to do is to get a copy of the [`radicle-node.service`][radicle-node] unit file. Place it in `/etc/systemd/system/radicle-node.service` for it to be found by `systemctl`:
-
-```bash
-curl -sSL https://seed.radicle.xyz/raw/rad:z3gqcJUoA1n9HaHKufZs5FCSGazv5/570a7eb141b6ba001713c46345d79b6fead1ca15/systemd/radicle-node.service -o /etc/systemd/system/radicle-node.service
-```
-
-Make sure it fits your needs by editing the file directly, or creating an override using `systemctl edit`.
-
-> The downloaded `systemd` unit file is configured to run your node process as the `seed` user and group, for security reasons. If you set up a different user or group name, or set a passphrase during `rad auth`, or if you want to listen on an IPv6 interface, you will have to make edits to this file before proceeding.
-
-When you’re ready, you can **enable** and **run** the service:
-
-```bash
-systemctl enable --now radicle-node
-```
-
-### Checking your node status
-
-To check the service status of your node, run:
-
-```bash
-systemctl status radicle-node
-```
-
-Besides using `systemctl status`, you can also check your node’s status using `rad node status`. This will give you information on the peers connected to your node. You’ll have to run this as the `seed` user, like so:
-
-```bash
-sudo -u seed -- rad node status
-```
-
-To tail your node’s logs, use:
-
-```bash
-journalctl --unit radicle-node --follow
-```
-
-### Changing your node’s configuration
-
-If you change your node’s configuration while the node is running, you’ll need to restart your node for the changes to take effect.
-
-First, verify that the new configuration is valid by running `rad config`, then restart your node with:
-
-```bash
-systemctl restart radicle-node
-```
-
-### Securing the `seed` user
-
-Now that your node is configured and working, you can secure the `seed` user by disabling shell access. This is optional, though recommended.
-
-```bash
-chsh -s /usr/sbin/nologin seed
-```
-
-This will prevent anyone from logging in as the `seed` user. Note that from this point onwards, if you chose to disable the `seed` user’s shell, you’ll have to run all commands via `sudo`, like we’ve been doing so far.
-
-> To facilitate running commands as the `seed` user by simply using `rad` as usual, add this alias to your admin shell’s init scripts:
->
-> ```bash
-> alias rad='sudo -u seed -- rad'
-> ```
-
-### Firewalls
-
-If you are running a firewall, ensure that port `8776` is open for TCP connections. This will allow inbound connections to your node.
-
-> It’s recommended to run a basic firewall to further lock down your server, using something like `iptables`, though this is out of scope for this guide.
-
-## Running the HTTP daemon
-
-In the prior sections, we set up `radicle-node`, a background process that actively and continuously discovers and replicates repositories on the network, based on your seeding policy. This node allows users to collaborate, host, share, and publish repositories on the network via the Radicle CLI or any compatible application. However, at this stage, the repositories on your seed node cannot be browsed or viewed without cloning them first, using the Radicle CLI. To enable web browsing of the content of your seed node, the Radicle HTTP Daemon `radicle-httpd` needs to be deployed alongside `radicle-node`.
-
-The HTTP Daemon is a background process that functions as a _gateway_ between the Radicle protocol and the HTTP protocol. It is configured to have direct read-only access to the node’s storage and database and expose this data via an HTTP JSON API. For seed nodes, the HTTP Daemon is always configured as a _read-only_ service over the node’s state.
-
-### Installation
-
-Head over to the [download](/install#cli) page, and follow the instructions there. The process is the same as for the Radicle Node. You will have to download, verify and extract the binary (`radicle-httpd`) and manuals to your preferred location.
-
-We recommend installing the daemon under `/usr/local`, just as we did for the node.
-
-### Configuring your HTTP daemon’s system service
-
-As with `radicle-node`, we can start by downloading an example `systemd` unit file for the daemon:
-
-```bash
-curl -sSL https://seed.radicle.xyz/raw/rad:z3gqcJUoA1n9HaHKufZs5FCSGazv5/570a7eb141b6ba001713c46345d79b6fead1ca15/systemd/radicle-httpd.service -o /etc/systemd/system/radicle-httpd.service
-```
-
-Make sure it fits your needs by editing the file directly, or creating an override using `systemctl edit`.
-
-> In this guide, all `systemd` unit files are configured to run the process as the `seed` user and group, for security reasons. If you set up a different user or group name, you will have to make edits to these files before running the services.
-
-Then, **enable** and **run** the service:
-
-```bash
-systemctl enable --now radicle-httpd
-```
-
-You can check that your node service is running with:
-
-```bash
-systemctl status radicle-httpd
-```
-
-You can query the API with `curl` to ensure everything is working properly:
-
-```bash
-curl http://127.0.0.1:8080/api/v1
-```
-
-### Adding support for HTTPS
-
-For your HTTP Daemon to be accessible from a frontend such as , it needs to respond to HTTPS requests. To do this, we recommend using [Caddy][caddy].
-
-Start by installing `caddy`; most Linux distributions have a package you can install. If you are using Debian or Ubuntu, you can run:
-
-```bash
-apt-get install caddy
-```
-
-If you’re having trouble installing Caddy, check the [installation guide][caddy-install]. Once installed, run `caddy version` to ensure that everything was installed correctly.
-
-```
-caddy version
-v2.6.4 h1:2hwYqiRwk1tf3VruhMpLcYTg+11fCdr8S3jhNAdnPy8=
-```
-
-Then, download the `caddy` unit file from Caddy’s GitHub repository:
-
-```bash
-curl https://raw.githubusercontent.com/caddyserver/dist/master/init/caddy.service -o /etc/systemd/system/caddy.service
-```
-
-Edit the file and change the `User` and `Group` attributes to `seed`, as we have for the other services. Also ensure that `ExecStart` and `ExecReload` are set to the correct path. You can find the path under which `caddy` is installed by running the `which caddy` command.
-
-Finally, edit or create the `Caddyfile` at `/etc/caddy/Caddyfile`, and _replace_ its contents with the following configuration, using the correct domain name for your seed:
-
-```
-seed.radicle.example {
- reverse_proxy 127.0.0.1:8080
-}
-```
-
-This will proxy all HTTPS requests from port `443` to your HTTP daemon running on port `8080`. Make sure your firewall has port `443` open for incomning TCP connections.
-
-Finally, enable and start the Caddy service:
-
-```bash
-systemctl enable --now caddy
-```
-
-If you encounter issues setting up Caddy, you can try following their [guide][caddy-guide] instead.
-
-If everything worked, you should now have HTTPS support for your daemon. To check, run the following command, replacing `seed.radicle.example` with your seed’s domain:
-
-```bash
-curl https://seed.radicle.example/api/v1
-```
-
-You should now be able to visit your seed node via any Radicle web frontend as well. For example, .
-
-> On some distributions, installing `caddy` will start the system service automatically. If you’re not able to connect to your HTTP daemon from the outside, try running `systemctl reload caddy` after you’ve updated the configuration.
-
-## You’re all set
-
-If you got this far, congratulations, you now have a Radicle seed node up and running!
-
-Come join us on our community chat and tell us about your seed node on the [#seeds][zulip] channel.
-
-[radicle-node]: https://seed.radicle.xyz/raw/rad:z3gqcJUoA1n9HaHKufZs5FCSGazv5/570a7eb141b6ba001713c46345d79b6fead1ca15/systemd/radicle-node.service
-[caddy]: https://caddyserver.com/
-[caddy-guide]: https://caddyserver.com/docs/running#linux-service
-[caddy-install]: https://caddyserver.com/docs/install
-[zulip]: https://radicle.zulipchat.com/#narrow/stream/384534-seeds
-[bittorrent]: https://en.wikipedia.org/wiki/BitTorrent
-[dnssd]: https://datatracker.ietf.org/doc/html/rfc6763
-[srv]: https://datatracker.ietf.org/doc/html/rfc2782
-
-
diff --git a/src/marketing/docs/guides/user.md b/src/marketing/docs/guides/user.md
deleted file mode 100644
index 3ed21d9bf..000000000
--- a/src/marketing/docs/guides/user.md
+++ /dev/null
@@ -1,1677 +0,0 @@
----
-title: Radicle User Guide
-subtitle: A fantastic journey through the Radicle universe
----
-
-
-
-
-
- User Guide | Radicle
-
-
-
-
-# Radicle user guide
-
-Software is _the_ fundamental way in which we interface with data that comprises our current reality, and code is the language of software. Most software systems were created through a collaborative process involving multiple people. If we accept that software is important and collaborative by nature, then a shared system for communicating about code and collaborating is needed. This system shouldn’t be owned by one company, as code is too important to be monopolized.
-
-
-
-Furthermore, our world is increasingly polarized, and this reality is finding its way into software companies and therefore into software products. Users are banned from using a platform because of their geographic location or the ideas they stand for. This is not tenable.
-
-This is why we’ve created Radicle, an open protocol that enables users like you to collaborate on your code within a sovereign network. It’s a neutral environment where you have full ownership of your data and you have the autonomy to set the rules of your code universe as you see fit. You can work on software projects (and ultimately more) even when offline, while also being connected to a broader network, through which you’ll eventually be able to find contributors.
-
-We’ve created this Radicle Guide to initiate you as a settler of our network through teaching you how to use the software we’ve developed—the Radicle CLI, which is both a node and command line interface tool for interacting with the protocol. This guide is split into multiple chapters and we recommend starting with the first chapter for a higher level introduction that takes you on a tour through Radicle’s core functions. Subsequent chapters will provide deeper dives into specific use cases, but they are still in progress.
-
-> 👾
->
-> Greetings, I’m your guide! Whenever you see 👾, it’s because I’ve got some spicy tips on how to use Radicle. You’ll also see 🥷 for privacy tips, 👻 for things you should be wary of, and 🧠 for opportunities to learn more.
->
-> If you ever get stuck and want additional guidance, join us in our [chatroom][zulip] on Zulip and ask your questions in the `#support` channel.
->
-> Also, this guide teaches you how to use Radicle in a narrative fashion. If you’re looking for more straightforward usage docs, check out the Radicle manual or the [Protocol Guide][proto] for more information on Radicle’s fundamental building blocks and motivations.
-
-
-
-## 1. Getting started
-
-One of the important facts to understand about Radicle is that it is a peer-to-peer protocol, which is uncommon when it comes to software you typically rely on. Most collaboration technologies are hinged upon a client-server model, where you’re entrusting your data and social interactions to a single entity that is managing a bunch of servers or data centers. This paradigm is transformed in a peer-to-peer protocol, where every user of the protocol is a _peer_, participating equally. Peers on the Radicle network are also referred to as **nodes**, and it doesn’t matter what you are doing -- whether you’re publishing repositories or discussing issues -- you have to run a node.
-
-Within a few paragraphs, you’ll be operating a Radicle Node via the command line by installing the Radicle software stack. It’s a pretty easy process that can be completed in under 5 minutes, but there are a few requirements that are important to run through before you proceed:
-
-1. You need a Linux or Unix based operating system like macOS or Ubuntu and a basic understanding of how to use your terminal.
-2. Radicle is built on top of Git, so a recent version of Git (2.34.0 or later) is recommended. We also assume you have _some_ experience using Git.
-3. OpenSSH (version 9.1 or later) with ssh-agent has to also be installed and running. This is a helper program that is used to secure the secret key related to your Radicle identity.
-
-
-
-> 👾
->
-> You can check your Git and SSH installations by running `git --version` or `ssh -V` in your terminal.
->
-> If you haven’t used Git before, you’re going to be in a world of pain and should read through the [Pro Git][pro-git] book first.
-
-[pro-git]: https://git-scm.com/book/en/v2
-
-### Installation
-
-The easiest way to install Radicle is by firing up your terminal and running the following command:
-
-```
-$ curl -sSLf https://radicle.dev/install | sh
-```
-
-This command runs an installer script that automates the setup process, by:
-
-- Identifying your OS, and installing Radicle binaries suitable for your system, including `rad`, `git-remote-rad`, `radicle-node`, and `radicle-httpd`, all placed in `~/.radicle/bin` by default. This is a non-standard location, so the script also updates your `PATH` variable to include the path to these binaries.
-- Installing `man` pages into `~/.radicle/man`, which enables you to access the Radicle CLI user manual through `man rad` or `rad help`.
-
-> 👾
->
-> If you want the above to be installed in a different location than `~/.radicle`, you can pass `--prefix` to the installation script, eg. `--prefix=/usr/local`.
->
-> Note that if you don’t want to use the installer script, you can also always compile from the [source code][heartwood] or get the [binaries] if you prefer.
-
-[heartwood]: https://radicle.network/nodes/seed.radicle.xyz/rad:z3gqcJUoA1n9HaHKufZs5FCSGazv5
-[binaries]: /download
-
-Once you’ve installed Radicle, you can make sure that it was successful by running:
-
-```
-$ rad --version
-```
-
-### Come into being from the _elliptic aether_
-
-When using Radicle for the first time, you have to create a new Radicle identity, which is simply a cryptographic key pair, using the `rad-auth` command. The public key is what uniquely identifies you across the network, while the private key is used to authenticate your node, as well as sign code and other artifacts you publish on the network.
-
-
-
-```
-$ rad auth
-```
-
-That’s how you’ll cryptographically forge your new Radicle identity.
-
-Follow the instructions by entering an **alias**, a non-unique name that makes it easier to identify your node, in addition to a **passphrase** to protect your key pair. Note that your alias can always be changed at a later time.
-
-```
-$ rad auth
-
-Initializing your radicle 👾 identity
-
-✓ Enter your alias: paxel
-✓ Enter a passphrase: ********
-✓ Creating your Ed25519 keypair...
-✓ Adding your radicle key to ssh-agent...
-✓ Your Radicle DID is did:key:z6Mkhp7VUnuufpvuQ3PdysShAjL86VDRUpPpkesqiysDBGs9. This identifies your device. Run `rad self` to show it at all times.
-✓ You're all set.
-...
-```
-
-When you’ve completed the steps, your new Radicle DID (Decentralized Identifier) will be generated and displayed. If `ssh-agent` is running, your private key will also be added to it for future use. While similar to your Node ID (NID), the Radicle DID is formatted as a [Decentralized Identifier][did], whereas the NID is simply the encoded public key. The Radicle DID is your own [self-sovereign][ssi] identity. Share it freely with collaborators!
-
-
-
-[ssi]: https://en.wikipedia.org/wiki/Self-sovereign_identity
-
-
-
-If you run `rad auth` again you can verify that your key was added to `ssh-agent`.
-
-```
-$ rad auth
-✓ Radicle key already in ssh-agent
-```
-
-> 👻
->
-> If you plan on using multiple devices, it is very important that you do not try to share your Radicle identity across those devices.
->
-> At the moment, each device is required to be identified by its own DID, meaning you have to go through the `rad auth` process on each device you plan on using.
->
-> We understand the desire and need to link devices to make collaboration smoother. We are in the process of designing and implementing this functionality.
-
-If you forget your DID, you can query your full identity by running `rad self` or alternatively you can grab your DID with `rad self --did`. If you need your NID, you can query for it with `rad node status --only nid`.
-
-```
-$ rad self
-Alias paxel
-DID did:key:z6Mkhp7VUnuufpvuQ3PdysShAjL86VDRUpPpkesqiysDBGs9
-└╴Node ID (NID) z6Mkhp7VUnuufpvuQ3PdysShAjL86VDRUpPpkesqiysDBGs9
-SSH running (3817)
-├╴Key (hash) SHA256:YCmRe6BkDOp45lYg0m5DeYxgRcPKftQZb4RmQD1nkjQ
-└╴Key (full) ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIO9xo9DHlsZJeZWnZaaawsnKFjcQxN4LQ…
-Home /home/paxel/.radicle
-├╴Config /home/paxel/.radicle/config.json
-├╴Storage /home/paxel/.radicle/storage
-├╴Keys /home/paxel/.radicle/keys
-└╴Node /home/paxel/.radicle/node
-```
-
-This displays your alias, DID, SSH agent status, SSH keys, and the locations of important files or directories.
-
-```
-$ rad self --did
-did:key:z6Mkhp7VUnuufpvuQ3PdysShAjL86VDRUpPpkesqiysDBGs9
-```
-
-For focusing on your DID.
-
-```
-$ rad node status --only nid
-z6Mkhp7VUnuufpvuQ3PdysShAjL86VDRUpPpkesqiysDBGs9
-```
-
-For getting the NID of the current, running node.
-
-> 👾
->
-> Many of the other items you see in the `rad self` output can be viewed individually. Wondering about your alias? A quick `rad self --alias` has you covered. Need to pinpoint your Radicle home folder? `rad self --home` is your friend. And for your config file location, just hit up `rad self --config`.
->
-> If you’re ever feeling lost, `rad self --help` will lay out all your options.
-
-### Operate nodes, smoothly
-
-Now that your node has an identity (or ’public key’), you have what it takes to connect to the Radicle Network. That’s right -- we don’t need your email address or any other personal identifying information. Your alias can be your cat’s name for all we care.
-
-The first command to embed deep within your consciousness is the one for checking your node’s status:
-
-```
-$ rad node status
-```
-
-If the node is not running, you can start it as a background daemon with:
-
-```
-$ rad node start
-```
-
-After your node starts, it will attempt to connect to peers on the network.
-
-But let’s take a step back and ponder some fundamental questions: _What exactly happens when these nodes interact? And how does Git fit into this picture?_
-
-At its core, Radicle marries Git with peer-to-peer networking. Your node isn’t just another cog in the machine; it’s a conduit for collaboration. It’s there _to host and synchronize repositories you’re interested in_.
-
-Radicle’s peer-to-peer architecture draws inspiration from [Secure Scuttlebutt’s][ssb] gossip protocol where data transmission relies on a publish/subscribe system, allowing peers to host and sync only the data they care about. Similar to [BitTorrent][bt], we use the terminology “seeding” to describe distributing and sharing a repository across the network.
-
-With Radicle’s gossip protocol, peers exchange messages about the network that facilitate the discovery and replication of repositories. The replication process kicks off when a node establishes a secure connection with another node, the initiating node conducts a _fetch_ operation via the Git protocol to pull the pertinent objects into the node’s storage, thereby availing them to the local user and other interested nodes.
-
-
-
-> If you’re curious about how Radicle works under the hood, read our [Protocol Guide][proto].
-
-### Git going with repositories
-
-Now, time to return to your terminal. The next thing we’ll do is publish a repository to the Radicle network. Once we’ve done this, anyone with a node will be able to fetch and seed your repository, increasing its replica count on the network.
-
-
-
-Pick a repository you maintain and navigate to a local copy. It can be any Git repository, but it should have at least one commit.
-
-```
-$ pwd
-/home/paxel/src/dark-star
-
-$ git status
-On branch master
-Your branch is up to date with 'origin/master'.
-nothing to commit, working tree clean
-```
-
-To publish it to the Radicle network, run the `rad init` command.
-
-```
-$ rad init
-
-Initializing radicle 👾 project in .
-
-✓ Name: dark-star
-✓ Description: Decoding data from the dark star to establish a model of the universe
-✓ Default branch: main
-✓ Visibility: public
-✓ Project dark-star created.
-
-Your project's Repository ID (RID) is rad:z31hE1wco9132nedN3mm5qJjyotna.
-You can show it any time by running `rad .` from this directory.
-
-✓ Project successfully announced to the network.
-
-Your project has been announced to the network and is now discoverable by peers.
-You can check for any nodes that have replicated your project by running `rad sync status`.
-
-To push changes, run `git push`.
-```
-
-Don’t be afraid to do this on one of your existing public repositories! Because even if you aren’t ready to use Radicle for code collaboration, it works great for distribution. Radicle’s network of seed nodes help propagate and host code, forming a decentralized, censorship resistant, and ungovernable distribution system.
-
-What `rad init` does is gather the essential details from you which are needed to initialize the repository into Radicle: the repository name, description, default branch (typically `main` or `master`), and whether it is public or private.
-
-Similar to how `git init` is used to initialize a Git repository, we use nomenclature you’re familiar with so you don’t go crazy. That’d be so cruel if you had to do `rad new`, instead, wouldn’t it?
-
-> 👻
->
-> It’s important to only publish repositories you own or are a maintainer of, and to communicate with the other maintainers so that they don’t initialize redundant repository identities.
-
-After entering your repository details, you’re presented with a Repository Identifier (RID) that is a globally unique URN that you can share with your collaborators or friends so that they can clone or seed your repository. Besides generating the RID, `rad init` creates a special Git remote in your working copy named `rad` and publishes the repository to the network (assuming it’s public). We’ll talk more about private repositories in another chapter.
-
-
-
-
-
-When you initialize a repository you are the sole maintainer or _delegate_, the term used in Radicle. Delegates can represent a group, person or even a bot. In your case, I’m assuming you’re a person. Delegates can be added or removed from a repository, by existing delegates. We’ll talk about this more in one of the next chapters.
-
-> 👾
->
-> A few spicy commands you might want to know about, that can be run within a repository you’ve initialized:
->
-> - It’s difficult to memorize RIDs. Use `rad .` to display the current repository’s RID.
-> - To display the repository’s identity payload, which contains its name, description and default branch, run `rad inspect --payload`.
-> - To be able to push changes to a repository from all of your devices, simply add each device’s DID as a repository delegate, using `rad id update`.
-> - For more details on managing the repository’s identity, including adding delegates, or making updates to its name, description, and visibility, refer to `rad id --help`.
->
-> By the way since your Radicle key is a valid SSH key, it can be used to sign Git commits since version Git `2.34.0`. This is an alternative to the more common GPG signing method. If you’d like to setup your repository to use your Radicle key for signing commits, enter these commands from its working directory:
->
-> ```
-> git config user.signingKey "$(rad self --ssh-key)"
-> git config gpg.format ssh
-> git config gpg.ssh.program ssh-keygen
-> git config gpg.ssh.allowedSignersFile .gitsigners
-> git config commit.gpgsign true
-> ```
->
-> You can also set this up globally by passing the `--global` option to `git config`.
->
-> Commit signing is a purely optional step; Radicle internally signs everything you publish anyway, so don’t worry if you don’t set this up!
-
-Note that your new repository will only be replicated by nodes that you are connected to and either have an open seeding policy, or follow you. Seeding involves both hosting the repository and synchronizing changes with other nodes. In the early stages of the Radicle network, all public repositories are automatically seeded by `iris.radicle.network` and `rosa.radicle.network` which are _public seed nodes_ run by the core team.
-
-
-
-You don’t _have_ to trust or rely on our public seed node. You can run your own. As more people run them, Radicle becomes more resilient and reliable for code collaboration.
-
-> We are always looking to attract more people that want to operate public seed nodes: if that’s you, check out our [Seeder’s Guide][seeder] for more details.
-
-### Publishing _ch-ch-ch-ch-changes_
-
-` or `--push-option=`. Radicle as well as other forges use these to configure a push.
->
-> Radicle supports other options such as:
->
-> - `-o sync`: force a network sync after the push.
-> - `-o no-sync`: don’t wait for sync after the push.
-> - -`o patch.draft`: open a “draft” patch.
->
-> See `man rad-patch` for the full list of options.
-
-If we look at the patch now, we’ll see the new revision Calyx just pushed:
-
-```
-$ rad patch show e5f0a5a
-...
-│ ● opened by z6MkvZw…7aCGq3C (b766431) 2 hours ago │
-│ ↑ updated to 4d0c1156f8ac7af2297d1314cd7556185cd16ae4 (80b8d42) 2 hours ago │
-│ * revised by calyx in 1e0596d (25f8515) 3 minutes ago │
-╰─────────────────────────────────────────────────────────────────────────────╯
-```
-
-Here we see that Calyx’s changes are associated to the revision identifier starting with `1e0596d` and to the commit hash `25f8515`.
-
-To merge this latest revision, Calyx uses regular Git commands. When Radicle detects that a patch’s revision was merged into the main branch, the associated patch is marked as _merged_.
-
-
-
-First Calyx merges the patch’s changeset into the `main` branch, by merging the patch branch he is on:
-
-```
-$ git checkout main
-Switched to branch 'main'
-Your branch is up to date with 'rad/main'.
-$ git merge patch/e5f0a5a
-Updating e81db74..25f8515
-Fast-forward
-data/897af.log | 50382 ++++++++++
-1 file changed, 50382 insertions(+)
-create mode 100644 data/897af.log
-```
-
-Then he pushes `main` to the `rad` remote.
-
-```
-$ git push rad main
-✓ Patch e5f0a5a5adaa33c3b931235967e4930ece9bb617 merged at revision 1e0596d
-✓ Canonical head updated to 25f851529d68180a780cfafc15a48b89208ba8c4
-✓ Synced with 7 node(s)
-
-To rad://z3cyotNHuasWowQ2h4yF9c3tFFdvc/z6Mkgom1bTxdh9fMFxFNXFMw3SbXnma6NARdsfcFuunurCap
- e81db74..25f8515 main -> main
-```
-
-This marks the patch as _merged_, as seen in the output, updates the repository’s **canonical** or “authoritative” state to `25f851`, and synchronizes the changes with the network.
-
-The patch no longer shows up under `rad patch`:
-
-```
-$ rad patch
-Nothing to show.
-```
-
-We can verify that it is merged via `rad patch show e5f0a5a`, or `rad patch --merged`, which shows all merged patches.
-
-> 👾
->
-> Patch commands work similar to issues. You can:
->
-> - Edit with `rad patch edit`.
-> - Label with `rad patch label`.
-> - Archive with `rad patch archive`.
->
-> For more details on how to work with patches, read the manual with `man rad-patch`.
-
-### From remote viewing to adding remotes
-
-Whenever you `init` or `clone` a repository, your node will follow all peers for that repository, which means that everyone’s patches and issues will be synchronized to your device.
-
-You can change this behavior by specifying a different scope when cloning or initializing a repository, with the `--scope` option. For example, `--scope followed` will only synchronize changes by peers you explicitly follow with the `rad follow` command. The default is `--scope all`.
-
-But if a peer becomes a regular collaborator, it would be useful to add them as a Git remote to track their changes and `checkout` their branches, even if they haven’t been submitted as patches. The `rad remote` family of commands can help you achieve this.
-
-Calyx decides to do this, and adds us (Paxel) as a remote:
-
-```
-rad remote add z6MkvZwzK64f3GuDcAs6dEcje89ddfHkBjS1v9Dkh7aCGq3C --name paxel
-```
-
-This allows Calyx to keep up with our changes by creating a remote tracking branch in his working copy, that has our main branch as its upstream.
-
-/.tor/radicle`.
->
-> If you are a **Debian** user who got Tor from a Debian repo, you may need to change the ownership of the `radicle` directory to the `debian-tor` user and group after creating it:
->
-> ```
-> $ sudo chown -R debian-tor:debian-tor /var/lib/tor/radicle
-> ```
-
-#### Configuring Radicle in _Mixed Mode_
-
-Now that we have Tor properly set up, it’s time to configure the networking on our Radicle node to work with it. There are several configuration options available, but for our use case, we’ll implement the _Mixed Mode_ where only connections to `.onion` addresses go through Tor, while regular connections go through the regular internet. For our particular use-case, we’re trying to collaborate on a private repository, not to hide our IP address.
-
-This configuration offers a balance between privacy and performance:
-
-- It maintains low latency for regular public nodes.
-- It allows connectivity through Tor, for nodes that are exposed as an onion service.
-
-
-
- Tor Mixed Mode.
-
-
-To set this up, we first ensure that our Radicle node is stopped and then edit our node’s configuration file:
-
-```
-$ rad node stop
-$ rad config edit
-```
-
-Under the `node` key in our configuration, we define a new `onion` attribute as follows:
-
-```json
-"node": {
- ...
- "onion": {
- "mode": "proxy",
- "address": "127.0.0.1:9050"
- }
-}
-```
-
-This tells Radicle that for `.onion` addresses, we want to use the specified Tor _SOCKS5_ proxy address. This is the address on which the Tor daemon should be listening.
-
-Next, we ensure our node is listening for incoming connections on port `8776`. This is the port that our Tor proxy will be using to bridge connections to our node, and is the same as the `HiddenServicePort` in our Tor configuration.
-
-```json
-"node": {
- ...
- "listen": ["0.0.0.0:8776"]
-}
-```
-
-Finally, if we want our `.onion` address to be publicly _discoverable_ on the network, we add it to our `externalAddresses`, including the port. This will configure our node to advertise its `.onion` address to peers.
-
-```json
-"node": {
- ...
- "externalAddresses": [
- "1odmmeotgcfx65l5hn6ejkaruvai222vs7o7tmtllszqk5xbysolfdd.onion:8776"
- ]
-}
-```
-
-> 👾 This is the `.onion` address we obtained earlier from the Tor `hostname` file.
-
-Note that this is **optional**: if you don’t specify it here, peers will still be able to connect to you if they know your `.onion` address.
-
-This configuration allows our node to use Tor for `.onion` connections while maintaining direct connections for regular traffic, balancing our privacy and performance needs.
-
-#### Making connections
-
-Now that we have updated our configuration, we can start up our node again:
-
-```
-$ rad node start
-```
-
-Since our node is online, Calyx can now continue to collaborate with us on `schrödingers-paradox`. He uses the `rad node connect` command to establish a direct connection with us:
-
-
-
-```
-$ rad node connect z6Mkhp7VUnuufpvuQ3PdysShAjL86VDRUpPpkesqiysDBGs9@odmmeotgcfx65l5hn6ejkaruvai222vs7o7tmtllszqk5xbysolfdd.onion:8776
-```
-
-Notice that the connect address is a combination of the peer’s NID and its `.onion` address:
-
-```
-` @ : `
-```
-
-Tor connections can take some time to establish as a route through the network of relays is computed. If you want your node to maintain a persistent connection to a peer even after your node is restarted, simply add the above address to the `connect` field in your node configuration:
-
-```json
-"node": {
- ...
- "connect": [
- "z6Mkhp7VUnuufpvuQ3PdysShAjL86VDRUpPpkesqiysDBGs9@odmmeotgcfx65l5hn6ejkaruvai222vs7o7tmtllszqk5xbysolfdd.onion:8776"
- ]
-}
-```
-
-By leveraging Radicle’s private repositories and the Tor network, we protected our project’s confidentiality and stood resilient in the face of attacks on our infrastructure. When nodes are _Torrified_ like ours is, it’s also easy for other peers to establish connections directly with us, without requiring an intermediary seed node.
-
-> 👾
->
-> Of course, Tor can also be set up on a seed node for a persistent, private connection. Simply follow the previous Tor configuration steps on your seed node, and enable it as a system service that starts automatically on boot using `sudo systemctl enable tor`.
-
-### Alternative Tor configurations
-
-While Mixed Mode allows us to connect to Tor nodes and traverse NATs, there are two additional configurations that offer more comprehensive network privacy through Tor, at the expense of network latency. These options route all Radicle traffic through the Tor network, including to nodes that are not configured with Tor.
-
-#### Full proxy mode
-
-Full Proxy Mode routes all traffic through Tor for maximum anonymity.
-
-
-
- Tor Full Proxy Mode.
-
-
-Instead of setting up a proxy only for `.onion` addresses, we set up a global proxy for all address types:
-
-```json
-"node": {
- ...
- "proxy": "127.0.0.1:9050"
-}
-```
-
-Then, we change the `mode` for `.onion` addresses to `forward`, and remove the `proxy` configuration from there:
-
-```json
-"node": {
- ...
- "onion": {
- "mode": "forward"
- }
-}
-```
-
-The `listen` and `externalAddresses` configuration doesn’t change.
-
-#### Transparent proxy mode
-
-If you’ve already set up a fully transparent Tor proxy on your network, simply omit the global proxy configuration, and set the `.onion` configuration to `forward`:
-
-
-
-```json
-"node": {
- ...
- "onion": {
- "mode": "forward"
- }
-}
-```
-
-This will configure your node to use your operating system’s DNS resolver to resolve `.onion` addresses.
-
-> 👻
->
-> Radicle’s codebase hasn’t yet undergone formal security audits. While we’re confident in its security, undiscovered vulnerabilities may exist. If you encounter any issues, we encourage you to report them to **security@radicle.xyz**.
-
-[proto]: /guides/protocol/
-[seeder]: /guides/seeder/
-[zulip]: https://radicle.zulipchat.com/
-[did]: https://en.wikipedia.org/wiki/Decentralized_identifier
-[ssb]: https://en.wikipedia.org/wiki/Secure_Scuttlebutt
-[bt]: https://en.wikipedia.org/wiki/BitTorrent
-[tor]: https://www.torproject.org
-[install-tor]: https://community.torproject.org/onion-services/setup/install/
-[cyph-man]: https://www.activism.net/cypherpunk/manifesto.html
-[heartwood]: https://radicle.network/nodes/seed.radicle.xyz/rad:z3gqcJUoA1n9HaHKufZs5FCSGazv5
-[cobs]: /guides/protocol/#collaborative-objects
-[ch1]: /guides/user/#1-getting-started
-[ch2]: /guides/user/#2-collaborating-the-radicle-way
-[ch3]: /guides/user/#3-grow-resilient-with-seeding
-[ch4]: /guides/user/#4-embracing-the-onion
diff --git a/src/marketing/guides.ts b/src/marketing/guides.ts
index ddcbd9f78..1d661dc97 100644
--- a/src/marketing/guides.ts
+++ b/src/marketing/guides.ts
@@ -14,35 +14,35 @@ export const guides: Guide[] = [
title: "Getting started",
description:
"New to Radicle? This quick-start walks you through installing the stack, creating your identity, and opening your first patch.",
- href: "/guides/getting-started",
+ href: "https://radicle.dev/guides/quick-start/",
image: "/marketing/images/learn/getting-started.jpg",
- external: false,
+ external: true,
video: false,
},
{
title: "Protocol guide",
description:
"Gossip, replication, identity, and the data structures behind it all.",
- href: "/guides/protocol",
+ href: "https://radicle.dev/guides/protocol/",
image: "/marketing/images/learn/protocol.jpg",
- external: false,
+ external: true,
video: false,
},
{
title: "Seeder guide",
description: "Run a public seed node to keep repositories available 24/7.",
- href: "/guides/seeder",
+ href: "https://radicle.dev/guides/seeder/",
image: "/marketing/images/learn/seeder.jpg",
- external: false,
+ external: true,
video: false,
},
{
title: "User guide",
description:
"Create an identity, open patches, manage issues, and collaborate from the CLI.",
- href: "/guides/user",
+ href: "https://radicle.dev/guides/user/",
image: "/marketing/images/learn/user.jpg",
- external: false,
+ external: true,
video: false,
},
{
diff --git a/src/marketing/router.ts b/src/marketing/router.ts
index fa91e2fe2..9a7180a8f 100644
--- a/src/marketing/router.ts
+++ b/src/marketing/router.ts
@@ -1,8 +1,6 @@
import type { ComponentType } from "svelte";
import type { DocsLoadedRoute, DocsPage, DocsRoute } from "./types";
-import { isDocsPage } from "./types";
-
export type {
CliRoute,
DesktopRoute,
@@ -24,19 +22,11 @@ const docsLoaders = new Map<
>([
["glossary", () => import("./docs/glossary.md")],
["download", () => import("./docs/download.md")],
- ["guides/getting-started", () => import("./docs/guides/getting-started.md")],
- ["guides/protocol", () => import("./docs/guides/protocol.md")],
- ["guides/seeder", () => import("./docs/guides/seeder.md")],
- ["guides/user", () => import("./docs/guides/user.md")],
]);
const docsTitles = new Map([
["glossary", "Glossary"],
["download", "Download"],
- ["guides/getting-started", "Getting started"],
- ["guides/protocol", "Protocol guide"],
- ["guides/seeder", "Seeder guide"],
- ["guides/user", "User guide"],
]);
export function docsTitle(page: DocsPage): string[] {
@@ -84,18 +74,10 @@ export function marketingRoute(
return segments.length === 0
? { resource: "docs", params: { page: resource } }
: null;
- case "guides": {
- // Bare `/guides` is the all-guides index; `/guides/` is a doc.
- if (segments.length === 0) {
- return { resource: "guides", params: undefined };
- }
- const guide = segments.shift();
- const page = guide ? `guides/${guide}` : undefined;
- if (page && isDocsPage(page) && segments.length === 0) {
- return { resource: "docs", params: { page } };
- }
- return null;
- }
+ case "guides":
+ return segments.length === 0
+ ? { resource: "guides", params: undefined }
+ : null;
default:
return null;
}
diff --git a/src/marketing/types.ts b/src/marketing/types.ts
index 36b6db2e4..7b5169de3 100644
--- a/src/marketing/types.ts
+++ b/src/marketing/types.ts
@@ -35,26 +35,7 @@ export interface PrinciplesRoute {
params: undefined;
}
-export type DocsPage =
- | "glossary"
- | "download"
- | "guides/getting-started"
- | "guides/protocol"
- | "guides/seeder"
- | "guides/user";
-
-const docsPages: DocsPage[] = [
- "glossary",
- "download",
- "guides/getting-started",
- "guides/protocol",
- "guides/seeder",
- "guides/user",
-];
-
-export function isDocsPage(page: string): page is DocsPage {
- return (docsPages as string[]).includes(page);
-}
+export type DocsPage = "glossary" | "download";
export interface DocsRoute {
resource: "docs";
did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK
- did:key
- method.
-
-
-
-
-
- rad:z3gqcJUoA1n9HaHKufZs5FCSGazv5
-
- rad://z42hL2jL4XNk6K8oHQaSWfMgCL7ji/z6MknSLrJoTcukLrE435hVNQT4JUhbvWLX4kUzqkEStBU8Vi-
z42hL2jL4XNk6K8oHQaSWfMgCL7ji and
- peer z6MknSLrJoTcukLrE435hVNQT4JUhbvWLX4kUzqkEStBU8Vi. rad://z42hL2jL4XNk6K8oHQaSWfMgCL7ji
- z42hL2jL4XNk6K8oHQaSWfMgCL7ji’s canonical
- references.9767b485c2aad1e23097d2b5165287ba84cfa452 refs/heads/master -f3eaa7454e3a4714885905ae99f616fc7895b5fa refs/cobs/xyz.radicle.patch/fe31d5b6049583a42c21a543545d182b893aa4a0 -0590b78ee42b39087983e4de04164065e5aa11bc refs/cobs/xyz.radicle.patch/ffbb812ad6e7fe1c5c610b1246ca5ca9d7d16027-
refs blob under a user’s refs/rad/sigrefs branch.
-
- Still don’t know what I was waiting for
Requiring an -internet connection to push to remote
But now I push to my local-first, oh so -`rad` remote
Instead of that one shoddy monopolized forge
-
-As we just mentioned, `rad init` creates a special remote in your working copy named `rad`. What’s this doing under the hood? With Radicle, you will typically be interacting with two different repository copies on your device, the _working copy_ and a hidden, _stored copy_ that you interact with via `git push rad` and `git pull rad` commands using Radicle’s _git remote helper_ program named `git-remote-rad`. Remote helpers are particularly useful for integrating Git with specialized network protocols like Radicle. Git calls the custom `git-remote-rad` program when it encounters `rad://` remotes.
-
-> 🧠
->
-> Git remote helpers are custom programs that allow Git to interact with repositories hosted on various types of servers or protocols that are not natively supported. Remote helpers are invoked by Git when it encounters a URL scheme that matches a supported helper. For example, in Radicle’s use case, if Git sees a URL starting with `rad://`, it will look for a remote helper program named `git-remote-rad` and use this program to handle operations related to that URL, such as fetching, pushing, and cloning. For more details, check out Git’s [documentation](https://git-scm.com/docs/gitremote-helpers) on remote helpers.
-
-To view information about the `rad` remote in your repository, try:
-
-```
-$ git remote show rad
-* remote rad
- Fetch URL: rad://z31hE1wco9132nedN3mm5qJjyotna
- Push URL: rad://z31hE1wco9132nedN3mm5qJjyotna/z6MkvZwzK64f3GuDcAs6dEcje89ddfHkBjS1v9Dkh7aCGq3C
- HEAD branch: (unknown)
- Remote branch:
- main tracked
- Local branch configured for 'git pull':
- main merges with remote main
- Local ref configured for 'git push':
- main pushes to main (up to date)
-```
-
-You’ll notice the Repository ID in a URL format under `Fetch URL`:
-
-```
-rad://z31hE1wco9132nedN3mm5qJjyotna
-```
-
-For the `Push URL`, you may be wondering, what is the element after the slash?
-
-```
-z6MkvZwzK64f3GuDcAs6dEcje89ddfHkBjS1v9Dkh7aCGq3C
-```
-
-Does it look familiar to you? Well, it’s your Node ID. Remember you can always check your Node ID by running `rad node status --only nid`.
-
-When using Git with traditional forges, you are pushing to a remote which is a centralized server that all other collaborators are also using. In Radicle, the remote is on your local device, which means that you can push changes even when you’re disconnected from the internet. Changes that you push to the remote while offline will automatically propagate to the network once you come back online. This is one of the very unique aspects of Radicle that makes offline work _way smoother_.
-
-
-
-> 🧠
->
-> Radicle’s storage layout accommodates multiple source trees _(namespaces)_ per repository. Each repository is stored as a bare Git repository, residing under a common base directory, uniquely identified by its Repository ID (RID). Rather than storing peer data in separate Git repositories with individual object databases (ODBs), Radicle consolidates peer data within the same Git repository. This is achieved using the `gitnamespaces` feature, where each peer’s unique Node ID serves as a namespace to partition their Git references.
->
-> See the [storage](/guides/protocol#local-first-storage) section of the protocol guide for more information.
-
-Now let’s try publishing some changes to see how this works.
-
-Use your favorite text editor to make a change to the repository that you just initialized. For example, you can update its README to include instructions on how to clone the repository on Radicle:
-
-```
-$ git diff
-diff --git a/README.md b/README.md
-index 91b304791..70ef6efc9 100644
---- a/README.md
-+++ b/README.md
-@@ -58,6 +58,12 @@
-
-+## Radicle
-+
-+To clone this repository on Radicle, simply run:
-+
-+ rad clone rad:z31hE1wco9132nedN3mm5qJjyotna
-+
-```
-
-Once you’re finished, add and commit your changes with `git add` and `git commit` just as you would when collaborating on any other Git repository. Then use `git push rad master` to synchronize the changes with your node (be sure to replace `master` with your default branch, in case that’s not it).
-
-```
-$ git add README.md
-$ git commit -m "Add instruction on cloning with Radicle"
-$ git push rad master
-✓ Synced with 1 node(s)
-To rad://z31hE1wco9132nedN3mm5qJjyotna/z6MkvZwzK64f3GuDcAs6dEcje89ddfHkBjS1v9Dkh7aCGq3C
- ecb1bf0..74fb8d2 master -> master
-```
-
-Whenever you execute a `git push rad` command, you are pushing the changes in your local working copy to your `rad` remote, the stored copy managed by your radicle node, so it’s a local operation. You see that the remote of your repository is represented by the URL:
-
-```
-rad://z31hE1wco9132nedN3mm5qJjyotna/z6MkvZwzK64f3GuDcAs6dEcje89ddfHkBjS1v9Dkh7aCGq3C
-```
-
-As the sole delegate of the repository, changes that you push to the repository’s default branch under the `rad` remote, represent the **canonical** or _authoritative_ state of the repository. This means that if someone were to clone your repository, they would be getting the state that you just pushed, given your nodes are able to communicate with each other.
-
-> 🧠
->
-> The canonical repository state is established _dynamically_ based on the delegate thresholds defined for the repository. For example, if a `threshold` of two out of three delegates is set, with the `defaultBranch` specified as `main`, and both Alice and Bob have the same commit in their `main` branches, that specific commit is recognized as the authoritative, current state of the repository. In the current Radicle release, the dynamic establishment of an authoritative state is limited to a single `defaultBranch`. Future releases of the protocol may enhance this feature to include additional secondary branches.
-
-You may be wondering -- now that you’ve pushed to your remote, how do other peers get this update? Any peer who has cloned or seeded the repository will receive a _reference announcement_ message from its peers, via the gossip protocol, which informs the node there was an update. Following this, peers conduct a _fetch_ operation via the Git protocol to pull the pertinent Git objects into their local storage.
-
-### The basics of _seeding_ and _cloning_
-
-Nodes have a _seeding policy_ which specifies the list of repositories they are interested in replicating on the network.
-
-Whenever you clone or initialize a new repository, your node’s seeding policy is updated to keep these repositories in sync with the network.
-
-There are a few ways that seeding relationships are established among nodes. One of the main methods is by one node intentionally _cloning_ another repository. You can run the `rad clone` command to clone a repository from the Radicle network, by supplying a Repository Identifier (RID).
-
-Let’s try this out. First, navigate to a directory where you typically clone Git repositories. Then run this command to clone the Radicle [Heartwood][heartwood] repository:
-
-
-
-```
-$ rad clone rad:z3gqcJUoA1n9HaHKufZs5FCSGazv5
-✓ Seeding policy updated for rad:z3gqcJUoA1n9HaHKufZs5FCSGazv5 with scope 'all'
-✓ Fetching rad:z3gqcJUoA1n9HaHKufZs5FCSGazv5 from z6Mkk4R…SBiyXVM..
-✓ Fetching rad:z3gqcJUoA1n9HaHKufZs5FCSGazv5 from z6Mksmp…1DN6QSz..
-✓ Fetching rad:z3gqcJUoA1n9HaHKufZs5FCSGazv5 from z6MkrLM…ocNYPm7..
-✓ Creating checkout in ./heartwood..
-✓ Remote cloudhead@z6MksFqXN3Yhqk8pTJdUGLwATkRfQvwZXPqR2qMEhbS9wzpT added
-✓ Remote-tracking branch cloudhead@z6MksFqXN3Yhqk8pTJdUGLwATkRfQvwZXPqR2qMEhbS9wzpT/master created for z6MksFq…bS9wzpT
-✓ Repository successfully cloned under /home/paxel/src/heartwood/
-╭────────────────────────────────────╮
-│ heartwood │
-│ Radicle Heartwood Protocol & Stack │
-│ 8 issues · 14 patches │
-╰────────────────────────────────────╯
-Run `cd ./heartwood` to go to the project directory.
-```
-
-Cloning has some similarities to Git’s `clone` command, in that it creates a working copy of a remote repository, but this is executed in a much different way since Radicle is a peer-to-peer protocol.
-
-The `rad clone` command is essentially equivalent to running these lower-level commands:
-
-| **`rad seed`** | Updates your seeding policy to start seeding this repository | **`rad sync -f`** | Fetches the latest repository data from other seeds and stores it in your local storage | **`rad checkout`** | Creates a working copy of the repository from local storage | **`rad remote add`** | Creates a Git remote in your working copy for all repository delegates
-
-When you only want to _seed_ a repository and have no interest in contributing code, you can still be a repository’s friend with the `rad seed` command. This is Radicle’s version of a ⭐ _star_ or 👍 _like_, where you show a repository some real love and care by sharing it with others on the network.
-
-
-
-This works similarly to cloning, where the RID is provided, the main difference is that it doesn’t create a working copy.
-
-```
-$ rad seed rad:z3gqcJUoA1n9HaHKufZs5FCSGazv5
-✓ Seeding policy updated for rad:z3gqcJUoA1n9HaHKufZs5FCSGazv5 with scope 'all'
-✓ Fetching rad:z3gqcJUoA1n9HaHKufZs5FCSGazv5 from z6Mkk4R…SBiyXVM..
-```
-
-When you seed a repository, it updates your seeding policy to subscribe to updates. It fetches a copy of the repository under your local storage, and provides a replica to the network.
-
-In the future, if you change your mind and decide that you want to contribute code to a repository you’re seeding, you can always run `rad checkout` to create a working copy of the repository from local storage and `rad remote add` to create remotes of peers that you can pull from and push to.
-
-If on the other hand you want to stop seeding a repository, simply run `rad unseed`. For example:
-
-```
-$ rad unseed rad:z9DV738hJpCa6aQXqvQC4SjaZvsi
-```
-
-You can list all of your seeded repositories with the `ls` sub-command:
-
-```
-$ rad ls --seeded
-```
-
-If on the other hand you only want to see repositories you’ve contributed to in some way, for example by pushing a branch or commenting on an issue, simply run `ls` with no arguments:
-
-```
-$ rad ls
-```
-
-> 👾
->
-> The set of peers that are followed in the context of a seeded repository is called the _scope_.
->
-> By default, when cloning or seeding a repository, your node will subscribe to content from _all_ peers. This behavior is part of the seeding policy and can be changed by passing `--scope followed` to the `seed` and `clone` commands, to only subscribe to content from the repository _delegates_ plus any node that is explicitly followed via `rad follow`.
->
-> If a repository wasn’t initially cloned or seeded in this way, it can also be changed later via the `rad seed` command, e.g.
->
-> ```
-> rad seed rad:z3gqcJUoA1n9HaHKufZs5FCSGazv5 --scope followed
-> ```
->
-> Conversely, to reset it to the default, `--scope all` can be passed.
-
-This marks the end of our initial foray into Radicle. As we move forward to Chapter 2, we’ll dissect the collaborative mechanisms at play, exploring issues and patches from the unique perspectives of both contributors and delegates. It’s here that the true kernel of _code collaboration_ begins to unfold.
-
-## 2. Collaborating the Radicle Way
-
-Now is the time to delve into Radicle’s approach to working with social artifacts like issues and patches. In the context of version control systems, social artifacts refer to collaborative features that facilitate discussions, bug tracking, and code review. Patches, in particular, represent proposed changes to the codebase, often in response to issues or feature requests. Unlike traditional centralized forges, Radicle leverages Git’s distributed version control system to allow you to maintain local copies of your repository’s associated issues and patches, alongside the repository source tree.
-
-
-
-If you’re familiar with Git, you know that when you `commit` code changes, a unique hash called a commit hash is generated to identify that snapshot in history. In Radicle, issues, patches, and their associated comments work similarly to code commits. They are stored as Git objects within the repository itself, each with its own unique Git Object ID (OID). This means that all collaborative interactions, such as creating issues, submitting patches, and commenting, are self-contained within the Git repository.
-
-Furthermore, these objects are cryptographically signed by their author, providing an additional layer of security and trust. This allows all participants to independently verify the authenticity of the collaborative interactions, ensuring the integrity of the project’s history. By storing social artifacts within Git and leveraging cryptographic signatures, Radicle enables projects to operate independently of centralized platforms, giving users full control over their collaborative data, and the ability to work offline.
-
-
-
-In Radicle, these collaborative social interactions are implemented using a novel system of [Collaborative Objects][cobs] or simply “COBs” 🌽, that are implemented using Git primitives.
-
-### Working with _issues_
-
-Requiring an -internet connection to push to remote
But now I push to my local-first, oh so -`rad` remote
Instead of that one shoddy monopolized forge
The more we git together
-Together, together
-The more we git together
-The happier we’ll be
-
-
-
-Before we get into _issue management_, you should first get to know our trusted friend, the COB 🌽. Discussing issues and patches is not natively supported by Git, so we had to extend it. We named this data type a [Collaborative Object][cobs] or “COB” for short. They use Conflict-Free Replicated Data Types (CRDTs) under the hood for data consistency and are one of the fundamental building blocks of the Radicle protocol.
-
-
-
-Now, to see how COBs are leveraged through the process of collaboration, we’ll open an issue under our “paxel” user alias, in a repository where we are a contributor, but not a delegate.
-
-We’re going to `cd` into our copy of the `dark-star` repository we are collaborating on, and open an issue with `rad issue open`. This will open your text editor, prompting you to enter a title and description for the issue. Radicle follows the same convention as Git commits when it comes to inputing via an editor: the first line is a summary or _title_ of the issue, then comes the _description_, separated by a blank line.
-
-```
-$ cd dark-star
-$ rad issue open
-```
-
-We’ll enter the following title and description in our editor:
-
-```
-Establish data standards for IUI Dark Star Data group
-
-As we go out and recruit the Neboriens and other intelligences to join
-the Intergalactic Union of Intelligences (IUI), we are going to have to
-establish standards for Dark Star data submissions.
-```
-
-When we save and close the editor, the issue is displayed on the command line:
-
-```
-╭───────────────────────────────────────────────────────────────╮
-│ Title Establish data standards for IUI Dark Star Data group │
-│ Issue e4255cc2a0a65b543c2b5badac14bf9e0d9f409f │
-│ Author paxel (you) │
-│ Status open │
-│ │
-│ As we go out and recruit the Neboriens and other │
-│ intelligences to join the Intergalactic Union of │
-│ Intelligences (IUI), we are going to have to establish │
-│ standards for Dark Star data submissions. │
-╰───────────────────────────────────────────────────────────────╯
-```
-
-Behind the scenes, `rad issue open` conjures up a brand-new COB for the issue, bestowing upon it a unique identifier. This COB becomes the guardian of all the metadata and interactions associated with the issue, ready to be replicated and synced across the Radicle network.
-
-> 👾
->
-> To ensure that your preferred editor is chosen when you enter `rad issue open`, make sure the `EDITOR` environment variable is set appropriately. It must be set to the full path to your preferred editor, for example:
->
-> ```
-> export EDITOR=/usr/bin/vim
-> ```
->
-> If you’d prefer to enter the issue title and description via the command-line without spawning your editor, you can use the `--title` and `--description` options to `rad issue open`.
-
-COBs such as issues and patches can be created even when offline, since Radicle is local-first. COBs you create offline will simply synchronize with the network once you go online.
-
-You can always see a table with all of the issues associated to a repository by running `rad issue` within its working directory.
-
--Together, together
-The more we git together
-The happier we’ll be
$ rad issue
-╭──────────────────────────────────────────────────────────────────────────────────────────────────╮
-│ ● ID Title Author │
-├──────────────────────────────────────────────────────────────────────────────────────────────────┤
-│ ● 80464b3 Categorize initial dataset paxel (you) │
-│ ● e4255cc Establish data standards for IUI Dark Star Data group paxel (you) │
-│ ● 3e2f653 Add anomalous data from ship 897AF calyx z6Mkgom…unurCap │
-│ ● badda04 Recruit Neboriens to join IUI and share dark star data calyx z6Mkgom…unurCap │
-╰──────────────────────────────────────────────────────────────────────────────────────────────────╯
-$ rad inbox
-╭────────────────────────────────────────────────────────────────────────────────────────────╮
-│ dark-star │
-├────────────────────────────────────────────────────────────────────────────────────────────┤
-│ 004 ● 3e2f653 Add anomalous data from ship 897AF issue open calyx 1 hour ago │
-╰────────────────────────────────────────────────────────────────────────────────────────────╯
--✓ Patch e5f0a5a5adaa33c3b931235967e4930ece9bb617 opened -✓ Synced with 8 node(s) - -To rad://z3cyotNHuasWowQ2h4yF9c3tFFdvc/z6MkvZwzK64f3GuDcAs6dEcje89ddfHkBjS1v9Dkh7aCGq3C -* [new reference] HEAD -> refs/patches -- -In the above Git output, we see our patch’s identifier displayed: - -``` -e5f0a5a5adaa33c3b931235967e4930ece9bb617 -``` - -Patches are a type of COB 🌽, just like issues, and this is the SHA-1 hash that uniquely identifies this patch. - -> 👾 -> -> If you want to avoid remembering the `git push rad HEAD:refs/patches` command, you can add an alias to your local (or global) Git configuration: -> -> ``` -> $ git config alias.patch 'push rad HEAD:refs/patches' -> ``` -> -> This allows you to create a patch by simply running `git patch`. Use the `--global` option with `git config` to add the alias to your global Git config. - -> 🧠 -> -> Radicle’s patch workflow is implemented using the `git-remote-rad` helper program developed for Radicle. This program is called by Git when it detects a push to any `rad://` URL, such as the one under our `rad` remote. - -In addition to opening a patch, the above `push` command creates a new remote tracking branch and makes it the upstream of our `anomalous-data-897af` branch. Any subsequent push from this original branch will now update the patch, synchronizing our local changes with the network. - -> 🧠 -> -> The name of the remote patch branch is always `rad/patches/` followed by the patch identifier. For example: -> -> ``` -> rad/patches/e5f0a5a5adaa33c3b931235967e4930ece9bb617 -> ``` - -We can take a look at remote tracking branches using `git branch --remotes` to understand this better. - -``` -$ git branch --remotes - calyx@z6Mkgom1bTxdh9fMFxFNXFMw3SbXnma6NARdsfcFuunurCap/main - rad/main - rad/patches/e5f0a5a5adaa33c3b931235967e4930ece9bb617 -``` - -Here we see three branches: the `main` branch of Calyx (`calyx@z6Mk..`), our own main branch (`rad/main`), and the branch associated with our recent patch (`rad/patches/e5f0a..`). - -We can also check the commit hashes associated with the `rad` remote references: - -``` -$ git ls-remote rad -e81db74197f48cc5198d9c03cceaec955af82abf refs/heads/main -80b8d420658834afc444a13c03f0c3ff6875a71c refs/heads/patches/e5f0a5a5adaa33c3b931235967e4930ece9bb617 -``` - -Since the `rad` remote is associated with our published copy of the repository, these are the branch heads that are publicly accessible on the network. - -### Updating patches - -So let’s say we’d like to update the patch we just submitted. We found some formatting issues with the log file we included and we’d like to correct it and update the patch. - -First, let’s dive into our editor and fix the formatting: - -``` -$ vi data/897af.log -``` - -Then, we commit the changes and push. - -``` -$ git commit --amend -$ git push --force -``` - -To update the patch, we simply use `git push`. Since we amended the original commit, we have to use the `--force` option when pushing. This is common practice when a patch has been reworked. - -As with opening a patch, this opens an editor to enter a reason for updating the patch. Leave it blank if you’d like to skip that. - -
✓ Patch e5f0a5a updated to revision 4d0c1156f8ac7af2297d1314cd7556185cd16ae4
-✓ Synced with 6 node(s)
-
-To rad://z3cyotNHuasWowQ2h4yF9c3tFFdvc/z6MkvZwzK64f3GuDcAs6dEcje89ddfHkBjS1v9Dkh7aCGq3C
- + b766431...80b8d42 anomalous-data-897af -> patches/e5f0a5a5adaa33c3b931235967e4930ece9bb617 (forced update)
-$ rad patch show e5f0a5a
-╭────────────────────────────────────────────────────────────────────────────────╮
-│ Title Add anomalous data from ship 897AF │
-│ Patch e5f0a5a5adaa33c3b931235967e4930ece9bb617 │
-│ Author paxel (you) │
-│ Head 80b8d420658834afc444a13c03f0c3ff6875a71c │
-│ Branches anomalous-data-897af │
-│ Commits ahead 1, behind 0 │
-│ Status open │
-│ │
-│ Data from ship 897AF. │
-├────────────────────────────────────────────────────────────────────────────────┤
-│ 80b8d42 Add anomalous data from ship 897AF │
-├────────────────────────────────────────────────────────────────────────────────┤
-│ ● opened by paxel (you) (b766431) 58 minutes ago │
-│ ↑ updated to 4d0c1156f8ac7af2297d1314cd7556185cd16ae4 (80b8d42) 44 minutes ago │
-╰────────────────────────────────────────────────────────────────────────────────╯
-$ rad patch
-╭───────────────────────────────────────────────────────────────────────────────────────────────────╮
-│ ● ID Title Author Head + - Updated │
-├───────────────────────────────────────────────────────────────────────────────────────────────────┤
-│ ● e5f0a5a Add anomalous data from ship 897AF z6MkvZw…7aCGq3C 80b8d42 +50382 -0 1 hour ago │
-╰───────────────────────────────────────────────────────────────────────────────────────────────────╯
-$ git remote -v
-paxel rad://z3cyotNHuasWowQ2h4yF9c3tFFdvc/z6MkvZwzK64f3GuDcAs6dEcje89ddfHkBjS1v9Dkh7aCGq3C (fetch)
-paxel rad://z3cyotNHuasWowQ2h4yF9c3tFFdvc/z6MkvZwzK64f3GuDcAs6dEcje89ddfHkBjS1v9Dkh7aCGq3C (push)
-rad rad://z3cyotNHuasWowQ2h4yF9c3tFFdvc (fetch)
-rad rad://z3cyotNHuasWowQ2h4yF9c3tFFdvc/z6Mkgom1bTxdh9fMFxFNXFMw3SbXnma6NARdsfcFuunurCap (push)
--╭────────────────────────────────────────────────────────────────────────╮ -│ Name RID Visibility │ -├────────────────────────────────────────────────────────────────────────┤ -│ schrödingers-paradox rad:z3jEQE4VMzkR1UVeSLiN9E8AMtV6a private │ -╰────────────────────────────────────────────────────────────────────────╯ -- -### Curating the _allow_ list - -Now that we have our private repository, the next step is to grant access to our collaborators. - -The newly created private repository, `schrödingers-paradox`, will initially be accessible only by us, the lone delegate. This is due to the fact that repository delegates always have access to their private repositories. However, to collaborate on this repository with others, we need to curate its allow list to include the DIDs of Calyx, and at least one [seed node][seeder] _we trust_. This seed node will act as a trusted relay, necessary for the synchronization of repository state between Calyx and us. - -Though this trusted seed node needs a public DNS address, it doesn’t have to be advertised to the network. One can simply omit adding the address to the `externalAddresses` key in the Radicle node configuration. - -> 👻 -> -> Private repositories are not encrypted at rest, so any node that you add to the allow list will have visibility over the contents of your private repository. In the [Chapter 4][ch4] we explore a different setup that works over Tor and doesn’t require a trusted seed node. - -We can add both Calyx and our trusted seed node to the allow list using a single `rad id update` command. This command requires a `--title` for the update, along with each authorized DID specified with the `--allow` flag: - -``` -$ rad id update --title "Allow Calyx and seed.darkstar.example" \ - --allow did:key:z6Mkgom1bTxdh9fMFxFNXFMw3SbXnma6NARdsfcFuunurCap \ - --allow did:key:z6MkqNZS9QWvC4wbZ8Vz4hQZ1FzN8q4XGj2KGmK9qNgQ8VWt -``` - -Once we submit the update above, it is automatically approved, as we are the repository’s sole delegate. If you look at the resulting diff, you see that both Calyx and our trusted node are being added to the `allow` list under the `visibility` key: - -```json -"allow": [ - "did:key:z6Mkgom1bTxdh9fMFxFNXFMw3SbXnma6NARdsfcFuunurCap", - "did:key:z6MkqNZS9QWvC4wbZ8Vz4hQZ1FzN8q4XGj2KGmK9qNgQ8VWt" -] -``` - -> 👾 -> -> It is also possible to update a repository that is currently public to become private, with a repository identity update: -> -> ``` -> $ rad id update --title "Make private" --visibility private -> ``` -> -> This won’t delete historic repository data from public seed nodes or other peers that previously seeded or cloned the repository, meaning users will still be able to clone the old version of the repository. -> -> Instead, future updates to the repository, including the repository’s private status will be hidden to unauthorized users, only to be announced and accessible to those explicitly defined in the `allow` list. - -### Replicating to our seed node - -Now that we’ve set up our private repository, it’s essential to configure it from our trusted seed node. Since our seed node is likely configured with a selective seeding policy, we’ll have to tell it to seed our private repository with the `rad seed` command. - -Since `schrödingers-paradox` is a private repository, we also need to specify our (Paxel’s) Node ID using the `--from` flag to explicitly indicate a source node to fetch from. We therefore run the following command from within an SSH session on our seed node: - - - -``` -$ rad seed rad:z3jEQE4VMzkR1UVeSLiN9E8AMtV6a --from z6MkvZwzK64f3GuDcAs6dEcje89ddfHkBjS1v9Dkh7aCGq3C -``` - -This will update darkstar’s seeding policy and attempt to fetch the repository from our node. For the fetching to be successful, we’ll have to be connected to the seed node. Check that it is indeed the case with `rad node status`, and use `rad node connect` or adjust your node’s configuration if it isn’t the case. - -> 👾 -> -> If you’re experiencing issues with repository replication, try these steps: -> -> 1. Check your current connections: -> ``` -> $ rad node status -> ``` -> 2. If your seed node isn’t listed, manually connect using: -> ``` -> $ rad node connect -> ``` -> For example: -> ``` -> $ rad node connect z6MkqNZS9QWvC4wbZ8Vz4hQZ1FzN8q4XGj2KGmK9qNgQ8VWt@seed.darkstar.example:8776 -> ``` -> -> To find your seed node’s address, run `rad node config --addresses` while logged in to the seed node. -> -> For comprehensive information on setting up and managing seed nodes, refer to our [Seeder’s Guide][seeder]. - -Once the repository is on the seed, you should be able to see it by running `rad ls --private` from within the SSH session. It can then serve as an always online reliable access point for other authorized peers. Remember, only peers on the repository’s allow list will be able to fetch from this seed node. - -### Cloning as a trusted peer - -With our repository now successfully seeded, Calyx can clone our project. Since `schrödingers-paradox` is a private repository, Calyx needs to specify the seed node to fetch from, using the `--seed` flag. In this case, Calyx specifies the Node ID of `seed.darkstar.example`: - - - -``` -$ rad clone rad:z3jEQE4VMzkR1UVeSLiN9E8AMtV6a --seed z6MkqNZS9QWvC4wbZ8Vz4hQZ1FzN8q4XGj2KGmK9qNgQ8VWt -``` - -Once the repository is fetched, it’s no longer necessary to specify the seed. Commands such as `rad sync` will automatically try to sync with our trusted seed. - -_With a local copy of the repository, Calyx can now collaborate freely, in full secrecy._ - -### Removing nodes from the _allow_ list - -In the event that our seed node became compromised, we could revoke access privileges to the repository from it. The same `rad id update` command is used, but this time with the `--disallow` flag: - -``` -$ rad id update --title "Darkstar is compromised!" \ - --disallow did:key:z6MkqNZS9QWvC4wbZ8Vz4hQZ1FzN8q4XGj2KGmK9qNgQ8VWt -``` - -Our _no-longer-trusted_ seed node will now be unable to fetch updates from us for `schrödingers-paradox`. - -> 👾 -> -> As time goes by, you might decide that a repository no longer needs to be private. In such a case, you can easily change its visibility. Simply run `rad publish` within a repository’s working copy to transform it from private to public. - -> 👻 -> -> Radicle’s codebase hasn’t yet undergone formal security audits. While we’re confident in its security, undiscovered vulnerabilities may exist. If you encounter any issues, we encourage you to report them to **security@radicle.xyz**. - -## 4. Embracing the Onion - -**[Tor][tor]**, “The Onion Router”, is a decentralized network that anonymizes users’ online activity by routing internet traffic through multiple encrypted relays, providing stronger anonymity compared to traditional VPNs. - - - -To further enhance repository and user privacy, Radicle nodes can be configured to run behind Tor. This allows connections to be made to `.onion` addresses, as well as hiding one’s IP address and exposing Radicle as a Tor _onion service_. - -Depending on how you configure Radicle, it offers several key advantages: - -- **Enhanced anonymity**: Your node’s real IP address is hidden, making it difficult for others to track your online activities or determine your location. -- **NAT traversal**: Tor automatically handles [NAT traversal][nat], eliminating the need for manual port forwarding or UPnP configuration. This means peers can directly connect with one another without a seed node, even behind a restrictive firewall. -- **Censorship resistance**: Repositories accessible via Tor are more resilient against censorship attempts, as the Tor network is designed to circumvent blocking. - -[nat]: https://en.wikipedia.org/wiki/NAT_traversal - -Network Address Translation (NAT) typically creates barriers for direct peer-to-peer communication. Devices behind NAT gateways are often isolated with non-routable private IP addresses, making them inaccessible from the public internet. This is common in most consumer internet setups. - -Tor addresses this issue by providing static `.onion` addresses – cryptographic identifiers representing nodes that are routable across the Tor network. This allows peers behind NAT to connect directly without needing to know each other’s public IP addresses, overcoming limitations faced by traditional peer-to-peer networks. - -This chapter will explore a few distinct ways to configure Radicle with Tor: - -1. **Mixed Mode**: Only connections to `.onion` addresses go through Tor, while other connections work normally. -2. **Full Proxy Mode**: All traffic is routed through Tor for maximum anonymity, - -``` -including traffic to nodes that are *not* behind Tor. -``` - -3. **Transparent Proxy Mode**: Leverages an existing fully transparent Tor proxy on the network. - -Before proceeding, ensure you have Tor installed on your system. Use your preferred package manager to install it (the package name is typically “tor”). For detailed instructions, refer to the Tor [installation guide][install-tor]. - -### Setting up a Tor Onion Service for Radicle - -We’ve been collaborating with Calyx on the private `schrödingers-paradox` repository. Recently, we removed a compromised seed node from the repository’s `allow` list, which inadvertently cut off Calyx’s access to the repository. - -To restore Calyx’s access and enhance the security of our sensitive research, we’ll configure our node as a Tor Onion Service (also known as a hidden service). This setup will make our node accessible via a `.onion` address, allowing Calyx to connect directly to us without relying on any intermediaries. - -Let’s set up our Tor Onion Service. The following steps are for Linux-based systems, but they should be similar for other operating systems. - -First we create a new `radicle` directory for our Onion Service, ensuring it’s readable and writable: - -``` -$ sudo mkdir -m 700 /var/lib/tor/radicle -``` - -This directory will store information and cryptographic keys for our Onion Service. - -Then we update our Tor configuration (`/etc/tor/torrc`) by adding the following lines to it: - -``` -HiddenServiceDir /var/lib/tor/radicle -HiddenServicePort 8776 -``` - -These lines set the `HiddenServiceDir` to the path of the directory we just created and specify the `HiddenServicePort` as `8776`, which is the default Radicle node port. - -Finally, we restart our Tor daemon to apply the configuration changes: - -``` -$ sudo systemctl restart tor -``` - -Our `.onion` address is stored in a file under our Onion Service directory. Let’s take a look: - -``` -$ sudo cat /var/lib/tor/radicle/hostname -1odmmeotgcfx65l5hn6ejkaruvai222vs7o7tmtllszqk5xbysolfdd.onion -``` - -We can copy this address to our clipboard, as we’ll need it to configure our Radicle node in the next steps. - -> 🧠 -> -> If you are a **macOS** user, install Tor via `brew install tor` and restart it via `brew services restart tor`. -> -> Use `mkdir -p -m 700 ~/.tor/radicle` to create your onion service directory. -> -> The Tor configuration file is located at `/opt/homebrew/etc/tor/torrc` and your `.onion` address can be found in `~/.tor/radicle/hostname`. -> -> Make sure to set the torrc HiddenServiceDir to `/Users/