Radicle: alternativa peer-to-peer ao GitHub baseada em código aberto

Protocolo e stack Radicle Heartwood

• O Radicle Heartwood é a terceira versão do protocolo Radicle, uma stack de colaboração e publicação de código entre pares.
• Este repositório inclui a implementação completa do Heartwood, incluindo uma interface de linha de comando amigável (rad) e o daemon de rede (radicle-node).
• O Radicle foi projetado para substituir forjas de código como GitHub e GitLab, como uma alternativa segura, distribuída e robusta que preserva a soberania e a liberdade do usuário.

Requisitos de instalação

• É necessário Linux ou um sistema operacional baseado em Unix.
• É necessário Git 2.34 ou superior.
• São necessários OpenSSH 9.1 ou superior e ssh-agent.

Instalação a partir de binários

• São necessários curl e tar.
• Para instalar a release binária mais recente, execute o seguinte comando: sh <(curl -sSf https://radicle.xyz/install)

Instalação a partir do código-fonte

• É necessário o toolchain do Rust.
• Dentro deste repositório, é possível instalar a stack Radicle a partir do código-fonte executando os seguintes comandos: cargo install --path radicle-cli --force --locked cargo install --path radicle-node --force --locked cargo install --path radicle-remote-helper --force --locked
• Ou é possível instalar diretamente a partir de um seed node: cargo install --force --locked --git https://seed.radicle.xyz/z3gqcJUoA1n9HaHKufZs5FCSGazv5.git \ radicle-cli radicle-node radicle-remote-helper

Execução

• Arquivos de unidade do Systemd para o daemon do sistema e o daemon HTTP são fornecidos na pasta /systemd. Eles podem ser usados como ponto de partida para personalizações adicionais.
• Além disso, ambos os crates incluem Dockerfile.
• Para saber como executar em modo de depuração, consulte HACKING.md.

Como contribuir

• Para uma introdução sobre como contribuir com o Radicle, consulte CONTRIBUTING.md e HACKING.md.

Licença

• O Radicle é distribuído sob os termos da licença MIT e da Apache License (Version 2.0).
• Para mais detalhes, consulte LICENSE-APACHE e LICENSE-MIT.

Opinião do GN⁺

• O Radicle é uma plataforma distribuída de colaboração de código que busca fortalecer a soberania do código do usuário como alternativa a serviços centralizados de hospedagem de código. Isso tem um valor muito importante para desenvolvedores ao oferecer controle sobre propriedade dos dados e privacidade.
• Como a rede distribuída oferecida pelo Radicle não depende de um servidor central, ela tem a vantagem de ficar livre de interrupções de serviço ou censura. No entanto, isso também pode afetar a estabilidade e a velocidade da rede, o que pode impactar negativamente a experiência do usuário.
• O Radicle é um projeto de código aberto que continua evoluindo por meio das contribuições da comunidade de desenvolvedores. Isso traz a vantagem de permitir respostas rápidas na resolução de problemas técnicos ou na adição de novos recursos.
• Antes de adotar o Radicle, é preciso considerar a compatibilidade com serviços centralizados já existentes, os requisitos de segurança do projeto e as barreiras de adoção dentro da equipe.
• Outros projetos com funcionalidades semelhantes incluem a versão self-hosted do GitLab e alternativas open source como o Gitea, que permitem aos usuários gerenciar código em seus próprios servidores.

[GN⁺]

Comentários do Hacker News

• Saudação de um dos cofundadores do projeto, com link para uma explicação de como o protocolo funciona. A documentação ainda está em andamento.

  Olá, pessoal do Hacker News. Sou um dos cofundadores deste projeto. Se vocês têm curiosidade sobre como o protocolo funciona por dentro, comecem por aqui: Documentação do Radicle. Mas a documentação ainda está em andamento.

• Parece adequado ao propósito do projeto, mas há a observação de que o git já é open source e P2P. Com o git, é possível conectar-se a outro servidor e buscar ou mesclar código diretamente sem binários adicionais. O que falta no git são issues de código, wiki, discussões, GitHub Pages e, mais importante, a rede de perfis de desenvolvedores. Seria preciso uma forma de incluir metadados do projeto no próprio .git, e talvez referências independentes para não confundir wiki e issues.

  Este projeto parece muito bem feito para o propósito, mas o próprio git já é open source e P2P. Sem precisar instalar um binário separado, você pode se conectar a outro servidor git e buscar ou mesclar código diretamente com comandos do git. O que falta no git são issues de código, wiki, discussões, GitHub Pages e, o mais importante, uma rede de perfis de desenvolvedores. É preciso uma forma de incluir metadados do projeto no .git. Talvez seja necessário algo como referências independentes, semelhantes a git notes. Documentação do git-notes

• Acompanhar a evolução do Radicle tem sido muito interessante. Depois de participar do workshop na Protocol Berg 2023, a impressão é de que construíram algo muito poderoso e novo. O aspecto mais interessante da colaboração no protocolo é que ela também é local-first. Dá para enviar patches e issues sem internet, e a equipe não é afetada quando o GitHub apresenta problemas.

  Foi muito interessante acompanhar como o Radicle evoluiu nos últimos cinco anos. Participei de um workshop na Protocol Berg 2023 e acho que eles construíram algo muito poderoso e novo. O mais interessante, especialmente, é que o aspecto colaborativo do protocolo também foi projetado com uma abordagem local-first, então é possível enviar patches e issues mesmo sem internet, e a equipe não é afetada quando o GitHub tem problemas.

• Curiosidade sobre o motivo de usar tanto a licença MIT quanto a Apache. A dúvida é se a licença MIT não permitiria contornar as responsabilidades adicionais da licença Apache, especialmente a cláusula de concessão de licença de patente. Como a MIT não menciona patentes, surge a pergunta: por que não usar apenas a MIT?

  Tenho curiosidade sobre o motivo de usar tanto a licença MIT quanto a Apache. Não é uma crítica, e posso estar errado, mas a licença MIT não permite contornar as responsabilidades adicionais oferecidas pela licença Apache? Especialmente no que diz respeito à cláusula de concessão de licença de patente. A licença MIT não menciona patentes, então, nesse caso, por que não usar apenas a licença MIT?

• Dúvida sobre o quão fácil seria para o público em geral encontrar esses repositórios. Parece não haver arquivo robots.txt, então mecanismos de busca poderiam rastreá-los. Há resultados no Google e no DDG, embora ainda não muito bem posicionados. Isso pode melhorar. Também seria interessante uma ferramenta integrada de suporte a CI (integração contínua). São necessárias ferramentas melhores para restringir pushes apenas a identidades confiáveis. Por fim, há menção a um repositório de artefatos. O Radicle não precisa resolver tudo, especialmente porque compartilhar binários grandes por uma rede distribuída pode rapidamente ser usado para fins indesejados.

  Fico imaginando o quão fáceis esses repositórios são de encontrar para o público em geral. Parece não haver um arquivo robots.txt, então os mecanismos de busca deveriam conseguir rastreá-los e, de fato, se você procurar no Google ou no DDG, aparecem resultados. Ainda não estão muito bem posicionados, mas talvez isso melhore sem usar filtros de site. Também seria interessante uma ferramenta que integrasse suporte a CI (integração contínua). São necessárias ferramentas melhores para restringir pushes apenas a identidades confiáveis. E, por fim, há a questão de um repositório de artefatos, mas o Radicle não precisa resolver tudo. Especialmente porque o compartilhamento de binários grandes por uma rede distribuída pode rapidamente ser usado para fins indesejados.

• Parabeniza pelo lançamento e demonstra entusiasmo ao ver o projeto amadurecer. Pergunta como migrar projetos atualmente no GitHub e se existe um modo espelho durante os testes.

  Parabéns pelo lançamento! Foi realmente muito interessante acompanhar este projeto e ver o quanto ele amadureceu. Como os projetos que atualmente estão no GitHub podem ser migrados? Existe um modo espelho durante os testes?

• A documentação menciona que é importante publicar apenas repositórios que você possui ou administra e se comunicar com outros administradores para evitar inicializar identidades duplicadas de repositório. No entanto, é provável que as pessoas ignorem esse pedido por não lerem a documentação com atenção. A página inicial explica como enviar código, mas esse aviso importante só aparece no guia do usuário, o que pode ser um problema.

  A documentação menciona que é importante publicar apenas repositórios que você possui ou administra, além de se comunicar com outros administradores para não inicializar identidades duplicadas de repositório. Mas é bem provável que as pessoas não leiam a documentação ou não prestem atenção e acabem ignorando esse pedido. A página inicial mostra como fazer push de código, mas essa solicitação importante só pode ser encontrada no guia do usuário, o que pode ser um problema.

• Desejo de que termos como "peer to peer" ou "distributed" sejam definidos com precisão. Quando usados como buzzwords, podem se tornar muito vagos.

  Gostaria que as pessoas definissem com precisão termos como "peer to peer" ou, mais frequentemente, "distributed". Esses termos podem se tornar muito vagos quando usados como buzzwords.

• Parabeniza pelo lançamento e diz que isso lembra o nest.pijul.com, um projeto semelhante que usa pijul em vez de git.

  Parabéns pelo lançamento! Isso me faz lembrar do nest.pijul.com, um projeto semelhante que usa pijul em vez de git.

• Comentário fora do tema dizendo que isso lembra o NESticle.

  Comentário fora do tema: isso me faz lembrar do NESticle. Wiki do NESticle