Se necesita una federación de forjas

• La colaboración en código abierto parte de la idea de que, en vez de una estructura que dependa fuertemente de un solo proveedor, es más deseable una combinación de protocolos distribuidos que repartan la transmisión de código y la comunicación
• La colaboración en código originalmente se hacía con la combinación de git y correo electrónico; después pasó a la combinación de git y el sitio web de GitHub; ForgeFed continúa con la combinación de git y ActivityPub, y Tangled con la de git y el protocolo AT
• Tangled tiene una estructura que federa eventos entre servidores git, llama knot a cada servidor y, aunque los servidores sean distintos, permite colaborar en repositorios, hacer forks entre servidores y abrir pull requests hacia repositorios ubicados en otros servidores
• Para el Authenticated Transfer alrededor del código usa AT, manejando en conjunto issues, pull requests, la línea de tiempo de eventos, follows y stars, y también lo aprovecha para invitar colaboradores y compartir claves públicas SSH
• Aunque se parece al flujo de operar directamente una instancia de cgit y enviar parches por correo, también deja ver una dirección que busca salir del monocultivo de GitHub sin perder el aspecto social ni la diversión de colaborar

---

Por qué hace falta una federación de forjas

• No es deseable que una parte importante de la colaboración en código abierto dependa de un solo proveedor, y el planteamiento parte de la idea de que los protocolos distribuidos sobreviven más que los sistemas centralizados
• La colaboración de código siempre ha usado dos protocolos al mismo tiempo: uno para la transferencia de código y otro para la comunicación
  • Al principio, el flujo era una combinación de git y correo electrónico
  • Después cambió a una combinación de git y el sitio web de GitHub
  • ForgeFed plantea la posibilidad de una combinación de git y ActivityPub
  • Tangled se está construyendo con una combinación de git y el protocolo AT
• Tangled federa eventos entre servidores git y llama knot a cada servidor
  • Se puede colaborar en repositorios sin importar en qué servidor estén
  • Admite forks entre servidores
  • Después de hacer push a un repositorio en tu propio servidor, puedes abrir un pull request hacia un repositorio alojado en un servidor completamente distinto
• Este enfoque se parece en varios aspectos al flujo de operar directamente una instancia de cgit y enviar parches por correo electrónico

Qué papel cumple Tangled

• Tangled usa AT para el Authenticated Transfer de los eventos alrededor del código
  • Se usa para transmitir eventos como issues y pull requests
  • También maneja funciones sociales como la línea de tiempo de eventos, follows y stars
  • También se agregarán pronto los vouches
• AT también se usa para invitar colaboradores y compartir claves públicas SSH, mientras que el resto sigue usando git tal como está
• El código abierto necesita salir del monocultivo de GitHub y, al mismo tiempo, mantener el carácter social y divertido de la colaboración en código
• tangled alpha
• docs
• source
• discord
• bluesky
• twitter (x)
• feed

[GN⁺]

Comentarios en Hacker News

• No tengo muy claro cuánto mejor sería esto que Mastodon

  • ATproto no funciona como una estructura donde varios servidores se mandan mensajes entre sí, sino que se parece más a RSS
    Hay una capa de hosting independiente de la app y cualquiera puede alojar sus propios datos, mientras que las apps agregan y muestran los datos de todos los hosts
    Por eso ni siquiera existe el concepto de defederation al estilo Mastodon
    Si quieres profundizar, puedes ver https://overreacted.io/open-social/ y https://overreacted.io/a-social-filesystem/
  • ATproto se federa de una forma bastante distinta a Mastodon y aquí no existe el concepto de instance
    Las cuentas se alojan en un PDS y el registro también va ahí, pero lo que ves en la app lo entrega un AppView que reúne datos de varios PDS
    Así que, sin importar en qué PDS estés, la experiencia en la app se siente como un servicio centralizado, y también puede haber varios AppView o incluso puedes alojar uno tú mismo
  • AppView es bastante diferente del fediverso y depende de un shared relay más que de una federación explícita
    Sí me hace pensar un poco el costo de tener una descubribilidad prácticamente global como ahora, pero aun así cuesta verlo simplemente como otro Mastodon
  • No entiendo por qué hay que tomar partido o elegir el lado correcto
    También puedes no alinearte con ninguno, o irte por el que tú creas que tiene razón
  • Lo exageré un poco, pero aun si fuera así, me sigue pareciendo mucho mejor que una estructura donde solo puedes tener visibilidad si dependes de GitHub y GitLab como ahora

