Tangled - plataforma de colaboración Git basada en atproto

 (blog.tangled.org)
3 puntos por GN⁺ 2025-10-12 | 2 comentarios | Compartir por WhatsApp
  • Tangled es una plataforma de colaboración Git con funciones sociales basada en AT Protocol, diseñada para que los desarrolladores mantengan la propiedad total de su código y, al mismo tiempo, las comunidades de código abierto puedan operar de forma autónoma
  • Adopta una arquitectura distribuida de colaboración de código que combina las ventajas del modelo federado centrado en ActivityPub (Forgejo) y del modelo completamente P2P de Radicle
  • Su concepto central, “Knot”, es un servidor Git ligero y sin interfaz que admite tanto self-hosting individual como entornos multi-tenant a nivel comunitario
  • App View (tangled.sh) ofrece una vista unificada de los repositorios de toda la red, permitiendo explorar, clonar y contribuir sin fricción a repositorios ubicados en distintos Knot
  • Actualmente está en fase beta y toma como principios clave la propiedad de los datos, la baja barrera de entrada y la preservación de la experiencia de usuario, con la meta futura de construir un ecosistema Git distribuido completamente abierto

Resumen de Tangled

  • Tangled es una nueva plataforma que ofrece un entorno de colaboración Git con interacción social, donde los desarrolladores conservan la propiedad de su código y su identidad
  • Está basada en AT Protocol y aplica una arquitectura de apps sociales descentralizadas a la colaboración en Git
  • Su objetivo es devolver la colaboración de código a un proceso abierto y disfrutable

Modelo distribuido y AT Protocol

  • En los modelos existentes de colaboración distribuida de código se encuentran enfoques como los siguientes
    • Forgejo (ActivityPub): colaboración mediante federación entre servidores
    • Radicle: estructura totalmente P2P (peer-to-peer)
  • Tangled combina las ventajas de ambos modelos y adopta atproto, que permite una gestión centralizada de identidad
  • Gracias a esto, los usuarios pueden mantener una estructura consistente de ID y autenticación incluso dentro de una red distribuida

Estructura de Knot

  • Knot es el componente central de Tangled: un servidor ligero que permite a los usuarios hospedar repositorios Git directamente
    • Admite configuraciones single-tenant y multi-tenant
    • Puede alojarse de forma independiente incluso en equipos pequeños como una Raspberry Pi
  • Tangled también ofrece por defecto un servicio administrado de Knot gratuito
  • Gracias a esta estructura, se forma una red Git distribuida donde los servidores personales de los usuarios y los servidores comunitarios se conectan de manera natural

App View y red unificada

  • El App View disponible en tangled.sh muestra los repositorios de toda la red en una sola vista unificada
  • Los usuarios pueden clonar (clone) y contribuir (contribute) fácilmente incluso en repositorios alojados en otros Knot
  • Este diseño mantiene intacto el flujo de trabajo tradicional de Git mientras elimina las barreras de un entorno distribuido

Principios de desarrollo

  • El equipo de Tangled estableció los siguientes tres principios para guiar su desarrollo
    • 1. Propiedad de los datos — todos los usuarios poseen directamente el código y los metadatos que crean
    • 2. Baja barrera de entrada — estructura e interfaz simples para que cualquiera pueda participar fácilmente
    • 3. Consistencia en la experiencia de usuario — garantizar una UX al nivel de los servicios centralizados pese a la estructura distribuida
  • Estos principios se reflejan en las decisiones técnicas de Tangled y en todo el diseño de su UI/UX

Acceso y comunidad

  • Al principio operaba con acceso por invitación (invite-only), y los desarrolladores podían participar a través del canal IRC #tangled (libera.chat)
  • Actualmente el inicio de sesión público está abierto, y cualquiera puede usarlo en tangled.sh/login
  • Tangled todavía está en una etapa temprana, pero sigue creciendo mientras valida sus funciones mediante uso interno (dogfooding)

Conclusión

  • Tangled es un intento de expandir la colaboración en Git hacia una experiencia conectada como la de una red social
  • Está llamando la atención como un nuevo ecosistema de plataforma Git distribuida que combina autonomía, accesibilidad y una cultura de desarrollo más disfrutable

Lecturas relacionadas

2 comentarios

 
lamanus 2025-10-12

