Radicle: una alternativa peer-to-peer a GitHub basada en código abierto

Protocolo y stack Radicle Heartwood

• Radicle Heartwood es la tercera versión del protocolo Radicle, un stack de colaboración y publicación de código entre pares.
• Este repositorio incluye la implementación completa de Heartwood, incluida una interfaz de línea de comandos amigable (rad) y el demonio de red (radicle-node).
• Radicle está diseñado para reemplazar forjas de código como GitHub y GitLab, como una alternativa segura, distribuida y sólida que preserva la soberanía y la libertad de los usuarios.

Requisitos de instalación

• Se requiere Linux o un sistema operativo basado en Unix.
• Se requiere Git 2.34 o superior.
• Se requiere OpenSSH 9.1 o superior y ssh-agent.

Instalación desde binarios

• Se requieren curl y tar.
• Para instalar la última versión binaria, ejecuta el siguiente comando: sh <(curl -sSf https://radicle.xyz/install)

Instalación desde el código fuente

• Se requiere el toolchain de Rust.
• Dentro de este repositorio, puedes ejecutar los siguientes comandos para instalar el stack de Radicle desde el código fuente: cargo install --path radicle-cli --force --locked cargo install --path radicle-node --force --locked cargo install --path radicle-remote-helper --force --locked
• O bien, puedes instalarlo directamente desde un nodo seed: cargo install --force --locked --git https://seed.radicle.xyz/z3gqcJUoA1n9HaHKufZs5FCSGazv5.git \ radicle-cli radicle-node radicle-remote-helper

Ejecución

• En la carpeta /systemd se proporcionan archivos de unidad de Systemd para el demonio del sistema y el demonio HTTP. Pueden usarse como punto de partida para personalizaciones adicionales.
• Además, ambos crates incluyen un Dockerfile.
• Para saber cómo ejecutarlo en modo debug, consulta HACKING.md.

Cómo contribuir

• Para una introducción sobre cómo contribuir a Radicle, consulta CONTRIBUTING.md y HACKING.md.

Licencia

• Radicle se distribuye bajo los términos de la licencia MIT y Apache License (Version 2.0).
• Para más detalles, consulta LICENSE-APACHE y LICENSE-MIT.

Opinión de GN⁺

• Radicle es una plataforma distribuida de colaboración de código que busca reforzar la soberanía del código de los usuarios como alternativa a los servicios centralizados de alojamiento de código. Esto tiene un valor muy importante para los desarrolladores, ya que les da control sobre la propiedad de sus datos y su privacidad.
• La red distribuida que ofrece Radicle no depende de un servidor central, por lo que tiene la ventaja de estar libre de caídas del servicio o censura. Sin embargo, esto también puede afectar la estabilidad y la velocidad de la red, lo que podría impactar negativamente la experiencia de usuario.
• Radicle es un proyecto de código abierto que sigue evolucionando gracias a las contribuciones de la comunidad de desarrolladores. Esto le da la ventaja de poder responder rápidamente a problemas técnicos o a la incorporación de nuevas funciones.
• Antes de adoptar Radicle, conviene considerar la compatibilidad con los servicios centralizados existentes, los requisitos de seguridad del proyecto y las barreras de adopción dentro del equipo.
• Otros proyectos con funciones similares incluyen la versión self-hosted de GitLab y alternativas de código abierto como Gitea, que permiten a los usuarios gestionar su código en sus propios servidores.

[GN⁺]

Comentarios de Hacker News

• Saludo de uno de los cofundadores del proyecto y enlace con una explicación de cómo funciona el protocolo. La documentación todavía está en proceso.

  Hola, Hacker News. Soy uno de los cofundadores de este proyecto. Si tienen curiosidad por cómo funciona el protocolo internamente, empiecen aquí: Documentación de Radicle. Dicho eso, la documentación todavía está en proceso.

• Parece adecuado para el propósito del proyecto, pero la opinión es que git ya es open source y P2P. Con git se puede conectar a otros servidores y traer o fusionar código directamente sin binarios adicionales. Lo que le falta a git son issues de código, wiki, discusiones, GitHub Pages y, sobre todo, una red de perfiles de desarrolladores. Hace falta una forma de incluir metadatos del proyecto en .git, y podría requerirse una referencia independiente para no mezclar wiki e issues.

  Este proyecto parece estar bien construido para su propósito, pero git en sí ya es open source y P2P. Sin necesidad de instalar binarios aparte, puedes conectarte a otro servidor git y traer o fusionar código directamente con comandos de git. Lo que le falta a git son issues de código, wiki, discusiones, GitHub Pages y, lo más importante, una red de perfiles de desarrolladores. Hace falta una forma de incluir metadatos del proyecto en .git. Probablemente se necesite una referencia independiente, como git notes. Documentación de git-notes

• Resulta muy interesante ver la evolución de Radicle. Después de asistir a un taller en Protocol Berg 2023, la opinión es que construyeron algo muy potente y novedoso. Lo más interesante del aspecto colaborativo del protocolo es que también está diseñado con enfoque local-first. Se pueden enviar parches e issues sin internet, y el equipo no se ve afectado cuando GitHub tiene problemas.

  Ha sido muy interesante ver cómo Radicle ha evolucionado durante los últimos 5 años. Asistí a un taller en Protocol Berg 2023 y creo que construyeron algo muy potente y nuevo. Lo que más me interesa es que el aspecto colaborativo del protocolo también está diseñado con un enfoque local-first, de modo que puedes enviar parches e issues incluso sin internet, y el equipo no se ve afectado cuando GitHub tiene problemas.

• Duda sobre por qué usan tanto la licencia MIT como Apache. Se pregunta si la licencia MIT no permite eludir responsabilidades adicionales que sí ofrece la licencia Apache, especialmente en lo relacionado con la concesión de licencias de patentes. Como la licencia MIT no menciona patentes, surge la pregunta de por qué no usar solo MIT.

  Tengo curiosidad por saber por qué usan tanto la licencia MIT como Apache. No es una crítica; puede que yo esté equivocado, pero ¿la licencia MIT no permite eludir la responsabilidad adicional que ofrece la licencia Apache? En especial en lo relacionado con la cláusula de concesión de licencias de patentes. La licencia MIT no menciona las patentes, así que entonces me pregunto por qué no usar simplemente la licencia MIT.

• Duda sobre qué tan fácil es para el público general encontrar estos repositorios. Parece no haber archivo robots.txt, así que los motores de búsqueda podrían rastrearlos. De hecho aparecen resultados en Google y DDG, aunque todavía no muy arriba. El ranking podría mejorar. También sería interesante una herramienta que integre soporte para CI (integración continua). Hacen falta mejores herramientas para limitar los pushes solo a identidades confiables. Por último, se menciona un repositorio de artefactos. Radicle no necesita resolverlo todo, especialmente porque compartir binarios grandes por una red distribuida puede terminar usándose rápidamente para fines no deseados.

  Me pregunto qué tan fáciles son de descubrir estos repositorios para la gente común. Parece que no hay un archivo robots.txt, así que los motores de búsqueda probablemente puedan rastrearlos, y de hecho si buscas en Google y DDG aparecen resultados. Todavía no están muy arriba, pero quizá mejoren si no usas filtros de sitio. También sería interesante una herramienta que integre soporte para CI (integración continua). Hace falta una mejor herramienta que permita restringir los pushes únicamente a identidades confiables. Y por último, se menciona un repositorio de artefactos, aunque Radicle no tiene por qué resolverlo todo. En especial, compartir binarios grandes mediante una red distribuida podría terminar usándose rápidamente para fines no deseados.

• Felicitaciones por el lanzamiento, y entusiasmo por seguir el proyecto y verlo madurar. Pregunta sobre cómo migrar proyectos alojados en GitHub y si existe un modo espejo durante las pruebas.

  ¡Felicidades por el lanzamiento! Ha sido realmente emocionante seguir este proyecto y ver cuánto ha madurado. ¿Cómo se pueden migrar los proyectos que actualmente están en GitHub? ¿Existe un modo espejo mientras se hacen pruebas?

• La documentación menciona que es importante publicar solo repositorios que uno posee o administra, y comunicarse con otros administradores para evitar inicializar identidades duplicadas del repositorio. Sin embargo, es probable que muchas personas no lean la documentación o no presten atención y terminen ignorando esa indicación. La página principal explica cómo hacer push de código, pero este aviso importante solo aparece en la guía de usuario, lo cual podría ser un problema.

  La documentación menciona que es importante publicar solo repositorios que posees o administras, y comunicarte con otros administradores para evitar inicializar identidades duplicadas del repositorio. Pero es muy probable que la gente no lea la documentación o no le preste atención y termine ignorando esta indicación. La página principal explica cómo hacer push de código, pero esta advertencia importante solo puede encontrarse en la guía de usuario, y eso podría ser un problema.

• Se pide una definición precisa de términos como "peer to peer" o "distributed". Cuando se usan como palabras de moda, pueden volverse muy ambiguos.

  Ojalá la gente definiera con precisión términos como "peer to peer" o, más comúnmente, "distributed". Estos términos pueden volverse muy ambiguos cuando se usan como palabras de moda.

• Felicitaciones por el lanzamiento, y comentario de que recuerda a un proyecto similar, nest.pijul.com, que usa pijul en lugar de git.

  ¡Felicidades por el lanzamiento! Esto me recuerda a un proyecto parecido, nest.pijul.com, que usa pijul en lugar de git.

• Mención fuera de tema que recuerda a NESticle.

  Comentario fuera de tema: esto me recuerda a NESticle. Wiki de NESticle