• Puede que esté sesgado porque uso bastante activamente el lado de atprotocol, pero de verdad estoy muy satisfecho con Tangled
  Es lo más cercano a la alternativa a GitHub que yo quería, y aunque tiene funciones más simples, durante el último año fue mi servicio social/git principal para proyectos personales de código abierto
  Mi cuenta es https://tangled.org/did:plc:rnpkyqnmsw4ipey6eotbdnnf
  Me gusta que continúa el grafo social que ya conocía en Bluesky, así que puedo relacionar de forma intuitiva a las personas detrás de commits, PR e issues, y además iniciar sesión es cómodo porque funciona igual que otros servicios de atproto
  Últimamente también añadieron soporte integrado para sitios estáticos, así que está muy bien para alojar directamente desde el repo un sitio web del lado del cliente o un index.html simple
  Spindles cumple el papel de sistema de build/acciones, y aunque no soy fan de Nix, para lo que necesitaba me funcionó bastante bien
  La open API también está muy buena, así que pude hacer fácilmente representaciones de información usando estándares basados en atproto, crear bots y agregar algunas funciones a npmx.dev
  Puedes operar tú mismo un knot (servidor git) y un runner (Spindles), o usar los alojados, pero lo importante es que la parte social está desacoplada, así que aunque el servidor git esté aparte, las conversaciones de issues y PR siguen en una capa social compartida
  No es perfecto, y el rótulo alpha en la barra de navegación no está ahí por nada, pero es muy probable que lo siga usando para trabajo de código abierto

  • Sí me preocupa un poco que atproto termine arrastrado por la falta de peso propio de Bluesky
    Todavía no sé bien si ese temor está justificado

• El tono de los comentarios es bastante negativo, pero aunque yo también desconfío del capital de VC, creo que hay que fomentar la competencia en este espacio
  A estas alturas, arrancar algo así con bootstrap parece muy difícil o prácticamente imposible, y sí, también es cierto que salió muy bien sincronizado con los posts críticos con GitHub que estaban ayer arriba en HN, pero aun así quiero apoyar este tipo de intentos
  Ojalá logre establecerse a una escala significativa

  • A mí no me parece simple negatividad, sino una preocupación real
    Solo con el título me había entusiasmado, pero en cuanto supe que había financiamiento de VC, salió inmediatamente de mi lista de opciones
    Si voy a poner mi proyecto querido, que ni siquiera me da dinero, en una plataforma, prefiero elegir una donde la probabilidad de un rug pull dentro de unos 5 años sea baja
    Un proyecto de VC tiene que devolver la inversión, así que creo que tarde o temprano el rug pull llegará de una forma u otra
    Por eso, por ahora prefiero usar servicios como cliente de pago, o servicios tipo cooperativa donde pago una cuota y tengo voto en las decisiones
  • Los proyectos con VC tienden a terminar en rug pull, publicidad, invasión de privacidad o empujar funciones de pago de forma forzada
    Por eso, como usuario, uno debería conocer esa posibilidad desde el principio
    No me gustan mucho los servicios que venden idealismo excesivo cuando esa es la realidad que se viene
    Preferiría que cobraran por el servicio, o si de verdad persiguen el ideal, que empiecen como non-profit, o al menos que dejen muy claro su plan de monetización
  • No entiendo bien por qué se dice que bootstrap es imposible
    Que sea difícil, claro, pero si además apunta a federation, ¿no debería poder construirse con una infraestructura más barata, en vez de costar lo mismo o más?

• Si te da curiosidad el modelo de datos de atproto, escribí una introducción en https://overreacted.io/a-social-filesystem/
  Es algo larga, pero ayuda bastante a ver con claridad el panorama completo

  • De hecho te estás quedando corto
    Fue la mejor introducción a ATProto que he visto hasta ahora
    Me pregunto si tienes algún tag o lista donde estén reunidos esos textos

• Yo diría que lo que hace falta no es forge federation, sino un git repo más rico en sí mismo
  Fossil ya está como al 90% de eso, integrando tickets, foro y wiki como parte del repositorio, y cuando clonas también descargas todo eso y puedes verlo sin conexión
  Incluso en un avión puedes dejar escrita una respuesta, y si tienes los permisos adecuados puedes sincronizarla de inmediato o después cuando vuelva la conexión
  Aun así, en vez de dejar ciertos tipos de artefactos hardcodeados en el VCS, me parecería mejor meter apps dentro del repo y que esas apps decidan qué artefactos permiten, qué reglas siguen y quién puede subir o bajar qué cosa y cuándo
  El forge solo tendría que ejecutar esa política y renderizarla como quiera para los usuarios web
  Así, mudarse a otro forge terminaría siendo básicamente solo hacer push del repo

  • Muchas gracias por esto
    Últimamente estaba haciendo cosas como sistemas de tickets o agentes con flat files dentro de repos git, y ahora me está dando la idea de extender eso hasta la gestión misma del repo
    Suena buenísimo

