Implementar ActivityPub, el protocolo que sostiene el fediverso, exige enfrentarse a cinco obstáculos técnicos muy concretos que convierten el desarrollo en un ejercicio de ingeniería de sistemas distribuidos. Hong Minhee, creador del framework Fedify, desgrana esas cinco "escenas" y muestra cómo su herramienta las resuelve.
La primera fricción son las firmas HTTP: no existe un único estándar en uso. La mayoría del fediverso sigue un borrador expirado (draft-cavage-http-signatures-12), mientras el estándar real es RFC 9421; los servidores deben probar ambos, recordar cuál aceptó cada nodo y aplicar el llamado "double-knocking". A ello se suman las firmas sobre el propio documento (Linked Data Signatures y Object Integrity Proofs) y la gestión de claves RSA y Ed25519.
La segunda es el formato JSON-LD: una misma actividad puede llegar con el actor como URI, como objeto inline, con destinatarios en cadena o en matriz, y con tres variantes válidas para la dirección pública. La normalización completa exige un procesador JSON-LD; el código defensivo se extiende por toda la base.
La tercera son los problemas de entrega: mensajes desordenados (un Delete llega antes que el Create y el post "zombi" permanece para siempre), reintentos con backoff exponencial, distinción entre errores 500 y 410 Gone y limpieza de seguidores en servidores caídos. La cuarta es la interoperabilidad de ecosistema: Mastodon requiere authorized fetch y un instance actor que no aparece en la especificación; Threads rechaza actores inline; Lemmy exige campos como attributedTo; Misskey usa extensiones propias. La quinta es la seguridad por defecto: sin verificación de firmas, sin restricciones al document loader y sin comprobaciones de origen, el servidor queda expuesto a SSRF y falsificaciones.
Fedify automatiza firmas, normalización, colas de entrega con reintentos y verificaciones de seguridad, de modo que desarrollar sobre ActivityPub deje de requerir reimplementar todo ese trabajo desde cero.