Plano de arquitectura ActivityPub de Gitlab
El plano de GitLab para añadir federación basada en ActivityPub a su plataforma está suscitando debate sobre cómo deberían interoperar los forges de software y si esto ayudará a romper los efectos de red centrados hoy en GitHub. Los comentaristas sopesan los beneficios de un modelo abierto y federado —donde incidencias y merge requests pueden circular entre GitLab, Gitea, Forgejo y otros— frente a los flujos de trabajo existentes basados en parches por correo o interfaces web centralizadas. Las preguntas se centran en la alineación con estándares como ForgeFed, la viabilidad de permisos y privacidad entre instancias, y si actores principales como GitHub probablemente adoptarán protocolos similares.
Relación con ForgeFed y los forges existentes
- A algunos les sorprende que el plano de GitLab no mencione ForgeFed, Forgejo, Gitea, etc., que han estado trabajando en federación interoperable.
- Otros señalan una discusión epica de GitLab que indica conocimiento y probable compatibilidad futura con ForgeFed.
- Hay preocupación de que GitLab pueda construir una red centrada en GitLab, pero un comentario enlazado en el epic sugiere que buscan interoperabilidad, no una alternativa propietaria.
- Un apunte: el comentario relacionado con ForgeFed en el epic es de un colaborador de la comunidad, no del personal de GitLab.
Correo + git vs forges web vs ActivityPub
- Un hilo importante debate correo+git (estilo Linux) frente a los forges modernos (GitHub/GitLab/etc.).
- Argumentos a favor de los forges: UX más rica, integración de CI, mejores herramientas de revisión (comentarios en línea, resoluciones), descubrimiento, etiquetas/tags y menos dependencia de convenciones sociales.
- Argumentos a favor del correo: estándar abierto y federado; clientes potentes y personalizables; buena estructura de hilos y discusiones; independencia de cualquier forge único.
- Varias personas dicen que los flujos de trabajo por correo son dolorosos, propensos a errores y escalan mal; otras dicen que el problema se debe sobre todo a clientes malos y falta de herramientas.
- Se cita el flujo de trabajo por correo del kernel de Linux como algo que sufre bajo la escala, y hay referencias a herramientas del kernel (p. ej., lore, b4) que intentan parchear las limitaciones del correo.
ActivityPub frente a “usar simplemente correo/git”
- Algunos desean que las herramientas se hubieran construido sobre correo en vez de inventar una nueva pila de protocolos.
- Otros responden que, una vez que construyes herramientas sofisticadas y capas de metadatos, en efecto ya tienes un protocolo nuevo, así que usar ActivityPub/HTTP es más limpio.
- ActivityPub se ve como una forma de permitir datos estructurados para parches/incidencias, evitando convenciones ad hoc del correo y puentes de correo a medida entre forges.
Descentralización, bloqueo y GitHub
- Muchos están entusiasmados con “un fediverse para el código”: poder abrir incidencias/MRs entre instancias sin cuentas extra.
- Esto se ve como una forma de erosionar el bloqueo por efecto de red de GitHub, permitiendo que los proyectos se muevan sin cerrar la colaboración.
- Persiste el escepticismo sobre que GitHub implemente algún día ActivityPub; la mayoría cree que solo ocurriría bajo fuerte presión competitiva o regulatoria.
Permisos y privacidad
- La federación de recursos privados se describe como un objetivo no buscado en el plano de GitLab.
- Algunos señalan que ActivityPub sí admite solicitudes autenticadas y podría, en principio, manejar permisos entre instancias.
- La privacidad es limitada: no hay cifrado de extremo a extremo; los administradores de las instancias pueden ver los mensajes directos.