• El principal problema que yo veo con una federated solution es al final el cold start
  Si entras a un servidor grande, vuelves a abrazar justo el problema de centralización del que querías escapar, pero al menos obtienes una red grande desde el principio
  En cambio, si montas tu propio servidor, tu red es 0, tu descubribilidad es 0, tu feed está vacío y además tienes que convencer a otros sitios de federarse contigo o de no bloquearte por ser un servidor de una sola persona
  No sé si solo lo siento yo, o si entendí mal federation
  Tal vez esto simplemente sea un problema específico de Mastodon

  • Por eso parece que Tangled eligió ATproto en lugar de ActivityPub
    Está diseñado para que AppView centrales reúnan los servidores individuales y den una vista única y consistente, como si fuera una red centralizada
    Cualquiera puede alojar un AppView
  • Esto se parece más al lado de Mastodon
    En atproto, cada servidor no funciona como una zona medio aislada
    La explicación desde la perspectiva de sistemas distribuidos está muy bien en https://atproto.com/articles/atproto-for-distsys-engineers
  • Creo que la ventaja está en el punto medio
    Si un servidor grande se vuelve sospechoso por moderación, políticas, contenido o problemas técnicos, es relativamente fácil salir y hacer crecer o mudarte a otro servidor también bastante grande
    Eso significa que desde el principio puedes tener un refugio con cierta reputación y escala
    Ya existen forges alternativos como GitLab, Codeberg, freedesktop, Fedora o Debian, así que mientras se mantengan la visibilidad y la descubribilidad del proyecto, pueden ser refugios suficientemente seguros
  • Hasta ahora yo también lo había sentido exactamente así y por eso evitaba los servicios federados
    Pero hace unos días vi este proyecto y pensé que este sí podría funcionar de verdad
    Porque el público objetivo se superpone bastante con la gente acostumbrada al self-hosting
    No necesito que toda mi red esté ahí; con que esté ese subconjunto que realmente es probable que use esto, ya me resulta suficientemente útil
  • Lo atractivo aquí es que puedes hacer self-host y también hacer migration entre proveedores grandes
    El costo de un servidor frontend será bajísimo, así que parece posible operarlo casi para siempre, y los datos reales los suministran otros hosts

• El hecho de que Tangled tenga respaldo de VC me suena más a presión de tener que crecer sí o sí que a estabilidad
  No le veo mucho el atractivo
  Incluso si es federado, si el desarrollo se detiene, me pregunto quién va a corregir bugs y mantenerlo

  • Tangled se desarrolla completamente en público en https://tangled.org/tangled.org/core y su objetivo es permanent software
    Es decir, quieren que todo sea completamente reproducible y que pueda self-hostearse entero con costo mínimo
    El financiamiento de VC no es el objetivo, sino un medio, y según cuentan los dos fundadores indios en Europa, conseguir subsidios era poco realista porque tardaban de 4 a 12 meses o más en concretarse
    VC fue la forma más rápida de armar el equipo, montar la infraestructura y acelerar el desarrollo, y dicen que se tomaron más de 6 meses para encontrar inversionistas muy alineados con sus metas
  • La gente que lo use puede mantenerlo
    Tangled tiene varias decisiones estructurales interesantes, pero el código en sí es relativamente simple y, por lo que pude ver, no parece difícil de mantener
    La mayor parte son Go modules débilmente acoplados, más HTML+CSS estático, un poco de TypeScript y Nix para la orquestación
    Si no recuerdo mal, los requisitos de hardware también son muy bajos, así que a esta escala una sola persona podría alojarlo por su cuenta
    De hecho, una gran parte de la carga real de infraestructura la llevan los knots, spindles, PDS de los usuarios y el ecosistema atproto en general
  • Incluso este comentario lo estás escribiendo en un sitio agregador de noticias financiado con VC, así que no sé si conviene afirmarlo tan categóricamente
  • No tengo problema con VC, siempre que no sea dinero de YC
  • Cuando entra VC en algo así, me hago dos preguntas
    ¿por qué hace falta VC sí o sí?, ¿por qué no patrocinio corporativo como Ladybird?
    Y si los inversionistas esperan un retorno de 10x, ¿por qué debería invertir tiempo en una herramienta para desarrolladores que al final va a terminar en enshittification?

