Radicle


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
Camada | Função | Tecnologias chave |
Identidade soberana | Cada usuário tem um DID (did:key: ) que garante autenticidade sem depender de provedores externos. | libp2p, DID‑key |
Rede p2p | Troca de objetos Git (blobs, trees, commits) diretamente entre nós. | libp2p‑gossipsub, Kademlia DHT |
Armazenamento | Os 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 consenso | Nã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ário | Clientes 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)
Assinaturas criptográficas – Cada commit, patch e meta‑objeto carrega uma assinatura Ed25519. Alterar histórico sem a chave privada correspondente é impossível.
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.
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.
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/
Links
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)
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).