Hola @rishabh, @riking, @codinghorror,
(Sí, hay un TL;DR más abajo)
Hace algún tiempo, entendí por @sl007 y @hellekin que no continuarán con esta Fase 1 a corto plazo, incluso con la financiación NGI0. Como promotor también de la interoperabilidad basada en ActivityPub, por supuesto, también lo siento. Pero desde la perspectiva de Discourse, el software de foros líder y más popular, hay muchas fuerzas y otras prioridades a tener en cuenta, y esta decisión empresarial, bajo esa luz, probablemente tiene mucho sentido:
Decisión: Este RFC, tal como se propone, simplemente no era lo suficientemente atractivo para recibir prioridad y ser incluido en la Hoja de Ruta.
El RFC adoptó un enfoque MVP con la idea de “Empecemos creando un feed de contenido agregado similar al de Facebook entre foros”, tal como lo propuso @Falco. Es solo una de las muchas, muchas funciones que podrían resultar de tener soporte nativo para ActivityPub de alguna forma u otra. Podría argumentarse que tener tal cronograma es una especie de desvío de lo que normalmente se encuentra en un foro, y a mí no me parece una función central real. Más bien una extensión añadida y, por tanto, algo deseable pero no esencial.
Un enfoque diferente
Una vez superada la necesidad de llegar rápidamente a un MVP de soporte para ActivityPub, quizás podríamos seguir el proceso inverso:
Ideación: Lluvia de ideas sobre casos de uso de interoperabilidad y evaluar su viabilidad en términos de beneficio empresarial y ventajas competitivas únicas (USP).
Es decir, ¿qué funciones serían realmente atractivas de tener en Discourse? O incluso: ¿En qué podría quedarse Discourse fuera si no está al tanto de lo que es posible?
En su última publicación anterior, @Falco menciona a Lemmy, que se construyó desde cero sobre un vocabulario de Datos Enlazados dedicado que coincide con su dominio empresarial. Tienen su MVP listo y en producción, y ahora están explorando la expansión de su conjunto de funciones sobre su propio dominio. Esto podría incluir la federación con el otro dominio de los microblogs, donde Mastodon, Pleroma y otros tienen mucho éxito.
El enfoque para la ideación podría seguir este ejercicio:
Ejercicio: Imaginemos cómo habría sido Discourse si desde el principio se hubiera basado de manera similar en su propio dominio empresarial basado en ActivityPub (definido como un vocabulario de Datos Enlazados).
Dejemos volar la imaginación en esta sesión de lluvia de ideas y permitamos que nuestra creatividad fluya libremente.
La lista de casos de uso que surgen de todo esto podría ser lo suficientemente interesante desde el punto de vista comercial para formar parte de la Hoja de Ruta, pero si no lo es, aún podría inspirar a la comunidad a crear complementos y componentes, y sentar las bases para construir sobre ellos en una etapa posterior.
ActivityPub versus Fediverso
Observo que existe un amplio malentendido sobre lo que significa tener soporte para ActivityPub en una aplicación. Mucha gente piensa que la razón para hacerlo es “formar parte del Fediverso”. Y aquí el pensamiento va inmediatamente a la federación con instancias de Mastodon, es decir, implementar interoperabilidad con (es decir, unirse a) el dominio federado de los microblogs.
Sí, esta es una oportunidad muy atractiva una vez que se tiene soporte para ActivityPub, y muchas otras aplicaciones como PixelFed (alternativa a Instagram), PeerTube (alternativa a YouTube) y también Lemmy (alternativa a Reddit) están buscando hacerlo. Ellos hacen del Fediverso un lugar más atractivo para participar, y muchas innovaciones están tomando forma que hacen que el futuro del Fediverso sea realmente emocionante.
PERO…
Podría argumentarse que organizaciones dirigidas a grandes bases de usuarios como Discourse podrían hacerse preguntas como: “¿Por qué querría integrar el Fediverso con solo unos 4 millones de usuarios?” o “¿Por qué integraría los microblogs en mi software que opera en un dominio completamente diferente?”. Y tendrían razón al afirmarlo, y renunciar a la implementación de ActivityPub bajo esa premisa.
SIN EMBARGO…
Las implementaciones de ActivityPub se tratan de mucho más que formar parte del (parte de microblogs del) Fediverso. Tiene todo el sentido implementar un vocabulario de Datos Enlazados diseñado exclusivamente para su propio dominio empresarial y que sus propias instancias de producto se federen entre sí. O todas las instancias de su producto y las de sus competidores en su industria que también adopten el mismo vocabulario, por cierto.
Un ejemplo de esto es el proyecto ForgeFed que tiene como objetivo definir estándares de interoperabilidad para forjas de código (GitHub, GitLab, Gitea, SourceHut, etc.) que implementen. Hacerlo tiene un sentido tremendo, especialmente para los proyectos de forjas de código más pequeños, para ofrecer una alternativa atractiva a GitHub (que se ha vuelto demasiado dominante como plataforma centralizada y cada vez más cerrada). Si se adopta ampliamente, los desarrolladores ya no tendrán que manejar una plétora de cuentas de forja en servidores dispersos por todo internet para participar en proyectos de código interesantes, presentar un problema, comentar y enviar solicitudes de extracción (PR).
(Tenga en cuenta que, como se indicó anteriormente, el mismo problema que tienen las personas con las forjas de código independientes que existen por todas partes, es lo que yo y otros también experimentamos con nuestra participación en un montón de comunidades de Discourse.)
Oportunidad: Discourse está en una posición única para tomar la iniciativa en el establecimiento de estándares de interoperabilidad para software de foros, y dar forma al estándar de tal manera que se alinee perfectamente con el conjunto de funciones actual de Discourse.
Hay algunos competidores emergentes en su industria que son innovadores, adoptan enfoques frescos e iteran rápidamente para agregar nuevas funciones (ustedes en Discourse saben mejor quiénes son 
). En mi opinión, Discourse en términos de completitud de funciones sigue estando muy por encima de lo que ofrecen sus productos. Y tienen una comunidad como ninguna otra para ayudarles a evolucionar el producto.
Pero la oportunidad de interoperabilidad que existe ahora, también podría convertirse en una amenaza. O bien los competidores podrían aprovechar la oportunidad primero, o, quizás impulsados por la Ley de Mercados Digitales de la UE, las grandes plataformas tecnológicas crearán algo con superposición en el dominio del software de foros. En ambos casos, sería más difícil para Discourse alinearse con este estándar y tener la voz más autorizada en el diseño de su especificación.
TL;DR
Este se ha convertido en una publicación más larga de lo que pretendía. Lo siento 
En resumen, argumento que, dada la postura actual sobre tener soporte para ActivityPub, podría ser prudente pasar de un enfoque a corto plazo tipo MVP a una evaluación más amplia de lo que la interoperabilidad de ActivityPub podría aportar a Discourse en términos de ventajas competitivas únicas (USP) y posicionamiento a largo plazo. Es decir, desarrollar el caso de negocio de la adopción de ActivityPub, comenzando con una fase de ideación.
(Cómo se configura mejor esto, siempre que estén interesados, lo dejo en el aire, pero podría comenzar simplemente con un nuevo tema de AP que tenga un wiki resumen de los casos de uso recopilados en la parte superior y que la gente discuta ideas de casos de uso en el hilo)