Radicle

Esli SilvaEsli Silva
7 min read

Plataformas centralizadas (GitHub, GitLab, etc.) concentram controle, metadados e políticas.

No artigo abaixo falei sobre alguns serviços SaaS ou self-hosted para Git, porém, além de só conhecerem o GitHub, muitos devs entendem atualmente o git como um sistema client/server. Poucos dias atrás falei que dá para ter um único repositório apontando para vários “git servers” incluindo push para github e gitlab (e outros) no mesmo projeto e acharam que eu estava maluco.

Fato é: muitos usam o básico e não entenderam realmente qual o propósito do Git: de ser um sistema de versionamento distribuído.

Agora, fora do mundo corporativo, num ambiente OSS/FOSS, os desenvolvedores rodam algo self-hosted como o Gitea (o mais usado!) inclusive alguns expondo somente pela rede Tor (onion), ou ficam sujeitos as políticas e regras dos sistemas SaaS como GitLab, GitHub, Codeberg, SourceForge e outros.

O Radicle propõe uma alternativa que preserva o fluxo do Git (commits, branches, objetos) enquanto adiciona uma camada P2P para publicação, issues, patches e revisão de código — sem servidor controlando. O objetivo não é substituir Git; é estender Git com um protocolo P2P e assinaturas por chaves do usuário onde a disponibilização pública é feita por seed nodes e peers, colocando-o em um ambiente totalmente descentralizado, onde você controla a infraestrutura, a identidade e o fluxo de contribuição.

Se você tem curiosidade suficiente para rodar um script de instalação, assinar seu primeiro patch e brincar com delegação, já está à frente da maioria dos profissionais que ainda dependem exclusivamente de serviços hospedados. E, como todo bom experimento, o aprendizado que vem junto – sobre criptografia, redes p2p e governança – paga dividendos em qualquer área de tecnologia.

O Radicle não é apenas “Git + P2P”. Ele propõe um novo contrato social entre desenvolvedores: controle total, responsabilidade distribuída e resistência a censura. Para quem já sente o peso das políticas de uso de plataformas centralizadas, ele oferece um caminho viável – ainda que em fase de amadurecimento.

Arquitetura básica

CamadaFunçãoTecnologias chave
Identidade soberanaCada usuário tem um DID (did:key:) que garante autenticidade sem depender de provedores externos.libp2p, DID‑key
Rede p2pTroca de objetos Git (blobs, trees, commits) diretamente entre nós.libp2p‑gossipsub, Kademlia DHT
ArmazenamentoOs objetos são armazenados localmente e replicados por peers que “seguem” o projeto. Não há um único ponto de falha.IPFS‑like blockstore (opcional)
Camada de consensoNão há blockchain pesada; o consenso nasce da assinatura de cada objeto e da política de “delegação” (ex.: quem pode mesclar).Ed25519 signatures, “patches” (pull‑requests)
Interface de usuárioClientes CLI (rad), UI web (Radicle Desktop) e integrações com editores.Electron, Rust‑CLI

Essas camadas permitem que você trabalhe exatamente como faria no Git, porém sem precisar empurrar nada para um servidor central. Quando alguém clona seu repositório, o próprio cliente cria uma conexão p2p e começa a baixar blocos diretamente dos peers que já têm o conteúdo.

Camada DVCS (Git): reutiliza completamente o modelo de objetos do Git para conteúdo e histórico. Os repositórios locais continuam sendo git repos normais.

Radicle Link (protocolo): um protocolo P2P genérico que replica metadados de colaboração (issues, patches, identities) sobre uma rede de peers; desenhado para suportar backends DVCS variados (a implementação primária foca em Git).

Objetos de Colaboração (COBs): Identidades, Issues, Patches e outros são modelados como documentos assinados (tipos xyz.radicle.id, xyz.radicle.issue, xyz.radicle.patch) que descrevem o estado colaborativo. Esses COBs são replicados pelo protocolo e ligados ao conteúdo Git.

Seed nodes / disponibilização: nós publicos conhecidos (seeders) armazenam e servem dados para melhorar disponibilidade e descoberta. Usuários podem rodar seus próprios seeders para controle total.

Interface e tooling: existe CLI (rad), helpers (git-remote-rad), daemon de nó (radicle-node) e camada web (radicle-httpd / app.radicle.xyz / rad web). A UI pode ser usada localmente, auto-hospedada ou via a instância pública.

Segurança e privacidade (por que o Radicle pode ser mais seguro)

  1. Assinaturas criptográficas – Cada commit, patch e meta‑objeto carrega uma assinatura Ed25519. Alterar histórico sem a chave privada correspondente é impossível.

  2. Zero‑knowledge de identidade – Seu DID não revela e‑mail, login ou número de telefone; ele só prova que você controla a chave.

  3. Resistência a censura – Como o código vive em múltiplos peers, derrubar o projeto exigiria bloquear todos os nós que o replicam – algo impraticável. E ele pode funcionar via rede Tor.

  4. Criptografia de tráfego – Todas as comunicações p2p são TLS‑encapsuladas via libp2p, evitando sniffers de rede.

