Salir de fedify: las cosas buenas de fedify que entendí al dejarlo

(Es un artículo de mi blog. El texto principal lo escribí con la ayuda de Shiro, el asistente de IA que trabaja conmigo; si encuentran alguna mala interpretación, les agradeceré que me la señalen)

El pequeño servidor del fediverso (una red social interconectada entre servidores, como Mastodon) sukhi-fedi dejó de usar fedify (una biblioteca que corría en un worker de Bun), que se encargaba de ensamblar JSON-LD (el trabajo de dar a los mensajes un formato que los servidores puedan entender entre sí) y de las firmas HTTP (el procedimiento de firma para verificar que un mensaje sea auténtico), y lo reimplementó todo directamente en Elixir. No es un texto para hablar mal de fedify; de hecho, la mitad trata sobre “las cosas buenas de fedify que entendí al dejarlo”.

• Desde el principio no usaban las funciones de framework de fedify (createFederation, inbox listener, dispatcher, etc. — herramientas de nivel superior que manejan por sí solas toda la federación); solo tomaban prestadas las piezas más básicas:

  • clases vocab
  • toJsonLd/fromJsonLd (convertidores que transforman el formato de los mensajes)
  • signRequest/verifyRequest, que entienden tanto el esquema de firma draft-cavage como RFC 9421
  • firmas LD, document loader
  • entrada/salida de claves/JWK (el formato estándar para contener claves públicas)

• Hubo tres razones para dejarlo:

  1. En el momento en que decidieron no usar el framework, ya tenían que encargarse por su cuenta de todo lo que fedify resolvía gratis (responder con Accept a Follow, idempotencia —un mecanismo para que, aunque llegue la misma solicitud varias veces, el resultado se aplique solo una vez—, authorized fetch, instance actor). Lo único que quedaba eran componentes básicos, así que el volumen a migrar ya estaba acotado.
  2. El objetivo era un servidor pequeño con 512~768 MB de memoria, pero en las pruebas de resistencia Elixir completó de forma estable con 130 MB, mientras que solo el worker de Bun tuvo un OOM a los 120 MB (murió por falta de memoria). La única parte del sistema que corría en otro lenguaje era la más pesada y la más frágil.
  3. La frontera entre lenguajes y procesos era en sí misma una fuente de problemas. Conservar los datos originales necesarios para verificar firmas, restaurar direcciones alteradas por el túnel, empaquetar como JWK las claves guardadas en la base de datos para moverlas a otro proceso… no era culpa de fedify, pero sí un trabajo de plomería que no dejaba de crecer.

• El reemplazo se completó con 12 archivos y unas 2,100 líneas. La estructura de la cola de mensajes se dejó igual, se incorporó al mismo grupo y la transición fue simplemente “detener el contenedor de Bun”.

• La red de seguridad la tendió, precisamente, fedify. Las firmas Ed25519 y la normalización URDNA2015 (una regla para ordenar siempre los documentos de la misma manera) producen siempre el mismo resultado si la entrada es la misma, así que pudieron generar por adelantado los “datos correctos” con el código real de fedify y verificar que el resultado migrado a Elixir coincidiera letra por letra.

• El worker de Bun se retiró, pero no se eliminó. Sigue ahí en el entorno de desarrollo para generar datos correctos.

• El equipo de fedify está creando DrFed (https://drfed.org/), una herramienta de depuración para ActivityPub. Incluirá funciones de diagnóstico para identificar en qué etapa de la federación se rompió algo (DNS/TLS/HTTP/firma/JSON-LD), además de un depurador para seguir paso a paso los dos esquemas de firma (con apoyo de NLnet NGI0, código abierto bajo AGPL-3.0, actualmente en desarrollo).

• En conclusión: también es una forma de decir que, si vas a usar el framework completo en TypeScript/JavaScript, fedify sigue siendo la mejor opción. La función ActivityPub de Ghost, hackers.pub y Hollo funcionan sobre él.