Un problema común que enfrentan muchos usuarios de Discourse es la imposibilidad de mostrar una agregación de todos los grupos de interés a los que están suscritos. No existe una forma sencilla de consumir contenido de múltiples instancias de Discourse en forma de un feed de usuario centralizado y social. Plataformas centralizadas como Reddit lo resuelven mediante un único inicio de sesión para todas las comunidades y un feed agregado de todas ellas mostrado en una sola secuencia en la página de inicio de reddit.com. Esta última característica es la que nos gustaría replicar en Discourse mediante el protocolo ActivityPub.
Por ejemplo, la Persona A frecuenta múltiples instancias de Discourse: una para política, dos para pasatiempos, una para su foro de barrio local, pero no tiene forma de consumir todo el contenido relevante en un solo feed. En comparación, si te has unido a varios grupos de Facebook o subreddits de Reddit, las publicaciones más relevantes ya aparecen en tu feed.
Especificación (v1)
Podríamos prototipar un MVP habilitando las siguientes características a través de un plugin de Discourse:
Generar un feed de ActivityPub bajo demanda (para cada página que ya tenga un feed RSS)
Similar a añadir .rss a la URL, esto permitirá la obtención de contenido usando el protocolo AP al solicitar el endpoint correcto.
Incluso podríamos habilitar esto para contenido privado añadiendo claves de API de usuario a la URL.
Permitir que los administradores del foro habiliten ActivityPub (saliente) por categoría o mantenerlo activado por defecto. (Creo que @Falco tenía algunas ideas al respecto)
Encontrar una forma de consumir este contenido en un foro de Discourse o en un feed de Mastodon (entrante)
Próximos pasos
Definitivamente necesitamos empezar en pequeño, así que al principio debemos decidir un conjunto pequeño y viable de características que se incluirán en la primera iteración. He estado revisando el protocolo ActivityPub, pero aún no estoy muy familiarizado con su funcionamiento interno. Por lo tanto, invito a otros que han mostrado mucho interés en esto a unirse a la discusión (@Falco, @hellekin, @merefield) para ayudarnos a construir una especificación viable para la primera iteración y recomendar cambios para la especificación anterior.
Comenzaría diciendo: ¿no deberíamos centrarnos inicialmente en el qué y no en el cómo? ¿La arquitectura técnica viene después? La razón por la que lo digo es que podría limitar la funcionalidad si se elige demasiado pronto.
Me encantaría ver para la Versión 1. listas de ‘Descubrimiento de descubrimientos’, comenzando con:
Una lista ‘Recientes’ que mostrara una vista previa de cada tema reciente de las fuentes incluidas (una unión simple de Recientes de todas las fuentes).
Una lista ‘Vigilados’, que mostrara una vista previa de cada tema con actividad de la que has seleccionado ser notificado. (esto toma su precedente de la aplicación móvil existente: está expandiendo las notificaciones de nueva actividad en temas vigilados hacia las propias vistas previas de los temas subyacentes).
Debo decir que la propuesta original que involucra la analogía de Facebook me resulta incomprensible: no tengo ni idea de qué hace Facebook, y no entiendo cómo se relaciona en absoluto con Discourse.
Mi comprensión de la compatibilidad con ActivityPub para Discourse es que podría ayudar a federar temas o incluso compartir una categoría entre instancias de Discourse. Por ejemplo, un tema de anuncios en discourse.joinmastodon.org podría federarse en socialhub.activitypub.rocks en la categoría relacionada #software:mastodon: allí, los usuarios locales podrían dar “me gusta”, responder, citar, etc., como si fuera un tema local, excepto que el tema original viviría en la instancia de joinmastodon.
Otro aspecto es que, si alguien tiene una cuenta en ambas instancias, debería haber una forma de vincular esas cuentas, es decir, usar una instancia específica de Discourse como proveedor principal de identidad. Entiendo que esto no es el foco de una primera iteración, pero es bueno tenerlo en cuenta, ya que podríamos terminar teniendo “iniciar sesión con [inserta aquí tu implementación favorita de ActivityPub]”.
Lo que entiendo de las propuestas anteriores es una réplica de la aplicación de Discourse en Android, donde tienes una lista de instancias y recibes notificaciones de todas ellas. Parece un poco peligroso entrelazar respuestas no relacionadas de muchas fuentes, especialmente cuando pierden el contexto.
¿He entendido correctamente? ¿Y sería mi comprensión un buen segundo paso para tu visión de integrar ActivityPub con Discourse?
Todas las implementaciones actuales de ActivityPub esperan que las publicaciones sean emitidas por Actores estables, por lo que podría necesitar una de las siguientes opciones:
Una cuenta del sistema que publique todas las entradas
Una cuenta por feed suscribible
Una cuenta por feed suscribible, que realice Announce de las entradas que supuestamente fueron escritas por una cuenta por usuario de Discourse
La primera opción es probablemente la más sencilla de implementar; la tercera hace el mejor trabajo al integrar los modelos de datos.
También está la decisión de si queremos publicar el contenido completo del tema, solo las primeras publicaciones de los temas, o algo similar a los feeds de Twitter de StackExchange donde se hacen publicaciones distintas promocionando entradas desde la página /top. O eso podría ser simplemente cómo funciona el feed de “mejores publicaciones”, y los otros feeds publican todo…
A nivel técnico, la URL no debería necesitar cambiar: todos los servidores enviarán Accept: application/activity+json o sus alternativas.
Una aplicación lectora que mezcle feeds de diferentes fuentes en distintos momentos en ActivityPub —recreando la “línea de tiempo algorítmica” como algo optativo— es algo que he deseado por un tiempo, y no parece existir hoy en día.
@hellekin: Creo que la autoría entre dominios tiene una alta probabilidad de burlar fatalmente muchas de las protecciones anti-spam que tiene Discourse. La lectura es más importante de implementar: después de todo, la lectura es fundamental!
No lo creo: los usuarios remotos aún podrían ser escalonados, a menos que vinculen su cuenta remota con una local, en cuyo caso las medidas antispam se aplicarían a esa cuenta.
Debo confesar que solo eché un vistazo rápido a los comentarios. Sugiero que cada categoría sea un actor independiente (con el tipo “Group”). Así, personas de fuera podrán suscribirse fácilmente a categorías específicas. Las publicaciones en estas categorías podrían implementarse anunciando las publicaciones del usuario a través de la cuenta del “Group”. De este modo, tendríamos tanto la categoría como el autor. Esta es la forma en que lo hacemos con nuestro propio software. Al usar firmas JSON-LD, esto sería seguro incluso para categorías no públicas.
La pregunta es qué hacer con los comentarios de personas de fuera. Sugiero que las cuentas de grupo se definan como de “aprobación manual”. Luego, se podría añadir un proceso de validación para evitar spam aleatorio. Estas cuentas validadas deberían poder comentar en estas publicaciones.
Esto permitiría de inmediato que personas de (casi) todo el fediverso se conecten e interactúen con sistemas de Discourse.
Cada grupo de categorías pueda tener un propietario con la autoridad para gestionar la categoría: controlar los permisos de publicación, prohibir o eliminar usuarios, establecer la visibilidad (pública o privada)…
Los usuarios locales puedan crear categorías en su instancia, siempre que el personal de la instancia apruebe dichas creaciones.
Si un propietario de categoría no cumple con su cargo, el personal del sitio pueda cambiarlo.
Así es como funcionan muchos foros y comunidades centralizados. Lo que hay que mejorar es hacerlo federado.
No obstante, aún existen problemas:
¿Deberían ser mutables los id de los actores? Los nombres de usuario de Discourse pueden configurarse como modificables en la configuración del sitio. Sin embargo, dudo que otro software de AP pueda manejar esto. Is Object's `id` immutable? - ActivityPub - SocialHub
(Hay más que mencionar)
¿Viene alguien del equipo de Discourse al SocialHub en OFFDEM la próxima semana? Sería un gran momento para conocer y conectar con otros implementadores de AP.
@heluecht y @misaka4e21 mencionaron el soporte para el actor Group. Hay una discusión en curso en SocialHub sobre formas de implementarlo de manera más o menos estandarizada.
5 Me gusta
sl007
(Sebastian Lasse | @sl007@mastodon.social)
14
¡Felicidades por el dinero de la UE!
¿Hay una hoja de ruta?
¿Alguien del equipo de Discourse irá a la Conferencia de ActivityPub?
Sería un gran momento para conocer y conectar con otros implementadores de AP. https://conf.activitypub.rocks
Esperamos que podamos discutir la implementación de ActivityPub en Discourse durante el Birds of a Feather el próximo domingo en el APConf2020. Consulta el tema dedicado en SocialHub:
@rishabh, sería genial tenerte por aquí, al menos en el tema si no puedes asistir el domingo. Aún no conocemos la hora exacta, pero será por la mañana del domingo. Actualizaré esta publicación cuando lo sepa.
Lo siento, no pude asistir. Te informo de que no solicitamos la financiación de NGI0 y, por ahora, nadie está trabajando en esto. Tampoco soy la persona más indicada para impulsar esto, ya que no estoy familiarizado con el protocolo, pero haré un ping a @Falco para ver si tiene alguna opinión o interés en llevarlo adelante.
Bueno, en ese momento, uno de los miembros de tu equipo sí lo hizo, aunque ya no forme parte del equipo, y ustedes fueron seleccionados. Así que alguien tuvo que aprobarlo, por lo que no sé a qué “nosotros” te refieres. De todos modos, espero con interés discutirlo con @Falco. Algún tipo de soporte para AP sería realmente útil para la comunidad de ActivityPub, especialmente porque facilitaría el trabajo entre instancias de Discourse y mejoraría la integración con el Fediverso.
Soy consciente del problema del spam, pero creo que se puede mitigar con usuarios del Fediverso en entorno de pruebas, como los usuarios de correo electrónico no registrados, hasta que registren realmente una cuenta local.
Sí, solicitamos la financiación en el pasado, pero hablamos con el equipo de NLnet a principios de este año para cerrar el proyecto y liberar la financiación que se había reservado para nosotros. Aunque fuimos seleccionados en ese momento, la colaboración con NGI0 está cancelada por ahora. Por supuesto, somos libres de presentar propuestas en el futuro.
Acabo de recordar que a @riking también podría interesarle
1 me gusta
sl007
(Sebastian Lasse | @sl007@mastodon.social)
20
Interesante.
Este proyecto fue financiado a través del Fondo NGI0 Discovery, un fondo establecido por NLnet con apoyo financiero del programa Next Generation Internet de la Comisión Europea, bajo el amparo de la DG Redes de Comunicaciones, Contenido y Tecnología, según el acuerdo de subvención n.º 825322.
Entonces: ¿están hablando de otro “Discourse”?
Solo pregunto debido a “Sitio web propio del proyecto: https://discourse.org”…
¡Oh, no sabía que esa página existía! Escribiré un correo electrónico a nuestro contacto en NLnet para recordárselo, por si acaso olvidaron eliminarla, y publicaré una actualización aquí.
De todos modos, espero con interés discutirlo con