# How Radicle.xyz can balloon traction

The mainnet of the protocol was launched in September 2024 after 4 years of work. And while there obvious improvements that have been made over the initial versions, there are many "great filters" hindering adoption at scale.

To begin with, lets look at how it may help in a coder's main tasks for a day:

||Github|GitLab|Radicle|
|-|-|-|-|
|Repository Creation|Easy|Easy|Easy|
|Code Security (Default)|High|High|High|
|Idiot-proof support|Very High|-|-|
|Ease of finding public repositories|Very High|Medium|Bad|
|Serverless CI/CD tools|Very Good|Good|-|
|Light Clients|Y|Y|N|

But I think in the fullness of time these application layer bundles can be hotfixed with RIPs.

### Core issues with the protocol

#### 1. Self Certification
The first major issue that radicle.xyz has and the most damning one is that it is nearly impossible to move away popular repositories from Github into the nodes here except those like tornado cash which are explicity banned. There are a few problems:

a) I donot know if the person whose NID I am reading from is the person who also owns github.com/bitcoin off-chain. Maybe an identity provider module in the network is useful in the sense

b) Let us say we ignore user identity and use a pure commit hash based solver to handle resolutions, we can still be fooled by inpersonators and have backdoors in the future commits. Having to constantly investigate backdoors in your dependency supply chain is very expensive for now.

c) The final issue is basically tombstoning github repositories once radicle.xyz migration is completed. This can probably be done relatively simply. Think of it like Avatar, you transfer conditional repository ownership to the official radicle.xyz github account and it gets mapped on-chain to your NID.

#### 2. Dependency Indexing at Scale
The way the gossip protocol and nodes are structured, it will become very bandwidth expensive for tools like `go mod`, `npm`, `pip`, and `uv` to install dependencies. While this can still be handled, I am yet to investigate the literature on the tradeoffs between disk and network usage. Anyways, purely lazy references will be noticeably slow.

#### 3. Search
How do I discover repositories without risking nuking my entire disk while adding a new server. Radicle needs a Piratebay for its Bittorrent. Say I want to track everything in the vLLM ecosystem. How do I just pick up those relevant seed(s)/organization(s) only without having exact RIDs and exhaustively reading all RIDs?

#### 4. Light Clients
Suppose I want to deploy a radicle.xyz repository to production. I only need access to a specific NID/RID at a particular commit or branch—without running a full node or participating in the gossip protocol. While this may seem unconventional, consider a scenario where I'm operating a managed Jenkins service that supports Radicle-based CI/CD pipelines. Now imagine the network overhead from the gossip protocol on my node, if I had to manage even 500 customer repositories.

### Is it web3 enough?

Now let me get into issues which are not necessarily with the core protocol but may undermine the level of decentralization of the radicle protocol.

#### 1. Repository Ownership
While I understand this is a distributed git alternative as opposed to a decentralized one. A major issue which communities have when it comes to open source repositories is missing/unresponsive owners. This is a major drag especially on the community leading to hard forks that break downstream consumers.

Radicle.xyz is in a unique position to implement a dead man switch mechanism on a project's authors which allows for true decentralized ownership on a repository. A basic solana program can very easily handle the issue of:
- [x] Missing authors
- [x] Orphaned & depreciated repositories
- [x] Hard forks
- [x] Private forks

This would ideally convince many web3 projects to switch away from Github by facilitating true decentralized community ownership of public goods & infrastructure.

#### 2. The general problem with scaled up code de-duplication
Generally how distributed systems scale is by storing copies of the data across multiple nodes based on their demand. However, the gossip protocol does not allow any node to communicate over the network about the Git sessions active. So, nodes cannot strategically de-register their interest in a repository as no one has clear visibility on the global demand for that repository. So you will end up with unnecessary de-duplications.