Radicle: forge de código autônoma

• Radicle é uma rede descentralizada de colaboração em código open source construída sobre o Git, permitindo replicar e gerenciar repositórios diretamente entre pares, sem servidor central
• Todos os dados e artefatos sociais são assinados com criptografia de chave pública, possibilitando verificação de autenticidade e autoria
• Os usuários podem operar seus próprios nós para manter um ambiente de colaboração resistente à censura e trabalhar de forma local-first mesmo sem conexão com a internet
• Por meio de Collaborative Objects (COBs), recursos de colaboração como issues, discussões e revisão de código são implementados como objetos Git, permitindo que desenvolvedores ampliem livremente essas funcionalidades
• É composto por uma estrutura modular com CLI, web e TUI, sendo uma plataforma de forge de código altamente extensível em que diferentes clientes podem ser desenvolvidos e substituídos

---

Visão geral (Synopsis)

• O Radicle é uma stack de colaboração em código peer-to-peer baseada em Git que, ao contrário das plataformas centralizadas de hospedagem de código, não possui uma única entidade de controle
  • Os repositórios são replicados de forma distribuída entre pares, e os usuários têm controle total sobre seus dados e fluxos de trabalho
• É fornecido como open source e pode ser usado livremente sob as licenças MIT e Apache 2.0
• O repositório principal possui o identificador rad:z3gqcJUoA1n9HaHKufZs5FCSGazv5

Instalação e primeiros passos

• A instalação pode ser feita no shell com o seguinte comando:
  curl -sSLf https://radicle.xyz/install | sh
• Ou pode ser compilado diretamente a partir do código-fonte
• Atualmente funciona apenas em Linux, macOS e sistemas BSD
• O cliente Radicle Desktop também oferece um ambiente gráfico de colaboração

Como funciona (How it works)

• Usa um sistema de identidade criptográfica para garantir a integridade do código e dos dados sociais, além da autenticação de autoria
• Usa o Git para realizar transferência eficiente de dados entre pares
• Troca metadados de repositórios por meio de um protocolo de gossip personalizado

Segurança e persistência de dados

• Todos os artefatos sociais são armazenados no Git e assinados com criptografia de chave pública
• O Radicle verifica automaticamente a autenticidade dos dados e a identidade do autor

Autonomia e resistência à censura

• Os usuários podem operar seus próprios nós para manter um ambiente de colaboração sem dependência de terceiros
• A rede foi projetada com uma estrutura resiliente e resistente à censura

Local-first

• Oferece funcionalidades sempre acessíveis mesmo sem conexão com a internet
• Os usuários mantêm a propriedade dos dados, com facilidade para mover, fazer backup e acessar

Escalabilidade e possibilidade de evolução

• Por meio de Collaborative Objects (COBs), recursos como issues, discussões e revisão de código são implementados como objetos Git
• Desenvolvedores podem expandir os COBs para criar novos fluxos de colaboração

Design modular (Modular by Design)

• A Radicle Stack é composta por CLI, interface web e TUI
  • Esses componentes são suportados por Radicle Node e HTTP Daemon
• Cada componente pode ser substituído, e outros clientes também podem ser desenvolvidos

Comunidade e participação

• O Radicle é um software livre e open source, e qualquer pessoa pode contribuir com código
• A comunidade atua em Zulip, Mastodon, Bluesky e Twitter
• Feedback pode ser enviado para [e-mail], sendo publicado automaticamente no canal #feedback do Zulip

[GN⁺]

Comentários do Hacker News

• A introdução do Radicle não deixa claro como ele difere de um Git self-hosted
  Se for uma alternativa como gitea ou forgejo, seria bom explicar brevemente quais recursos ele adiciona por cima do Git

  • Depois de ler a introdução, a impressão foi de algo como Git local-first para equipes
    Entendi como uma ferramenta para colaborar sem o caos de compartilhar patches por e-mail
    Como não conheço gitea nem forgejo, a comparação na verdade não ajuda
  • Acho que o resumo atual já é bom o suficiente
    Mencionar Git logo na primeira frase deixa isso claro
    Já a landing page do forgejo evita mencionar Git ou controle de código-fonte e, por isso, acaba sendo mais confusa
  • O Radicle é uma alternativa distribuída ao GitHub
    Ele oferece recursos de hospedagem local como forgejo/gitea/gitlab, mas funciona sobre uma rede P2P, sendo resiliente a falhas e permitindo hospedagem pública descentralizada de projetos
  • AD: somos um projeto open source, então sugestões e patches são bem-vindos
    Seria ótimo se você sugerisse diretamente uma forma melhor de escrever isso
  • Pela página, tive a impressão de um GitHub descentralizado em que equipes podem colaborar sem que a empresa tenha acesso ao código

