Se crea un tema con un enlace en la primera publicación; para empezar, detecta un solo enlace en la primera publicación o una URL pegada en el título.
Opcional: Para evitar spam trivial, espera la primera respuesta o habilita una configuración del sitio.
Sondea la página para ver si WebMention es compatible.
Se envía un comentario de WebMention con el texto “Esta página se está discutiendo en =SITE\ _DOMAIN=: “=TITLE=” =TOPIC\ _LINK= =CATEGORY_AND_TAGS=” (usando el default_locale del sitio).
El sitio recibe el WebMention (delegando potencialmente a fed.brid.gy, aplicando anti-spam, etc.) y finalmente lo muestra como un comentario.
El actor (el “autor” del comentario) tomaría el logotipo del sitio de alta calidad o el avatar de @system, y el nombre corto del foro.
Solo un comentario aparte: no lo mencioné en la publicación, pero el protocolo admite el envío de “me gusta” y republicaciones como ciudadanos de primera clase, al igual que las respuestas; sería bueno que Discourse también implementara eso.
Pavilion presentó una solicitud a NLnet por 40.000 Euros para añadir soporte de federación a Discourse (ver abajo). Fue rechazada y terminamos solicitando (y siendo aceptados) en DAPSI en su lugar.
Una actualización aquí. Pavilion y CDCK (Discourse.org) están discutiendo la creación de un plugin ActivityPub para Discourse. Después de algunas discusiones, hemos llegado a la especificación a continuación. Cualquier comentario o sugerencia es bienvenido antes de finalizarla. Tenga en cuenta que
El soporte para contenido entrante (por ejemplo, publicaciones en Mastodon, etc. que se importan a Discourse) está intencionalmente excluido. Será posible agregar esto en una versión posterior.
El soporte para seguir usuarios (en contraposición a las categorías) también está intencionalmente excluido. También sería posible agregar esto en una versión posterior.
Pavilion creará el plugin MVP (yo trabajaré en él), y CDCK lo poseerá y alojará (es decir, será un plugin de CDCK, no un plugin de Pavilion).
Resumen
Un plugin ActivityPub (AP) para Discourse.
El objetivo del plugin es una implementación MVP de las especificaciones ActivityPub, ActivityVocab y ActivityStreams en Discourse con una integración demostrada de la funcionalidad MVP para una plataforma compatible con AP, a saber Mastodon. En la medida de lo posible, la implementación se construirá para admitir un mayor soporte de los protocolos y cualquier extensión.
Esta especificación se refiere a la habilitación del soporte de AP por categoría, donde solo la primera publicación de cada tema en una categoría habilitada para AP se federará (“solo la primera publicación”).
Usuarios
El uso del plugin se documentará de manera integral en meta en un tema de plugin.
Usuario Normal
Se suscribe (o “sigue”) una categoría de Discourse habilitada para federación (FDC) en Mastodon (o cualquier otro servicio fediverso) utilizando el manejador de la categoría, por ejemplo, @announcements@meta.discourse.org.
Ve un extracto de la primera publicación de todos los temas de FDC (publicados después de que se suscriban) en su feed de Mastodon, cada uno con un enlace de regreso al tema asociado, por ejemplo, “Discutir en nuestro foro”.
Cualquier acción relacionada con la publicación en Mastodon no aparece en Discourse.
Cualquier acción relacionada con la publicación en Discourse no aparece en Mastodon.
Los extractos de publicaciones federadas pueden ser controlados por el autor de la publicación utilizando marcado similar al utilizado para controlar los extractos de temas, por ejemplo, <div>{text}</div>
Administrador
Habilita la federación por categoría utilizando una configuración de categoría. La federación solo se puede habilitar en categorías visibles para “todos” en instancias públicas.
Establece el nombre de usuario federado de la categoría a través de la interfaz de configuración de la categoría (no se puede cambiar).
Establece listas de dominios permitidos y denegados a través de la configuración del sitio desde la cual la actividad se acepta o rechaza automáticamente.
Establece una “lista de bloqueo” de nombres de usuario federados para formar parte de un objeto(s) de bloqueo en la bandeja de salida del servidor.
Establece la longitud máxima de caracteres de una nota federada utilizando una configuración del sitio, es decir, activitypub_note_excerpt_maxlength.
Establece el texto asociado con el enlace incluido en la primera publicación de un tema de Discourse federado en “Personalizar > Texto”.
Establece si el enlace de regreso (y el texto) al foro se incluye en las publicaciones federadas por categoría.
Agrega un par de claves a través de la configuración del sitio para firmar el contenido federado.
Técnico
El plugin incluirá pruebas completas (pruebas unitarias/de integración y pruebas js).
La categoría es un Actor automatizado de ActivityPub dentro de Discourse (como un tipo de Actor Grupo). El preferredUsername federado se establece por el administrador al habilitar la federación y se almacena en un campo personalizado de la categoría. El nombre federado (también conocido como nombre para mostrar) es el full_name de la categoría.
Los usuarios son Actores en el contenido federado por el Actor de la categoría. El preferredUsername federado es el nombre de usuario de Discourse del usuario en el momento de la federación. El preferredUsername de un usuario se almacena en un campo personalizado de usuario en caso de que el usuario cambie su nombre de usuario de Discourse. El nombre federado (también conocido como nombre para mostrar) es el nombre de usuario de Discourse del usuario.
En general, los objetos de ActivityPub se asociarán con sus objetos de Discourse equivalentes utilizando campos personalizados cuando sea apropiado (por ejemplo, IDs de objeto o actor), y nuevas tablas cuando sea apropiado (por ejemplo, bandejas de entrada y salida).
La actividad principal de ActivityPub a implementar es Seguir y las actividades y modelos asociados requeridos para implementarla, es decir, bandeja de entrada, bandeja de salida y Acciones y Colecciones asociadas requeridas.
Las publicaciones de Discourse se federarán como Notas de ActivityStream, con el contenido como HTML.
La autenticación se manejará utilizando Firmas HTTP, ver aquí y aquí. Se abordarán todas las demás Consideraciones de Seguridad en la especificación de ActivityPub según corresponda.
Los puntos finales de federación estarán protegidos según corresponda a la especificación, es decir, asegúrese de que redirect_to_login_if_required se utilice en los controladores, agregue guardian para el permiso de que la categoría sea visible para todos.
¡Estoy muy emocionado de ver esta noticia! ¡Gracias! Además, me alegra que empiecen con una implementación inicial simple en lugar de intentar abarcar demasiado (no es una referencia oblicua a Mastodon). Dudo en sugerir añadir algo, pero ya que piden sugerencias, una que espero que requiera un trabajo insignificante:
¿Qué pensarías sobre publicar opcionalmente también extractos de las respuestas, usando inReplyTo para enlazarlas? Creo que esto resaltaría el diálogo que ocurre en Discourse y sería más atractivo; junto con el “Discute en nuestro foro”, esperaría que ver la conversación atrajera a más gente.
El problema de federar las respuestas en esta etapa es que puedes crear expectativas de interacción que no se cumplirán hasta que tengas un soporte adecuado para ello. Es importante mantener claras las expectativas del usuario aquí. Si bien algunos usuarios pueden comprender las limitaciones de esas respuestas federadas, otros pueden no hacerlo. El otro problema es el de intentar reducir el número de desafíos técnicos a abordar a la vez.
Dicho esto, ya hemos contemplado una extensión de “tema completo” a la especificación de “solo la primera publicación” que ves arriba. He compartido algunas de las notas técnicas para eso a continuación para darte una idea de hacia dónde podría dirigirse esto. Destacaría que la extensión de “tema completo” no forma parte de la especificación inicial y es solo una posibilidad en esta etapa.
Extensión de tema completo
Las Notas entrantes se publicarían como nuevos temas o respuestas (usando inReplyTo o Replies).
Los filtros de seguridad y spam de Discourse se aplicarían a los objetos entrantes lo mejor posible utilizando Accept / Reject objects.
Las publicaciones de notas se atribuirían a un usuario provisional asociado con el actor id a través de un campo personalizado. Esto requerirá una variación no basada en correo electrónico del concepto de usuario provisional, ya que el usuario no tendrá un correo electrónico real (se puede generar un marcador de posición utilizando el actor federado id y preferredUsername).
Sería posible asociar usuarios provisionales de ActivityPub con usuarios estándar de Discourse, pero actualmente no está incluido en ninguna parte de esta especificación. Este es un problema de “identidad federada” y sus soluciones asociadas.
Las publicaciones federadas no admitirían menciones federadas @ o cualquier otra cosa en esta línea fuera de las especificaciones principales de ActivityPub/Stream. El soporte para tales características podría agregarse en versiones posteriores, por ejemplo, utilizando Webfinger, siguiendo a Mastodon.
La clave en esta primera versión es centrarse en la implementación mínima viable. Una vez que se establezca esa base, una federación completa (o más completa), potencialmente en la línea de esas notas de “tema completo”, será más factible. Sin embargo, enfatizaría que la dirección del plugin será algo que CDCK determinará. Cualquier cosa que mencione aquí son solo formas posibles en que se podría construir la especificación base.
PD. También me gustaría mencionar que fui contactado por Daniël Klabbers, desarrollador principal de Flarum, en noviembre del año pasado, quien me dijo que estaban trabajando en una extensión de ActivityPub. No sé cuál es el estado, pero sería bueno que todos los proyectos en el dominio de los Foros trabajaran juntos para lograr la mayor interoperabilidad posible en el espacio.
Con respecto a esa interoperabilidad, también me gustaría señalar el proceso de Propuesta de Mejora del Fediverso, el FEP en Codeberg:
Aquí, por ejemplo, Lemmy finalizó recientemente un FEP para Grupos de ActivityPub. Las discusiones tienen lugar en SocialHub en:
(El proceso FEP está cobrando impulso con el crecimiento del Fediverso y actualmente es el mejor lugar para estandarizar los mecanismos del protocolo)
Gracias @aschrijver, ¡muy útil! Personalmente, me centraré bastante en la implementación del MVP especificada anteriormente, trabajando en estrecha colaboración con CDCK. En la concisa frase de @mcdanlj, es fundamental que ese esfuerzo no intente “tragarse al elefante”. Estamos interesados en escuchar cualquier comentario constructivo sobre la especificación, particularmente en el frente técnico.
Sin embargo, añadiría que otros dos miembros de Pavilion@nmeyne (un veterano de la comunidad SSI; particularmente credenciales verificables) y @merefield también están trabajando en este espacio, y están interesados en algunas de las preguntas más amplias que usted ha planteado.
A modo de ilustración de malentendidos reales derivados de una ilusión de fidelidad, uno de los problemas que hemos encontrado en Maker Forums, donde importamos muchas comunidades de Google+ cuando Google+ desapareció, es que la importación fue de una fidelidad suficientemente alta como para que los recién llegados al sitio no se den cuenta de que están intentando interactuar con otros usuarios que no han (aún) llegado al sitio desde Google+, y por eso tenemos una respuesta predeterminada para hacerles saber que la persona con la que intentan hablar no está allí para responderles.
Gracias por proporcionar los detalles sobre la idea de la “extensión de tema completo”.
En caso de que esto se añada más adelante… fwiw, me gusta mucho el enfoque que ofrecía Pterotype para Wordpress, que es que cualquier comentario federado se retransmite directamente a moderación / aprobación grupal antes de ser publicado de nuevo en el tema original del foro como una respuesta.
En el caso de un foro, esta podría ser una tarea más adecuada para los tipos TL4 / TL3 en lugar del personal.
Personalmente, he descubierto que esto resulta especialmente útil para evitar que las respuestas fuera de tema / al estilo de las redes sociales dominen el tema de discusión original.
Sí, el uso de la cola de revisión es algo que hemos discutido para el contenido entrante. Como bien señalas, esto es algo a considerar si y cuando lleguemos a ese punto (no en la primera versión).
Solo una nota de que los asuntos administrativos relacionados con este trabajo se han resuelto, así que comenzaré a trabajar en la especificación la próxima semana. Cualquier comentario técnico adicional o nota sobre la especificación es bienvenido.
Tomará algunos meses para que esto se concrete, así que ten paciencia.
Si se elimina una publicación en Discourse, ¿se puede enviar una acción Delete a los seguidores?
En Maker Forums, tenemos suficientes “puntos de Google” que recibimos muchos spammers de SEO. Tenemos permisos relativamente flexibles para los usuarios nuevos porque una forma común de uso nuevo es una persona frustrada que busca ayuda relevante para el sitio, y nos ayuda a ayudarlos más rápido. Pero esto significa que los spammers tienden a publicar spam y luego se marca como spam, se elimina de la lista y luego se elimina relativamente rápido.
Me encantaría que esas publicaciones federadas se eliminaran y que la eliminación se publicara a través de Delete para limpiar el spam de las cachés federadas. ¿Está eso posiblemente dentro del alcance?
Podría ser útil en este caso si hubiera un retraso en la federación, de un número determinado de horas, para permitir que el spam sea tratado antes de la federación. (¿Quizás incluso aplicar el retraso solo a las primeras publicaciones de usuarios relativamente nuevos?)
Anticipo que haremos esto en el MVP por las razones que mencionas. Lo discutiré más a fondo con la gente de Discourse en el momento adecuado.
Sugerencia útil. La federación será definitivamente asíncrona. Cómo se establece y se maneja el retraso es algo que tendremos que abordar de alguna manera en el MVP.
Sugerencias específicas como esta para el MVP, particularmente basadas en casos de uso anteriores o experiencia en el dominio técnico, son muy bienvenidas.
Si no supone un trabajo inicial significativamente mayor, también sería valioso federar las ediciones de publicaciones como Actividades de Actualización. Si es una de esas cosas que se pueden aportar después del MVP, entonces un diseño que acomode razonablemente la adición posterior sería genial.
Por si sirve de algo, establecería el retraso bajo en mi(s) instancia(s). No planeo usarlo para evitar federar publicaciones de spam, porque es razonablemente probable que sea una señal que traiga a un moderador de su feed de fediverso a nuestro Discourse para tomar medidas. Tengo chat_integration_delay_seconds configurado en 20 para ediciones rápidas de errores tipográficos, y esperaría hacer algo similar aquí. Como mínimo, esa configuración sienta un precedente para dicho retraso.
¡Una breve actualización! Llevamos un mes de desarrollo y, a grandes rasgos, ya tenemos lo siguiente funcionando:
Las personas pueden seguir categorías con ActivityPub habilitado.
La primera publicación de temas en categorías habilitadas para ActivityPub se federan a los seguidores.
También hay una serie de piezas más pequeñas, pero no vale la pena entrar en detalles en esta etapa. Habrá al menos un mes más de desarrollo antes de que comencemos las pruebas internas.
