- Radicle Heartwood es la tercera implementación de Radicle Protocol y ofrece una pila de colaboración y publicación de código peer-to-peer sin forjas de código centralizadas
- El repositorio incluye la herramienta de línea de comandos
rad, usada directamente por desarrolladores, y el demonio de red radicle-node
- Está diseñado para reemplazar forjas de código como GitHub y GitLab, con seguridad y descentralización, además de la preservación de la soberanía del usuario, como objetivos centrales
- El entorno de instalación requiere Linux o un sistema operativo tipo Unix, Git 2.34 o superior y OpenSSH 9.1 o superior con
ssh-agent
- Admite instalación mediante binarios y desde código fuente en Rust, pero los correos de feedback se publican automáticamente en un canal público de Zulip, por lo que el nombre y la dirección de correo pueden quedar expuestos
Qué ofrece Radicle Heartwood
- Heartwood es la tercera iteración de Radicle Protocol y una pila completa para colaboración y publicación de código peer-to-peer
- El repositorio incluye los componentes principales necesarios para implementar Heartwood
rad: una interfaz de línea de comandos fácil de usarradicle-node: el demonio de red
- Radicle está diseñado como una alternativa a forjas de código como GitHub y GitLab
- Su objetivo es preservar la seguridad, la descentralización, y la soberanía y libertad del usuario
- La información general está disponible en la Radicle home page
- Las conversaciones del proyecto se pueden realizar en el Zulip chat
- El funcionamiento de Radicle está detallado en la Protocol Guide
Instalación y ejecución
- Los requisitos de instalación son los siguientes
- Linux o un sistema operativo basado en Unix
-
Git 2.34 o superior
- OpenSSH 9.1 o superior con
ssh-agent
- Para la instalación mediante binarios se necesitan
curl y tar; la versión más reciente se instala con el siguiente comando
curl -sSf https://radicle.dev/install | sh
- Los binarios también se pueden obtener en la página de [download](https://radicle.dev/download)
- Para instalar desde el código fuente se necesita el **toolchain de Rust**; dentro del repositorio, ejecuta los siguientes comandos
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
- También se puede instalar directamente desde un 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
- El archivo de **systemd unit** para el nodo está en la carpeta `/systemd` y puede usarse como punto de partida para personalizaciones adicionales
- Para ejecutar en modo de depuración, consulta [HACKING.md](https://radicle.network/nodes/iris.radicle.network/rad%3Az3gqcJUoA1n9HaHKufZs5FCSGazv5/tree/HACKING.md)
Feedback, contribuciones y licencia
- El feedback puede enviarse mediante
rad issue, Zulip o feedback@radicle.dev
- El feedback enviado por correo electrónico se publica automáticamente en el canal público #feedback de Zulip
- Durante la publicación, se expone el encabezado
From, que generalmente incluye el nombre y la dirección de correo electrónico
- Las guías para contribuir están en CONTRIBUTING.md y HACKING.md
- Radicle se distribuye bajo los términos de la licencia MIT y la Apache License 2.0
- Los detalles están en LICENSE-APACHE y LICENSE-MIT
1 comentarios
Opiniones de Hacker News
Soy cofundador de Radicle. Si te interesa saber cómo funciona el protocolo por dentro, conviene empezar por la documentación: https://docs.radicle.xyz/
La documentación todavía está en proceso
Si básicamente es una app P2P para compartir archivos, me pregunto en qué parte del protocolo se aborda el abuso. Si no, no veo en qué se diferencia de apps de intercambio de archivos de generaciones anteriores, como BitTorrent o Winny, donde se compartía arbitrariamente contenido con copyright como películas, música o software. Parece que un pequeño grupo de usuarios maliciosos podría arruinarlo, y también me pregunto si es posible separar redes “privadas” para poder estar seguro de no participar en algo ilegal
En Crunchbase figura que recibieron 12 millones de dólares de inversión, así que imagino que habrá algún plan de monetización
Para el tipo de proyectos en los que ayudo, esto podría ser crítico. El código parece estar en Rust, y me pregunto si hay planes de dar soporte a MS Windows. ¿Supongo que Mac OS cuenta como parte de la familia Unix? Aunque no haya soporte oficial para Windows, me pregunto si sería posible un port a MSYS2.
Para agregar un poco de contexto: no estoy en una posición donde tome decisiones como la selección de proveedores de servicios, sino que estoy vinculado a una organización semigubernamental que tiene una base de código open source considerable alojada en GitHub. A veces tengo la oportunidad de proponer ciertas ideas, pero no depende de mí que se adopten. Esta organización tiene una fuerte motivación para ser resiliente y no quedar a merced de las políticas de proveedores privados, y también para hacer “cosas buenas” como sostenibilidad o amplio acceso. Como organización gubernamental europea típica, GitHub entra en conflicto con esas políticas.
También hay otros organismos gubernamentales encargados del archivado o del soporte de red, pero les falta capacidad o siguen atrapados en formas antiguas de hacer las cosas, y a menudo caen en trampas tendidas por proveedores. Por ejemplo, un servicio de archivado adoptó por completo DataBricks sin siquiera saber que era un producto comercial de código cerrado. Por eso tengo pocas expectativas de que esa organización aproveche bien una solución autohospedada, y una solución distribuida se ve atractiva. Pero no podemos usar una herramienta que no funcione en los principales entornos de PC de uso masivo
También me da curiosidad qué nivel de adopción esperaban antes y qué nivel esperan ahora, y si los resultados reales coincidieron con esas expectativas
Fue interesante observar cómo Radicle ha evolucionado durante los últimos cinco años aproximadamente. Asistí al taller Protocol Berg 2023, y creo que construyeron algo bastante potente y novedoso.
Lo especialmente interesante es que incluso las funciones de colaboración son local-first. Puedes enviar parches e issues aunque no tengas internet, y cada vez que GitHub tenga problemas ya no hará falta que todo el equipo esté pegado a HN
Para su propósito parece un proyecto razonable, pero creo que Git en sí ya es open source y P2P. No hace falta recibir binarios con
sh <(curl); basta con conectarse a otro servidor Git y traer o fusionar el código directamente con comandos de Git.Lo que Git no tiene son issues de código, wikis, debates, GitHub Pages y, sobre todo, una red de perfiles de desarrolladores. Hace falta una forma de poner los metadatos del proyecto dentro de
.gitmismo para que los commits de código fuente no se mezclen con la wiki o los issues. Quizá sea posible con referencias independientes comogit notes.https://git-scm.com/docs/git-notes
Por ejemplo, no hay forma de verificar que el repositorio que recibí con
git clonesea el repositorio que pedí. Por eso hay que clonar desde una fuente confiable, es decir, un servidor conocido. Eso no encaja con un P2P práctico.Radicle resuelve este problema asignando identificadores de repositorio estables[0] que se pueden verificar localmente, lo que permite que entidades no confiables alojen repositorios.
[0]: https://docs.radicle.xyz/guides/protocol#trust-through-self-...
En móvil, si tocas los botones que están debajo del enlace original, puedes ver la pestaña de seguimiento de issues, la pestaña de pull requests, etc.
Recuerdo que Gerrit antes guardaba las revisiones de código en Git
En la documentación dice que “es importante publicar solo repositorios de los que seas propietario o mantenedor, y comunicarte con otros mantenedores para evitar crear identificadores de repositorios duplicados”.
Ya me ha tocado gente que toma mi código y lo sube a GitHub, y también he visto muchas veces que, aunque en la documentación del producto o en una UI intermedia se ponga un aviso tipo “por favor no hagas X, porque les causa problemas a otros usuarios”, nadie lo lee, lo piensa ni le importa, y hacen X de inmediato. Por eso creo que mucha gente no va a respetar esta petición de la documentación; incluso la página principal solo explica cómo hacer push del código, mientras que esta petición “importante” está en una guía de usuario que casi nadie lee.
Al final, me preocupa bastante que una acción que parece razonable, como simplemente hacer push del código open source en el que estás trabajando siguiendo las instrucciones de la página principal, pueda con el tiempo desordenar o volver confuso algo importante por la forma en que funcionan el protocolo y el almacenamiento.
En GitHub puedes obtener confianza adicional por la cantidad de estrellas, y en Radicle el equivalente sería la cantidad de seeds de un repositorio específico.
En un día normal de uso de computadoras vemos decenas de avisos y usamos decenas de herramientas. Si piensas en el tiempo que tomaría leer todos esos avisos y toda la documentación de cada herramienta con cuidado, sería demasiado.
Por eso es mucho mejor no leer y usar heurísticas. Por ejemplo, si cierras un documento con cambios sin guardar, sabes que el cuadro de diálogo dirá “¿descartar?”, así que no hace falta leerlo. Eso es algo bueno.
La conclusión es que el software debe diseñarse asumiendo que la gente se comporta así. Por lo general es posible. Si tienes un ejemplo concreto, creo que podría proponer una solución mejor que “pedirlo y esperar que lo lean”.
Felicidades por el lanzamiento. He estado siguiendo este proyecto y me entusiasma mucho ver cuánto ha madurado. Me pregunto cuál sería la mejor forma de migrar proyectos que actualmente están en GitHub. También me pregunto si hay un modo espejo que se pueda probar.
cronque cada hora haga fetch desde GitHub y push a Radicle.git pull github mastergit push rad masterMe pregunto qué tan descubribles serán estos repositorios para usuarios comunes. Parece que https://app.radicle.xyz/robots.txt no existe, así que los motores de búsqueda podrían indexarlo, y de hecho al buscar
site:app.radicle.xyzen Google y DDG aparecen resultados.Todavía no aparecen arriba sin filtrar por sitio, pero el ranking podría mejorar.
También estaría bueno tener herramientas que se integren con soporte de CI. En última instancia sería un bucle como
while true; do wait_repo_update; git pull && ./run_ci.sh; done, pero hace falta una forma mejor que permita limitarlo solo a pushes de identificadores confiables.Por último, también hace falta un repositorio de artefactos. Aunque quizá Radicle no tenga que resolverlo todo. En particular, una red distribuida para compartir binarios grandes parece algo que podría usarse para fines no deseados bastante rápido.
app.radicle.xyzdeberían permitir que los crawlers indexen el conjunto completo de repositorios de la red.Me gustaría que la gente definiera con claridad qué significa exactamente “P2P” o, como se dice más comúnmente, “distribuido”. Ahora se ha convertido en una buzzword vaga que puede usarse para cualquier cosa.
Por lo tanto, un sistema P2P es un sistema en el que todos los participantes tienen “los mismos privilegios dentro de la red”. Normalmente eso también significa que todos ejecutan el mismo software.
[0]: https://en.wikipedia.org/wiki/Peer-to-peer
Que la guía de instalación sea
curl -sSf [https://radicle.xyz/install](<https://radicle.xyz/install>;) | shhizo que mis expectativas se derrumbaran de inmediato ante la basura de curl-bashEste tipo de instalación es una fuerte señal de desarrollo poco pensado. Si este proyecto despega, creo que veremos desplegarse un desastre de seguridad. Espero que algún día aparezca una “alternativa open source P2P a GitHub” que no empiece con la peor forma de instalación
Los riesgos de los instaladores por pipe son bien conocidos por mucha gente. Con esa lógica, habría que descartar Homebrew [1] (más de 38 mil estrellas en GitHub), PiHole [2] (más de 46 mil), Chef [3], RVM [4] y muchísimos proyectos open source que usan instaladores automáticos de un solo paso que se pasan por pipe a
bashUna respuesta más razonable sería colaborar con los desarrolladores para que la documentación ofrezca métodos de instalación alternativos o explique mejor los riesgos, no quemar la casa para matar las chinches
[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
En cuanto al problema de que se interrumpa la transferencia, el script es seguro salvo que en tu sistema haya comandos peligrosos que coincidan con
^(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?)?)Una vez resuelto eso, no veo qué diferencia hay con ofrecer solo el script y no el comando para ejecutarlo. Si quieres revisarlo, puedes descargar el script y ejecutarlo aparte. Creo que había una forma de detectar scripts enviados por pipe frente a scripts descargados, pero probablemente no funcione con un script tan pequeño
[0] https://files.radicle.xyz/latest/
[1] https://app.radicle.xyz/nodes/seed.radicle.garden/rad:z3gqcJ...
Siento que escucho hablar de Radicle cada vez que sube el mercado cripto. ¿Alguien lo usa en serio?
Esto recibió downvotes al instante. Lo pregunto en serio: me da curiosidad cuánto presupuesto se ha destinado a Radicle, cuánta gente ha trabajado en él y quién lo está usando
Trabajo en la industria cripto y tuve la misma impresión. La última vez que oí hablar de Radicle fue en el ciclo alcista anterior, y durante el mercado bajista estuvo silencioso. Todo el mundo dice que el mercado bajista es para construir, y Radicle claramente es una herramienta para desarrolladores, así que resulta bastante raro
Me pregunto si planean soportar el caso de uso de ofrecer repositorios solo a un conjunto específico de nodos. Me imagino que hay gente que no quiere estar en GitHub, pero sí quiere colaboración privada
Sin embargo, no están cifrados en reposo, así que no se pueden almacenar en nodos intermedios que no formen parte del conjunto de confianza