• É bom ver uma tentativa de criar uma nova forge social
  Só o fato de esse tipo de projeto pressionar GitHub e GitLab a melhorar já tem valor
  Pelo FAQ, o Radicle tenta resolver o problema de confiança do Git com um sistema de identidade baseado em PKI
  Ainda assim, parece que no fim a questão de “em qual identidade confiar” continua existindo

  • AD: cada repositório é gerenciado por documentos de identidade assinados pelos delegates
    Hoje isso tem mapeamento 1:1 com chaves SSH, mas estamos expandindo para identidades de grupo
    Não é uma solução perfeita, mas com uma identidade criptográfica oferecemos uma estrutura que permite ‘escalar mais confiança a partir de alguma confiança’
    No fim, a confiança é distribuída por meio de conexões sociais, como nas relações entre pessoas
  • A confiança precisa ser construída por outros canais ou por revisão de código
    Depois que a confiança existe, dá para procurar outros repositórios com o mesmo DID
    Se houver várias versões, basta escolher uma fonte confiável ou um repositório mais ativo

• Ao conviver com pequenos grupos de sysadmins que mantêm serviços antigos da internet (IRC, Gopher etc.), acabei pensando na impossibilidade de apagar dados em sistemas P2P
  Fico me perguntando o que fazer quando alguém publica dados pessoais por engano, ou conteúdo que depois passa a ser problemático por mudança na lei
  Há também situações perigosas, como o caso de radioamadores presos em Belarus
  Isso não quer dizer que P2P seja ruim, mas a questão da exclusão continua difícil de resolver

  • A maioria das postagens antigas da Usenet ainda existe
    No GitHub também, quando código com chave secreta é enviado, muitas vezes já é tarde demais
    Em vez de criar um problema novo, o P2P apenas expõe um problema que já existia
  • Precisamos reconhecer a realidade de que conteúdo publicado é, na prática, permanente
    Seria bom ter um recurso de publicação com atraso, como no e-mail, que permitisse cancelar a publicação dentro de um certo prazo
  • AD: estamos cientes desse problema e estamos tornando as configurações padrão mais seguras
    Também estamos discutindo um recurso de descarte de conteúdo no nível da rede
  • Sistemas centralizados também não são perfeitamente seguros
    Operadores podem manipular a exclusão ou reportar o conteúdo ao governo
    No fim, questões legais dependem da justiça do sistema político
  • Mesmo em serviços centralizados, o conteúdo pode ser baixado, então exclusão completa é impossível

• Pergunta sobre a diferença em relação ao Tangled

  • O Radicle segue uma arquitetura local-first, em que o usuário opera seu próprio nó
    Todo o trabalho (issues, revisão de patches etc.) acontece em um armazenamento de dados local, sem ida e volta ao servidor
    A rede só entra em cena no momento da sincronização
    Já o Tangled tem uma estrutura federada baseada no AT Protocol e, na prática, depende de servidores centralizados (AppView)
    Estruturalmente, é cliente-servidor
  • O Tangled usa o AT Protocol para intermediar a comunicação entre vários servidores Git (“knots”)
    O Radicle não tem conceito de servidor, e todos os nós são equivalentes
    Alguns nós apenas operam como servidores HTTP para facilitar o acesso via navegador

• Pelo FAQ, o Radicle permite que cada nó bloqueie abuso e conteúdo ilegal com base em sua própria política
  Também oferece suporte a repositórios privados entre peers confiáveis
  Os dados não são criptografados, mas, por causa da replicação seletiva, não ficam expostos para a rede inteira
  Link do FAQ

• Parece necessário haver um gateway com índice de repositórios públicos na página inicial
  Assim seria possível explorar a rede inteira
  Se esse índice existir, há potencial para substituir o GitHub

  • É possível pesquisar repositórios públicos em search.radicle.xyz
    Só não sei se isso está explicitamente linkado na página inicial

• O Radicle é realmente um projeto muito legal
  Estou rodando um nó há meses, mas ainda não uso como principal
  Acredito que uma forge P2P é o futuro da web

  • AD: obrigado por participar; eu também opero um nó seed permissivo
    Participar por si só já é um voto
  • AD: fiquei curioso sobre por que você ainda não usa como principal

• Sempre que um projeto é bloqueado no GitHub, penso: “devia ter usado o Radicle”
  Rodar um nó por trás do Tor também pode evitar pressão legal

  • Fiquei curioso se é possível expor o nó em várias redes ao mesmo tempo (Tor, i2p, clearnet, yggdrasil etc.)
    Alguns projetos no passado tiveram problemas nesse tipo de configuração

• Fiquei curioso sobre como um seed permissivo se protege contra uploads grandes de binários
  Se todas as issues e discussões forem armazenadas, o repositório pode crescer demais
  Parece necessário algum tipo de replicação parcial, como o shallow clone do Git

• Pergunta sobre a diferença em relação ao Forgejo (protocolo ForgeFed)

  • O Radicle tem uma estrutura totalmente P2P, sem conceito de servidor ou instância
    Cada nó executa o mesmo processo, e as contas de usuário usam um modelo self-certifying
    Já o Forgejo tem uma estrutura federada em que os servidores se comunicam via ActivityPub
    Dá para comparar GitHub : Forgejo = Twitter : Mastodon, e compartilhamento de arquivos : BitTorrent = desenvolvimento de software : Radicle
    O Radicle gerencia referências por namespaces criptográficos no nível do projeto, e não por servidor central
    O controle de acesso também se baseia na identidade do usuário, não no servidor