• Me acordé del chiste de que hay 4 estándares y, para unificarlos en uno, se crea otro estándar, así que al final hay 5 estándares
  Bromas aparte, creo que hace falta una justificación más fuerte de por qué ActivityPub no basta
  Antes de volver a resolver el problema de la comunicación descentralizada de otra manera

  • ActivityPub y atproto tienen formas muy distintas
    Compararlos así es como preguntar para qué hace falta la web si ya existe el correo electrónico
    ActivityPub, como el email, funciona con servidores que hacen de bandeja de entrada y se envían mensajes entre sí
    En cambio, atproto, como la web, hace que los repositorios del usuario alojen los datos y que las apps los reúnan y los muestren
    Esa diferencia de topología cambia también sus propiedades: en atproto puedes cambiar el hosting del usuario sin romper la experiencia de la app, y cualquiera puede crear nuevas apps a partir de los datos existentes
    ActivityPub no permite eso, y al final se parece más a pequeños servicios centralizados acoplados entre sí, donde hosting y app vienen juntos y se mandan mensajes entre ellos
  • También creo que hay que mirar por qué Tangled pudo lanzar un producto sobre ATProto incluso antes de recaudar fondos, mientras que ForgeFed lleva años avanzando con mucha más lentitud
  • Está enlazado en el texto original, pero los autores de ForgeFed explican directamente por qué ActivityPub no encaja bien para este problema en https://forgefed.org/blog/actor-programming/

• También existe https://gitworkshop.dev/ como alternativa a GitHub relativamente madura sobre Nostr
  La idea central es que puedes subir repositorios a varios relays nostr compatibles con GRASP, y aunque un servidor se caiga, se sincroniza de forma transparente por otros lados
  Así que, si eliges servidores confiables, en la práctica se acerca mucho a un 100% de disponibilidad, y tanto los repositorios como la actividad y los issues están firmados criptográficamente

  • No se ve tan maduro
    Desde el nombre ya parece violar la política de marcas de git
    https://git-scm.com/about/trademark
  • Ojalá me equivoque, pero ese proyecto parece closed source
  • No pude abrir correctamente ningún repositorio en ese sitio
    En algunos casos el navegador decía que no soportaba URL ssh o https, y en otros solo aparecía Failed to load file tree con carga infinita
    Así que me cuesta aceptar mucho la descripción de fairly mature

• Yo apoyo con fuerza la federation, pero nunca he terminado de entender bien para qué serviría una federation of forges
  ¿Qué datos exactamente tendrían que intercambiar los forges entre sí?
  ¿Por qué un forge para Blender tendría que conectarse con uno para Ubuntu?
  El mayor valor que obtengo de GitHub es el single sign-on para moverme entre proyectos, y creo que incluso los forges independientes podrían ofrecer buena parte de ese valor solo con social login, sin necesitar una federación compleja entre forges

  • Cuando la gente busca software, al final empieza por la búsqueda en GitHub
    Si alojas tu propio forge, a menos que seas un nombre ya grande como Blender, nadie va a encontrar tu software
    Por eso casi te ves obligado a hacer al menos mirroring en GitHub, para que tu código no se pierda en el vacío
    Si se quiere evitar eso y hacer que forges más pequeños compitan como un conjunto, se necesita una red única donde el software pueda encontrarse sin importar en qué host esté, y eso es precisamente lo que busca ForgeFed
    También reduce la fricción de exigir un login específico de cada forge a quienes recién quieren contribuir, aunque eso es secundario y a la vez está relacionado
  • Git es descentralizado por diseño
    GitHub solo resolvió muy bien la UI, los issues y los PR para que incluso principiantes pudieran trabajar desde una pantalla, y en ese proceso centralizó todo
    La federation está más cerca de la filosofía de Git, pero eso no significa que haya que irse al extremo de una distribución tan radical que si un nodo se cae, el upstream desaparezca o ni siquiera pueda encontrarse
    Git no resuelve la disponibilidad, y federation puede complementarla manteniendo la filosofía descentralizada
  • El mayor problema sigue siendo la discoverability
    Hace falta una forma sencilla de encontrar proyectos de código abierto repartidos en distintos servidores
    La búsqueda de proyectos en GitHub solo sirve dentro de GitHub
  • Un identity provider interoperable sin duda sería útil
    Y además ayudaría a que todo fuera más resilient cuando el host del proyecto desaparece, cambia sus políticas o queda bloqueado por un gobierno
  • La ventaja aquí es que los datos viven en un solo lugar, el PDS, y si quieres puedes self-hostearlo
    Luego AppView reúne en una sola pantalla los datos de múltiples PDS
    Si tangled.org termina enshittificándose, puedes seguir exactamente igual desde cualquier otro AppView, porque tangled.org no ocupa una posición privilegiada
    El social login de forges independientes ayuda, pero personalmente prefiero tener una sola cuenta que administrar, y gracias al AT protocol, aunque un forge individual desaparezca, los datos siguen accesibles desde otro AppView