Nunca compartilhe sua seed phrase ou a chave privada do DID em canais públicos. Trate-a como a senha do seu cofre.

Instalação e componentes principais

Componentes principais:

  • rad (CLI): operações de identidade, publicação, patches e interação com o nó.

  • radicle-node: daemon que participa da rede P2P.

  • git-remote-rad: permite usar remotes rad como remotes git convencionais.

# Install
curl -sSf https://radicle.xyz/install | sh

# recarregue o bash / para ter o path dos binários
source ~/.bashrc

# crie um alias e passphrase. Vai criar uma keypair em Ed25519 e gerar seu DID.
rad auth

# inicializar o daemon
rad node start

Crie um repo em git normalmente com ao menos 1 commit:

git init my-first-radicle
cd my-first-radicle
echo "My radicle repo" > README.md
git add .
git commit -m "initial commit"

cd ..

Agora, inicie o Radicle para este repo:

rad init my-first-radicle

Ele solicita para confirmar o nome do repo, adicionar uma descrição e escolher se é público ou privado.

Sendo privado, solicitará uma passphrase para o repo.

Finalizando, gerará o ID (RID) do repositório.

Depois disso, basta compartilhar o rad‑id (algo como rad:asdqwe123zxcasd123) com quem quiser colaborar.

Quem receber o ID pode fazer:

rad clone rad:asdqwe123zxcasd123

E voilà: o repositório aparece localmente.

rad Desktop

rad CLI

rad ls

rad self - para mostrar seus dados/IDs e paths (não precisa ser em um repo especifico)

git remote show rad - em um repo especifico: exibe os dados do “servidor”, de como o git está configurado e principalmente, o RAD do repositório.

rad --help
rad 1.3.0 (0e48723b419be95340a5d9858d76963e8e97137b)
Radicle command line interface

Usage: rad <command> [--help]
Common `rad` commands used in various situations:

        auth         Manage identities and profiles
        block        Block repositories or nodes from being seeded or followed
        checkout     Checkout a repository into the local directory
        clone        Clone a Radicle repository
        config       Manage your local Radicle configuration
        fork         Create a fork of a repository
        help         CLI help
        id           Manage repository identities
        init         Initialize a Radicle repository
        inbox        Manage your Radicle notifications
        inspect      Inspect a Radicle repository
        issue        Manage issues
        ls           List repositories
        node         Control and query the Radicle Node
        patch        Manage patches
        path         Display the Radicle home path
        clean        Remove all remotes from a repository
        self         Show information about your identity and device
        seed         Manage repository seeding policies
        follow       Manage node follow policies
        unblock      Unblock repositories or nodes to allow them to be seeded or followed
        unfollow     Unfollow a peer
        unseed       Remove repository seeding policies
        remote       Manage a repositorys remotes
        stats        Displays aggregated repository and node metrics
        sync         Sync repositories to the network

See `rad <command> --help` to learn about a specific command.

Do you have feedback?
 - Chat <radicle.zulipchat.com>
 - Mail <feedback@radicle.xyz>
   (Messages are automatically posted to the public #feedback channel on Zulip.)

Equivalentes ao Radicle

Alguns projetos que podem ser considerados “primos” ou “equivalentes” ao Radicle:

  • Gitea + Forgejo + P2P layers → ainda centralizados, mas podem ser auto-hospedados.

  • IPFS + Git (git-remote-ipfs) → usar IPFS como backend para Git.

  • Pijul → não é Git, mas um VCS distribuído alternativo, com foco em descentralização.

  • SourceHut (sr.ht) → não é P2P, mas segue filosofia de simplicidade e descentralização (infra própria).

  • Scuttlebutt (SSB) → não é Git, mas compartilha a ideia de rede social P2P com identidade criptográfica, que inspirou parte do Radicle.

Porém, nenhum acima chega próximo do que o Radicle oferece out-of-box, talvez algo como o git-remote-g2g ou uma implementação do Git Over NOSTR como https://nostrgit.org/nostr-protocol/nostr (além de projetos como o git-nostr, gitstr…) e o https://gitworkshop.dev/

radicle.xyz

https://radicle.xyz/guides

https://radicle.xyz/guides/user#the-basics-of-seeding-and-cloning

https://radicle.xyz/guides/user#setting-up-a-tor-onion-service-for-radicle - Radicle over Tor

https://app.radicle.xyz/ - interface web do projeto com os repos e a visualização dos nodes (iris, rosa, seed)

0
Subscribe to my newsletter

Read articles from Esli Silva directly inside your inbox. Subscribe to the newsletter, and don't miss out.

Written by

Esli Silva
Esli Silva

Linux hard user since 2003, IT manager, DevOps, Sysadmin, SRE, teacher, Bass player, Krav Maga fighter and Marksman (Sport Shooter).