Como no hay un contenedor oficial, la configuración inicial resulta un poco engorrosa.
 
GN⁺ 2025-10-12
Comentarios en Hacker News
  • Como cofundador de Tangled, hace poco al reemplazar la librería de OAuth hubo un problema por el que los usuarios nuevos no se agregaban al knot y spindle predeterminados (el servidor interno de hosting git y el runner de CI); acabo de aplicar el parche, así que si cierran sesión y vuelven a iniciarla ya deberían poder crear repositorios normalmente. Si tienen preguntas, con gusto las respondo.
    • La primera pregunta es si en el PDS de tngl.sh se puede cambiar el handle o eliminar la cuenta. La segunda es qué recursos se necesitan para crear y operar un AppView nuevo; por ejemplo, si se hace un AppView basado en PDS que simplemente sube una carpeta de sitio web estático y la sirve tal cual, como Cloudflare Pages, ¿el operador del AppView tendría que asumir por completo el costo de tráfico masivo? Quisiera entender cómo sería la carga operativa en una estructura así.
    • Tangled usó la expresión “social-enabled”, que parece relacionada con el protocolo AT. Me da curiosidad si Tangled planea incorporar más funciones sociales en el futuro, o si solo significa que tiene soporte para el protocolo AT.
  • Este proyecto me parece realmente genial. Me gusta el intento de desmontar la estructura monopólica de los servicios de code forge existentes. Lo que me atrae de este tema es que siento que los code forge terminan siendo ineficientes por tratar de resolver demasiados problemas a la vez. La mayoría junta en un solo lugar repositorios git, visor web, herramientas de colaboración, pipelines de CI/CD, gestión de trabajo y más. Pero creo que esas funciones no necesariamente tienen que venir unidas. Por ejemplo, si no hace falta acceso directo al repositorio git, se podría ofrecer un visor web completamente estático como https://pgit.pico.sh, o bien la colaboración podría vivir en un servidor aparte para dividir parches, revisarlos y gestionarlos localmente (https://pr.pico.sh). Incluso subir solo un repositorio bare git a un VPS ya es suficiente, y eso es muy fácil. Git ya es un sistema distribuido, así que centralizarlo por culpa de servicios adicionales me parece un antipatrón.
    • La gente suele decir “Git ya es distribuido”, pero en la práctica la idea de distribución tiene sus zonas grises. Más que enfocarse en la distribución, Git normalmente se basa en protocolos tipo maestro-esclavo (como HTTP), así que al final tiende a repetirse la centralización.
    • Cuando hay varios servicios aparece el problema de la confianza. Hay que pensar si conviene auditar un solo servicio que cubra el 80% de las necesidades, o verificar 10 servicios separados. Además, no se pueden ignorar las economías de escala de la infraestructura y las ventajas de integrar varias funciones. Por eso todavía mucha gente prefiere un monolito. Al final, esto obliga a pensar en el trade-off de la experiencia de desarrollador.
    • Configurar un repositorio remoto de git en un VPS es realmente fácil; con acceso por ssh ya funciona. En realidad, creo que el tema central es el lock-in (dependencia del servicio). ¿Por qué GitHub y otros se enfocan más en el lock-in que en el servicio en sí? Detrás de eso están el financiamiento y el modelo de negocio. Ese ciclo de centralización → lock-in → ingresos aparece una y otra vez en muchos servicios. Si no existe una estructura en la que el servicio por sí mismo genere ganancias, da la sensación de que este fenómeno es inevitable.
    • Técnicamente no es imposible separar las funciones, pero también están los problemas de economía (que cada función no tenga una estructura de ingresos suficiente para mantenerse por separado) y de usabilidad (la gente quiere la comodidad de algo con “batteries included”). En el open source pasa lo mismo: muchas veces se ignora la sostenibilidad económica, pero al final la mayoría de los proyectos desaparece cuando se agota la energía de una sola persona mantenedora. Incluso los proyectos open source más exitosos suelen sostenerse con patrocinio corporativo o con apoyo de ingenieros.
    • No es que haya que separarlo todo, pero igual cuando está integrado es mucho más cómodo.
  • Me enteré del soporte reciente para Jujutsu en JJ Con. Se puede ver más al respecto en https://blog.tangled.org/stacking.
    • Este servicio sí soporta stacked PRs de verdad. GitHub no ha podido hacer esto en décadas. Si hubiera que usarlo de forma privada dentro de una empresa, sí me deja un poco insatisfecho que no esté claro cómo configurar una instancia de Tangled para que no se conecte a redes externas.
  • Ya no creo que se pueda confiar en GitHub. Aunque sea solo para el stack OSS, moverlo al protocolo AT u otra red abierta me parece una buena forma de protegerse contra riesgos de grandes corporaciones, censura y demás. Me alegra ver intentos así.
    • Pero la mayoría de la gente no quiere operar su propio servidor. Probablemente solo organizaciones grandes de OSS podrían asumir eso. Incluso fuera del correo electrónico, sería difícil ofrecer PRs.
  • Fui una de las primeras 100 personas en registrarse en tangled. Me impresionaron el roadmap de revisión de PRs con stacked patches y la velocidad de mejora de funciones, y también sentí una energía positiva en la comunidad. Tengo muchas ganas de ver cómo evoluciona. Si sigue avanzando de esta manera, creo que puede lograr una experiencia mucho mejor, más control de fondo y sostenibilidad a largo plazo.
  • Me interesa mucho una forma más distribuida de colaboración con git. Tengo curiosidad por saber cuál consideran que es el mayor obstáculo para que esto se difunda: operar servidores, gestionar llaves privadas, o al final simplemente los efectos de red.
    • La barrera más grande son el spam, el contenido ilegal y los problemas generales de moderación. Como un PDS puede ser cualquier dominio y un solo PDS puede alojar usuarios ilimitados, hay muchas experiencias donde la confianza se rompe. Si la gente empieza a subir montones de ebooks o series de TV a repos git, ¿qué se hace? O si un proyecto recibe ataques de spam por temas políticos, también hay que pensar cómo resolverlo. Lo bueno del concepto de AppView es que, como en BlueSky, un equipo central de moderación puede aplicar políticas consistentes. Cada quien podrá subir lo que quiera, pero al final en el frontend se puede hacer curación selectiva. Aun así, las decisiones centralizadas de moderación siempre son polémicas. Esa es una razón por la que no quisiera asumir toda la carga y responsabilidad de una red completamente distribuida. La apertura del protocolo AT es una ventaja frente a servicios como Twitter, pero a cambio también hace falta un sistema donde la gestión diaria y la autorización estén más concentradas. Personalmente, en este momento me pregunto si habrá alguien dispuesto a ofrecerse como operador de un radicle seed node “generoso” (que permita subidas anónimas de git).
    • GitHub es gratis, y la descentralización cuesta.
    • Estoy muy satisfecho con que Tangled permita usar git de forma independiente sin tener que operar un servidor propio. La mayor desventaja es que todavía es un servicio demasiado nuevo. Aún no tiene reconocimiento masivo y mucha gente ni siquiera sabe qué ofrecen Bsky y PDS. Me gustaría que hubiera más funciones y más alternate clients. Aun así, creo que quienes lo usan temprano ya están teniendo una experiencia bastante buena. Estoy esperando el día en que más desarrolladores puedan conocer esta experiencia.
  • Me alegró ver soporte para pipelines de CI, pero me decepciona un poco que se parezca a GitHub Actions. No creo que haga falta describir una ejecución secuencial simple en YAML; con un script de bash basta. El YAML de pipelines tiene sentido cuando expresa dependencias (DAG), no el flujo de un programa. En ese sentido, Buildkite es mucho mejor.
  • Mañana saldrá una plataforma empresarial no-code llamada “Spaghetti”, junto con un importante servicio de bóveda para guardar datos llamado “Lock-in”.
  • En la empresa, por obligación, tenemos que usar una org pública de GitHub. Me pregunto si se podría hacer el code review (CR) en tangled y después sincronizar con GitHub, manteniendo la misma experiencia de revisión con la herramienta jj.
  • Me pregunto si se puede adoptar Tangled para uso enterprise/privado. El flujo de revisión de stacked diffs parece encajar muy bien con el trabajo en empresas.
    • Sí hay posibilidad. Se está discutiendo una versión de Tangled completamente airgapped y separada de AT. Es un trabajo bastante grande, así que no parece algo que pueda avanzarse de inmediato.
    • Por ahora no existe claramente una solución empresarial aparte. La discusión del issue relacionado puede verse en https://tangled.org/@tangled.org/core/issues/60.