- Radicle Heartwood é a terceira implementação do Protocolo Radicle e oferece uma stack de colaboração e publicação de código em modo peer-to-peer, sem uma code forge centralizada
- O repositório inclui a ferramenta de linha de comando
rad, usada diretamente por desenvolvedores, e o daemon de rede radicle-node
- Foi projetado para substituir code forges como GitHub e GitLab, com segurança e descentralização e a preservação da soberania do usuário como objetivos centrais
- O ambiente de instalação exige Linux ou um sistema operacional da família Unix, Git 2.34 ou superior e OpenSSH 9.1 ou superior com
ssh-agent
- Suporta tanto instalação por binário quanto a partir do código-fonte em Rust, mas os feedbacks enviados por e-mail são publicados automaticamente em um canal público do Zulip, podendo expor nome e endereço de e-mail
O que o Radicle Heartwood oferece
- Heartwood é a terceira iteração do Protocolo Radicle e uma stack completa para colaboração e publicação de código em peer-to-peer
- O repositório inclui os principais componentes necessários para a implementação do Heartwood
rad: interface de linha de comando amigávelradicle-node: daemon de rede
- O Radicle foi projetado como alternativa a code forges como GitHub e GitLab
- O objetivo é preservar segurança, descentralização, soberania e liberdade do usuário
- Informações gerais podem ser consultadas na Radicle home page
- As conversas do projeto podem acontecer no Zulip chat
- O funcionamento do Radicle está detalhado no Protocol Guide
Instalação e execução
- Os requisitos de instalação são os seguintes
- sistema operacional baseado em Linux ou Unix
-
Git 2.34 ou superior
- OpenSSH 9.1 ou superior com
ssh-agent
- A instalação por binário requer
curl e tar, e a versão mais recente pode ser instalada com o seguinte comando
curl -sSf https://radicle.dev/install | sh
- Os binários também podem ser baixados na página de [download](https://radicle.dev/download)
- Para instalar a partir do código-fonte, é necessário o **toolchain Rust**, e os seguintes comandos devem ser executados dentro do repositório
cargo install --path crates/radicle-cli --force --locked --root ~/.radicle
cargo install --path crates/radicle-node --force --locked --root ~/.radicle
cargo install --path crates/radicle-remote-helper --force --locked --root ~/.radicle
- Também é possível instalar diretamente a partir de um seed node
cargo install --force --locked --root ~/.radicle \
--git https://seed.radicle.dev/z3gqcJUoA1n9HaHKufZs5FCSGazv5.git \
crates/radicle-cli crates/radicle-node crates/radicle-remote-helper
- O arquivo **systemd unit** para o node está na pasta `/systemd` e pode ser usado como ponto de partida para personalizações adicionais
- Para executar em modo de depuração, consulte o [HACKING.md](https://radicle.network/nodes/iris.radicle.network/rad%3Az3gqcJUoA1n9HaHKufZs5FCSGazv5/tree/HACKING.md)
Feedback, contribuição e licença
- O feedback pode ser enviado via
rad issue, Zulip ou feedback@radicle.dev
- Os feedbacks enviados por e-mail são publicados automaticamente no canal público #feedback do Zulip
- Durante a publicação, o cabeçalho
From é exposto publicamente e normalmente inclui nome e endereço de e-mail
- As orientações para contribuir estão em CONTRIBUTING.md e HACKING.md
- O Radicle é distribuído sob os termos da licença MIT e da Apache License 2.0
- Os detalhes estão em LICENSE-APACHE e LICENSE-MIT
1 comentários
Opiniões do Hacker News
Sou cofundador do Radicle. Se quiser saber como o protocolo funciona internamente, comece pela documentação: https://docs.radicle.xyz/
A documentação ainda está em elaboração
Basicamente, se isto é um aplicativo P2P de compartilhamento de arquivos, fico curioso em qual parte do protocolo o abuso é tratado. Caso contrário, não vejo como ele difere de aplicativos de compartilhamento de arquivos da geração anterior, como BitTorrent ou Winny, que compartilhavam arbitrariamente conteúdo protegido por direitos autorais, como filmes, músicas e software. Parece que um pequeno número de usuários mal-intencionados poderia estragar tudo, e também me pergunto se é possível separar redes “privadas” para ter certeza de que não se está participando de algo ilegal
No Crunchbase consta que receberam US$ 12 milhões em investimento, então imagino que haja um plano de monetização
Para o tipo de projeto em que ajudo, isso pode ser fatal. O código parece ser em Rust; fico curioso se há planos de suporte ao MS Windows. Posso considerar o Mac OS como incluído na família Unix, certo? Mesmo que não haja suporte oficial ao Windows, será que um port para MSYS2 é possível?
Para acrescentar um pouco de contexto, não estou em posição de tomar decisões como escolher fornecedores de serviços; estou ligado a uma organização semigovernamental que mantém uma base considerável de código aberto no GitHub. Às vezes tenho a oportunidade de sugerir determinadas ideias, mas a adoção não está sob minha autoridade. Essa organização é muito motivada a ter resiliência contra políticas de fornecedores privados e também a fazer “coisas boas”, como sustentabilidade e amplo acesso. Sendo uma organização governamental europeia típica, o GitHub entra em conflito com essas políticas
Há outros órgãos governamentais responsáveis por arquivamento ou suporte de rede, mas eles têm pouca capacidade ou estão presos a métodos antigos, e frequentemente caem nas armadilhas deixadas por fornecedores. Por exemplo, um serviço de arquivamento adotou DataBricks de forma ampla sem nem saber que é um produto comercial de código fechado. Por isso, minha expectativa de que essa organização aproveite bem uma solução auto-hospedada é baixa, e uma solução descentralizada parece boa. No entanto, não podemos usar uma ferramenta que não funcione nos principais ambientes de PC do público em geral
Também tenho curiosidade sobre qual nível de adoção era esperado antes e agora, e se os resultados reais bateram com essas expectativas
Foi interessante acompanhar como o Radicle evoluiu ao longo dos últimos cinco anos mais ou menos. Participei do workshop Protocol Berg 2023 e acho que eles criaram algo bem poderoso e novo
O ponto especialmente interessante é que até os recursos de colaboração são local-first. Dá para enviar patches e issues mesmo sem internet, e a equipe inteira não precisa ficar grudada no HN toda vez que o GitHub tem algum problema
Parece um projeto adequado para o objetivo, mas acho que o próprio Git já é open source e P2P. Não é preciso obter binários via
sh <(curl); basta conectar a outro servidor Git e buscar ou mesclar o código diretamente com comandos GitO que falta no Git são issues de código, wiki, discussões, GitHub Pages e, acima de tudo, uma rede de perfis de desenvolvedores. É preciso uma forma de colocar metadados do projeto no próprio
.git, sem misturar commits de código-fonte com wiki ou issues. Talvez referências independentes comogit notessejam possíveishttps://git-scm.com/docs/git-notes
Por exemplo, não há como verificar se um repositório recebido com
git cloneé o repositório que você solicitou. Por isso, é preciso clonar de uma fonte confiável, ou seja, de um servidor conhecido. Isso não combina com P2P práticoO Radicle resolve esse problema atribuindo identificadores de repositório estáveis[0], verificáveis localmente, permitindo que entidades não confiáveis forneçam repositórios
[0]: https://docs.radicle.xyz/guides/protocol#trust-through-self-...
No celular, ao tocar nos botões na parte inferior do link original, dá para ver a aba de rastreamento de issues, a aba de pull requests etc.
Pelo que lembro, o Gerrit antigamente armazenava revisões de código no Git
A documentação diz que “é importante publicar apenas repositórios que você possui ou dos quais é mantenedor, e comunicar-se com outros mantenedores para evitar criar identificadores de repositório duplicados”.
Já passei por pessoas pegando meu código e publicando no GitHub, e vi muitas vezes que, mesmo colocando em documentação de produto ou em alguma UI intermediária um aviso do tipo “por favor, não faça X, isso causa problemas para outros usuários”, ninguém lê, pensa ou se importa, e vai direto fazer X. Por isso acho que muita gente não vai seguir esse pedido na documentação; pior, a página inicial só ensina como fazer push do código, e esse pedido “importante” fica em um guia do usuário que quase ninguém lê.
No fim, é bastante preocupante que uma ação que parece razoável — simplesmente fazer push de um código open source em que se está trabalhando, seguindo as instruções da página inicial — possa, por causa do protocolo e da forma de armazenamento, acabar bagunçando ou confundindo algo importante com o tempo.
No GitHub, você pode obter confiança adicional pelo número de estrelas; no Radicle, o equivalente é a quantidade de seeds de um determinado repositório.
Em um dia comum de computação, vemos dezenas de instruções e usamos dezenas de ferramentas. Se você pensar no tempo que levaria para ler todas essas instruções e toda a documentação de todas as ferramentas com atenção, seria tempo demais.
Por isso, é muito melhor não ler e usar heurísticas. Por exemplo, se você fecha um documento com alterações não salvas, sabe que a caixa de diálogo provavelmente diz “descartar?”, então não precisa ler. Isso é algo bom.
A conclusão é que o software deve ser projetado partindo do pressuposto de que as pessoas agem assim. Normalmente isso é possível. Se houver exemplos concretos, acho que daria para sugerir soluções melhores do que “pedir e torcer para que leiam”.
Parabéns pelo lançamento. Venho acompanhando este projeto e é muito animador ver como ele amadureceu. Fico curioso sobre qual seria a melhor forma de migrar projetos que hoje estão no GitHub. Também gostaria de saber se há algum modo de espelhamento que dê para testar.
cronque busca do GitHub a cada hora e faz push para o Radicle.git pull github mastergit push rad masterFico curioso para saber o quão descobertos esses repositórios serão por usuários comuns. Parece que https://app.radicle.xyz/robots.txt não existe, então os mecanismos de busca aparentemente podem indexar, e de fato há resultados ao pesquisar
site:app.radicle.xyzno Google e no DDG.Ainda não aparece no topo sem filtros de site, mas o ranqueamento pode melhorar.
Também seria bom ter ferramentas que se integrem com suporte a CI. No fim, talvez seja um loop como
while true; do wait_repo_update; git pull && ./run_ci.sh; done, mas seria preciso uma forma melhor de restringir isso apenas a pushes de identificadores confiáveis.Por fim, também é necessário um armazenamento de artefatos. Dito isso, talvez o Radicle não precise resolver tudo. Especialmente uma rede distribuída para compartilhar binários grandes parece algo que rapidamente seria usado para fins indesejados.
app.radicle.xyzdevem permitir que crawlers indexem o conjunto completo de repositórios da rede.Gostaria que as pessoas definissem com clareza o que querem dizer exatamente com “P2P” ou, como é mais comum, “distribuído”. Hoje isso virou uma palavra da moda vaga demais, que pode ser usada para significar qualquer coisa.
Portanto, um sistema P2P é um sistema em que todos os participantes têm “privilégios iguais dentro da rede”. Normalmente isso também significa que todos executam o mesmo software.
[0]: https://en.wikipedia.org/wiki/Peer-to-peer
O guia de instalação ser
curl -sSf [https://radicle.xyz/install](<https://radicle.xyz/install>;) | shfez minhas expectativas desabarem direto no lixo do curl-bashEsse tipo de instalação é um forte sinal de desenvolvimento sem pensar. Se este projeto decolar, acho que vamos ver um desastre de segurança acontecer. Espero que um dia surja uma “alternativa P2P open source ao GitHub” que não comece pelo pior método de instalação possível
Os riscos de instaladores via pipe são bem conhecidos por muita gente. Por essa lógica, teríamos que descartar Homebrew [1](mais de 38 mil estrelas no GitHub), PiHole [2](mais de 46 mil), Chef [3], RVM [4] e inúmeros projetos open source que usam instaladores automáticos de uma etapa com pipe para
bashUma resposta mais razoável seria colaborar com os desenvolvedores para oferecer métodos alternativos de instalação na documentação ou explicar melhor os riscos, não queimar a casa inteira para matar um percevejo
[1] https://brew.sh/
[2] https://github.com/pi-hole/pi-hole
[3] https://docs.chef.io/chef_install_script/#run-the-install-sc...
[4] https://rvm.io/rvm/install
Quanto ao problema de a transferência ser interrompida, a menos que no seu sistema haja comandos perigosos que correspondam a
^(t(e(m(p(d(ir?)?)?)?)?|a(r(g(et?)?)?)?)?|i(n(_(p(a(th?)?)?)?|fo?)?)?|s(u(c(c(e(s?s)?)?)?)?)?|f(a(t(al?)?)?)?|m(a(in?)?)?|w(a(rn?)?)?|u(rl?)?), o script é seguroDepois de lidar com isso, fico me perguntando qual é a diferença entre só disponibilizar o script e não fornecer o comando para executá-lo. Se quiser revisar, é só baixar o script e executá-lo separadamente. Acho que havia uma forma de detectar scripts executados via pipe versus scripts baixados, mas provavelmente não funcionaria para um script pequeno desses
[0] https://files.radicle.xyz/latest/
[1] https://app.radicle.xyz/nodes/seed.radicle.garden/rad:z3gqcJ...
Parece que ouço falar da Radicle sempre que o mercado de criptomoedas sobe. Tem alguém usando isso a sério?
Isso levou downvote num instante. Estou perguntando sério: queria saber quanto orçamento entrou na Radicle, quantas pessoas trabalharam nela e quem está usando
Trabalho no setor de criptomoedas e tive a mesma impressão. A última vez que ouvi falar da Radicle foi no último ciclo de alta, e durante o mercado de baixa ficou quieto. Todo mundo diz que mercado de baixa é hora de construir, e a Radicle claramente é uma ferramenta para desenvolvedores, então é bem estranho
Fico me perguntando se há planos para dar suporte ao caso de uso de disponibilizar repositórios apenas para um conjunto específico de nós. Imagino que haja pessoas que não queiram estar no GitHub, mas queiram colaboração privada
Porém, eles não são criptografados em repouso, então não podem ser armazenados em nós intermediários que não façam parte do conjunto confiável