Sí, Discourse podría hacer algo similar con su widget de incrustación de comentarios. Entre otras cosas, podría ayudar a reducir la torpeza que algunas personas experimentan al iniciar un foro que solo tiene unos pocos usuarios activos: AI sockpuppet accounts to jumpstart my community?. Los nuevos sitios de Discourse podrían usar publicaciones de blog para promocionar y sembrar su foro. Eso es algo posible ahora, pero permitir a los usuarios comentar directamente desde el widget de incrustación haría el proceso más fluido.
3 Me gusta
Un formulario de comentarios simple conectado a Discourse en el lado de Wordpress, para que los visitantes no tengan que ir primero a Discourse y crear una cuenta allí, antes de publicar un comentario, ayudaría a reducir la fricción y a generar participación, al menos para editores como yo.
Para mi caso de uso, sería ideal si un comentarista pudiera dejar su comentario simplemente con un nombre y una dirección de correo electrónico. Esto luego podría usarse para crear un usuario provisional en Discourse e invitarlo a unirse completamente para continuar la conversación, sin impedirle dejar su comentario.
Estamos descubriendo que la fricción adicional de crear una cuenta para dejar un comentario en un artículo publicado está dificultando la generación de participación y, en última instancia, el crecimiento de la comunidad en nuestro foro. Por ejemplo, cuando se le preguntó sobre nuestra sección de comentarios (utilizando la integración actual de Discourse-Wordpress), un autor nos dio los siguientes comentarios:
Sobre el área de conversación: ahora que lo mencionas… recuerdo haberlo visto. Y en ese momento, de hecho, pensé que lo olvidaría por el momento ya que parecía que llevaría mucho tiempo registrarse. Esa es una fuerte evidencia de cómo se sentiría la mayoría de las personas al tener que pasar por ese proceso. Normalmente estoy casi obsesionado con ver comentarios sobre mi escritura. Recuerdo haberme reído y dicho: “Supongo que no estoy lo suficientemente obsesionado como para lidiar con esto ahora mismo”. Idealmente, simplemente dejarías los comentarios abiertos a todos sin proceso de registro. Pero cualquier nivel de simplificación/facilidad mejoraría la participación allí. Comentarios como ese suelen ser un impulso. Si las personas se ven obstaculizadas de alguna manera, tenderán a seguir adelante y no se tomarán el tiempo.
3 Me gusta
Justo estaba pensando en esto el otro día. Curiosamente, he echado de menos los comentarios de Wordpress en mis publicaciones de blog porque parecía muy rápido para que la gente empezara, una barrera de entrada muy baja.
A pesar de tener un proceso de registro muy sencillo, ahora mismo si alguien quiere comentar una publicación, tiene que visitar una página nueva. Creo que cruzar ese umbral puede resultar demasiado engorroso. Casi como si quisiera comentar en A, pero tengo que visitar B para comentar en A y luego volver a A para ver el comentario. Sería más natural comentar en A justo debajo de A.
Me gusta la idea de poner en escena a los usuarios. Se me ocurre que podría hackear esto haciendo que el formulario de comentarios de Wordpress envíe un correo electrónico al foro de Discourse y luego poner en escena a un usuario de esa manera, aunque me imagino que se volverá más complejo integrarlo completamente de esta manera.
3 Me gusta
Creo que esto solía ser posible, pero estoy bastante seguro de que Discourse ahora compara la “Cabecera de remitente” del correo electrónico con su Ruta de retorno. Si no coinciden, el correo electrónico es rechazado. (Si Discourse no está verificando la Ruta de retorno, el sistema de comentarios podría ser fácilmente abusado: cualquier dirección de correo electrónico podría ingresarse en el formulario).
Hay algunas maneras de abordar el problema de Discourse como sistema de comentarios. Creo que el mejor enfoque sería que Discourse mejorara su iframe incrustado de comentarios para que los usuarios pudieran interactuar con él como usuarios autenticados de Discourse. Si eso no es posible, se podría desarrollar una aplicación web de comentarios de Discourse incrustada. Ese sería un proyecto interesante, pero querría estar seguro de que Discourse no proporcionaría una funcionalidad similar a través de su iframe de comentarios incrustados antes de seguir adelante.
También existen algunas soluciones específicas para WordPress. La más simple es habilitar los comentarios de WordPress y el plugin WP Discourse. El riesgo es que esto reduciría la actividad en el foro de Discourse. Creo que habría formas de ayudar con eso en la interfaz de usuario de WordPress, por ejemplo, enlazando a conversaciones relacionadas que estuvieran ocurriendo en Discourse.
También sería posible desarrollar algo específico para sitios de WordPress que funcionaran como proveedor de SSO de Discourse. Escribí sobre eso en publicaciones anteriores en este tema. Para hacerlo bien, podría requerir cambios significativos en el plugin WP Discourse. A menos que (estoy pensando en voz alta aquí):
Lo que intento indicar con la captura de pantalla anterior es que, en el caso de un sitio de WordPress que sea el proveedor de SSO de Discourse, los comentarios podrían mostrarse con el iframe de comentarios de Discourse. Los comentarios podrían crearse a través de un formulario que publica en la API de Discourse. Esto podría requerir algunos cambios en el iframe de comentarios de Discourse para garantizar que se actualice cuando se agrega un nuevo comentario, pero no requeriría que los usuarios pudieran interactuar con él como usuarios autenticados de Discourse.
4 Me gusta
Entonces, si entiendo correctamente, la idea sería que el comentarista se registre en el lado de WordPress, luego deje un comentario a través del iframe incrustado de Discourse, que se publicaría en el tema en Discourse, luego actualice la pantalla de vuelta en WordPress, para que aparezca de inmediato.
El proceso de registro de WordPress validaría el correo electrónico, supongo. Pero esto también requeriría cambiar a WordPress como proveedor de Discourse SSO, lo cual es factible, pero de alguna manera desafortunado, porque traslada la fricción al otro lado para las personas que solo quieren registrarse en el foro.
Tiendo a estar de acuerdo con lo que has dicho aquí:
Si incluso fuera posible registrarse allí mismo en el iframe, o al menos prepararlo, para que uno pudiera proceder con el comentario (que solo se publicaría una vez que se valide el correo electrónico), eso me parecería una solución que equilibra la facilidad de uso con la seguridad.
2 Me gusta
Sí, lo has entendido. Si WordPress es el proveedor de SSO, el problema de permitir a los usuarios comentar en temas de Discourse no es tan difícil de resolver. La parte complicada, en términos de trabajar con el estado actual del plugin WP Discourse, es averiguar cómo mostrar los comentarios en WordPress; actualmente, la sección de comentarios de WP Discourse no refleja las respuestas del tema de Discourse. En su lugar, se muestra una selección de los “mejores” comentarios.
Sería posible actualizar el plugin WP Discourse para manejar este caso de uso, pero para hacerlo correctamente se requeriría reescribir completamente la forma en que maneja los comentarios de Discourse. No es mi decisión, pero creo que invertir esfuerzos en mejorar el iframe de comentarios de Discourse sería un mejor uso del tiempo.
5 Me gusta
Solo quería añadir mi voz a quienes desean esta función.
Sería muy bueno si los usuarios de WP pudieran registrarse/iniciar sesión y comentar directamente debajo de una publicación en WP sin tener que ir al foro, para que todo se sienta más como un sistema de comentarios. Su comentario aparecería tanto debajo de la publicación como en el hilo de Discourse que se creó. Y siempre tendrían la opción de publicar en Discourse, WordPress o ambos, sin problemas. No tengo idea de cómo se lograría esto, pero sería una forma muy fluida de integrar los comentarios de WP con Discourse que se siente menos tosca y sin duda mejoraría enormemente la cantidad de comentarios que obtenemos actualmente con el plugin existente.
3 Me gusta
Quizás esto:
Pero secuestra totalmente el inicio de sesión de Discourse, que yo sepa.
¿Eso permitiría a los usuarios publicar comentarios directamente debajo de una publicación de WordPress y poblar automáticamente esa publicación en el hilo correspondiente de Discourse?
Estoy trabajando en esto ahora. La primera versión es para un sitio WordPress sin cabeza que utiliza el framework Remix para su frontend. Una vez que eso esté hecho, haré una versión para sitios WordPress normales. Probablemente será un plugin que extienda el plugin WP Discourse. Espero que la mayor parte de lo que estoy haciendo en el sitio WordPress sin cabeza se pueda transferir a los sitios WordPress normales, pero podría requerir algunas concesiones.
Permitir a los usuarios comentar directamente desde un sitio externo es trivial de implementar. El requisito principal es que el sitio externo tenga acceso a las credenciales del usuario de Discourse. Eso se puede hacer utilizando el sitio externo como proveedor de DiscourseConnect para Discourse o configurando Discourse como proveedor de DiscourseConnect para el sitio externo.
En el segundo escenario, donde el sitio externo no es el proveedor de DiscourseConnect para Discourse, la primera vez que un usuario quiera comentar desde el sitio externo, deberá hacer clic en un enlace para conectar su cuenta en el sitio externo con su cuenta de Discourse (o registrarse en Discourse si aún no lo ha hecho). Puede ser bastante fluido desde el punto de vista del usuario.
Sin embargo, el cambio anterior no hace que todo se sienta como un sistema de comentarios normal. Una expectativa normal para un sistema de comentarios es que puedas leer e interactuar con todos los comentarios. El plugin WP Discourse solo muestra una selección de comentarios que se extraen de una ruta especial proporcionada por Discourse. No proporciona ninguna funcionalidad para interactuar con los comentarios.
Las partes difíciles del problema son:
- Paginación de todos los comentarios de un tema en WordPress, teniendo en cuenta que podría haber miles.
- Proporcionar una interfaz de usuario que brinde al usuario comentarios sobre dónde se encuentra en una lista larga de comentarios.
- Averiguar cómo mostrar comentarios que son respuestas directas a otros comentarios. (La convención de Discourse para esto está desalineada con la forma en que la mayoría de los sistemas de comentarios manejan las respuestas).
- Permitir a los usuarios responder directamente a un comentario, dar “me gusta” a un comentario, editar sus propios comentarios, etc.
- Tratar con comentarios creados en Discourse que podrían contener contenido o marcado que no se puede renderizar o interactuar fácilmente en el sitio externo. Por ejemplo, oneboxes, encuestas…
- Proporcionar una forma de filtrar comentarios por recientes, más antiguos, mejores, etc…
Todo esto debe lograrse sin poner una carga excesiva en el servidor del sitio externo, hacer demasiadas solicitudes de API a Discourse o consumir demasiada memoria en el dispositivo del usuario (el objetivo es crear un sistema de comentarios ligero). Es factible, pero no es algo que se pueda simplemente incorporar al código existente de WP Discourse sin hacerle cambios significativos.
4 Me gusta
¡Me alegra saber que has empezado con esto!
Solo una idea: dado que parte de la idea es reducir la fricción para que la gente comente en primer lugar, podría ser una buena idea centrarse en la fluidez de ese primer comentario. Como se mencionó anteriormente, parece que muchas personas simplemente quieren poder comentar con su dirección de correo electrónico; el problema entonces es la validación y el inicio de sesión, o la creación de cuentas (dependiendo, supongo, de cómo esté configurado DiscourseConnect).
Una vez que un usuario entra, esperaría que sea más probable que visite el tema del foro correspondiente para obtener toda la funcionalidad de discusión basada en Discourse. Solo espero que todas esas partes difíciles del problema no impidan resolver el problema del “primer comentario”. Tener miles de comentarios para los que tendremos que averiguar la paginación sería entonces un “buen problema a tener”. 
4 Me gusta
Esto es suficiente para mí, ya que los usuarios nuevos y antiguos participarán y se relacionarán entre sí. No es gran cosa para mí, un externo.
Sí, esa es una preocupación genuina. El primer paso es poner en línea un sitio de demostración. Tener un sitio en vivo para probar las cosas debería dejar claros los puntos de fricción.
Podría ser técnicamente posible permitir que los usuarios anónimos comenten en las publicaciones. La única forma no improvisada que se me ocurre sería que un usuario real publicara los comentarios en nombre del usuario anónimo. Sin embargo, eso se siente un poco extraño.
Sé que WordPress tiene una configuración para permitir que los usuarios “invitados” creen comentarios. Viene con la limitación de que un comentario de “invitado” no se asociará con un usuario real si el usuario que creó el comentario de invitado se registra en el sitio después de crearlo. Publicar “en nombre de” un usuario tendría que funcionar de manera similar: no habría forma de saber que el usuario que creó el comentario anónimo era el propietario de la dirección de correo electrónico que proporcionó con el comentario.
Idealmente, los usuarios se autenticarán en el sitio externo o en Discourse antes de crear un comentario.
Desde el punto de vista del usuario, la menor fricción posible sería en el caso de que el sitio externo sea el proveedor de SSO para Discourse. Eso les permitiría comentar en temas de Discourse sin tener que visitar el sitio de Discourse.
Desde el punto de vista del propietario del sitio, la forma técnicamente más sencilla de autenticar a los usuarios sería que Discourse funcione como un proveedor de autenticación para el sitio externo. Esa es la configuración que estoy utilizando actualmente en mi sitio de prueba local. El sitio externo (Remix) ni siquiera tiene una tabla de usuarios. Simplemente crea una sesión de usuario basada en la respuesta de la ruta /session/sso_provider de Discourse.
La desventaja de usar Discourse como proveedor de autenticación para el sitio externo es que obliga a los usuarios a pasar por el proceso de registro/inicio de sesión de Discourse. No hay nada de malo en ese proceso, excepto que parece obligar a los usuarios a descargar todos los activos de Discourse cuando es posible que solo quieran dejar un comentario en el sitio externo. Así que es un poco lento. Investigaré más…
Lo sería Quizás redúzcalo a cientos para un escenario más realista. El punto que intento transmitir es que el problema se vuelve complejo una vez que se supera 1 página de publicaciones (20 publicaciones).
Editar: podría ser posible usar las invitaciones de Discourse para agilizar el proceso: si un usuario anónimo quisiera comentar una publicación, se mostraría un campo de correo electrónico junto con el formulario de comentarios. El envío del comentario activaría a Discourse para enviar una invitación a la dirección de correo electrónico. El comentario se mantendría en una cola hasta que se aceptara la invitación. Esto permitiría a los usuarios crear el comentario cuando sintieran la inspiración y les daría retroalimentación inmediata sobre el estado de su comentario.
4 Me gusta
Me entusiasma ver cuál será la solución de @simon aquí.
Solo quería señalar que una solución que se está desarrollando en una vía diferente en este frente es usar ActivityPub. En su última versión, el plugin oficial de ActivityPub de WordPress añadió soporte para el plugin ActivityPub de Discourse.
Esto significa que si tienes instalado el plugin ActivityPub de WordPress y el plugin ActivityPub de Discourse, todo lo que necesitas hacer es configurar una categoría para “Seguir” a un actor de WordPress que publica (o a todo el sitio de WordPress) y tus publicaciones de WordPress aparecerán como nuevos temas en esa categoría de Discourse.
(ten en cuenta que el plugin de WordPress tiene un retraso en la publicación, por eso tarda un minuto en aparecer en Discourse en el video; salta a 1:40 para verlo aparecer).
El plugin ActivityPub de WordPress también admite la ingesta de actividades y ya está configurado para procesar las actividades entrantes en respuesta a una publicación como un “Comentario” en esa publicación, sin embargo, esa parte en particular aún no funciona con las Actividades que envía el plugin de Discourse (creo que el plugin de WordPress aún no admite notas anunciadas). Pero eso también debería funcionar pronto.
Ver más
6 Me gusta
Tenga en cuenta que Matthias, el mantenedor del plugin de Wordpress, ha logrado que esto funcione, por lo que pronto debería haber soporte para compartir publicaciones y comentarios nativos bidireccionales entre Discourse y Wordpress (a través de ActivityPub).
https://socialhub.activitypub.rocks/t/this-is-a-test-federation/4164/2
https://pfefferle.org/this-is-a-test-federation/#comment-148
3 Me gusta
Este tema comenzó con la idea de que un sistema de comentarios impulsado por Discourse podría proporcionar una funcionalidad similar a Coral, con el beneficio adicional de permitir que los comentarios del sitio web se ramifiquen en temas regulares de Discourse. Discourse proporciona la capacidad de moderar los comentarios de un sitio web y permite que las discusiones relacionadas con los comentarios ocurran en el foro.
No creo que sea necesario argumentar sobre la necesidad de moderación.
La necesidad de permitir que los comentarios se ramifiquen en temas reales de Discourse podría ser menos obvia. Estoy partiendo de la suposición de que tener cualquier tipo de conversación en línea es difícil: la conversación en persona proporciona todo tipo de señales sutiles que no existen en línea. Tener conversaciones en línea significativas con más de un puñado de personas es casi imposible. Ahí es donde entra Discourse. La funcionalidad de grupos de Discourse proporciona la capacidad de limitar quién puede participar en un tema. Se puede permitir que grupos de comentaristas participen en temas de Discourse cerrados. Esto es un poco lo opuesto a cómo funciona el fediverso.
Dicho esto, tengo curiosidad sobre cómo podría funcionar la integración de Discourse/WordPress en el fediverso. Por ejemplo, si Sally comenta en la publicación de WordPress de Bob, ¿qué se esperaría que sucediera con el comentario de Sally si tuviera una cuenta de Discourse? ¿Qué se esperaría que sucediera con el comentario de Sally si no tuviera una cuenta de Discourse? ¿Hay alguna manera de que Sally pudiera optar por no publicar su comentario en el fediverso?
Me estoy saliendo del tema, pero con los diversos tipos de leyes sobre daños en línea que se están implementando o proponiendo en los países occidentales, si el comentario de Sally se considera ofensivo, ¿quién es responsable de publicarlo? Supongo que es una pregunta sin respuesta en este momento.
3 Me gusta
¡Interesante!
La forma en que sugeriría pensar sobre cómo funciona ActivityPub con la moderación y la agrupación (y otros aspectos de la comunicación en línea) es que es principalmente un estándar de comunicación. Proporciona algunos mecanismos para abordar esas cuestiones, pero en gran medida las deja en manos de los diversos clientes del sistema.
El correo electrónico como estándar de comunicación es una analogía imperfecta, pero quizás útil. “Correo electrónico” es una colección de estándares de comunicación que le permite intercambiar mensajes con cualquier persona en Internet. Tiene varios problemas de “control de calidad”, por ejemplo, spam. Hay algunos aspectos de la colección de estándares que llamamos “correo electrónico” que ayudan a lidiar con esos problemas (por ejemplo, DMARC, DKIM, SPF, etc.), sin embargo, quizás la forma principal en que se aborda el control de calidad es en los propios clientes de correo electrónico. Gmail se convirtió en un cliente de correo electrónico popular en parte porque, argumentablemente, manejaba el spam (y problemas de control de calidad similares) bastante bien.
Siguiendo la analogía, Discourse sería el “Gmail” de ActivityPub. Todas las herramientas de moderación, agrupación de usuarios y otras características que hacen de Discourse una excelente plataforma de discusión todavía están (prácticamente) disponibles dentro del contexto de ActivityPub. Desarrollaré esto comenzando a responder sus preguntas.
Comenzaré describiendo lo que sucede y luego quizás pasaremos a las preguntas más matizadas. Omitiré muchas cosas aquí, con el objetivo de responder lo básico:
-
El comentario de Sally se publica como un objeto ActivityPub desde WordPress.
-
El objeto se ingiere en Discourse y se convierte en una publicación.
-
Si el “Actor” de Sally está asociado con una cuenta de usuario en Discourse, la publicación se asociará con esa cuenta de usuario. Si su Actor aún no está asociado con una cuenta de usuario, se creará un usuario provisional a partir del actor de Sally y ellos serán los propietarios de la publicación.
Puede ver lo anterior en funcionamiento en este tema:
-
La categoría de Discourse WordPress - SocialHub está siguiendo WordPress de Matthias.
-
Matthias publicó un nuevo artículo en su blog usando su cuenta habitual de WordPress.
-
Eso apareció en Discourse como un nuevo tema, con la publicación asociada a un usuario provisional asociado con el Actor de Matthias.
-
La forma en que funcionan los comentarios es exactamente la misma.
Solo para abordar quizás la pregunta más obvia: ¿Puede Matthias reconciliar el usuario “provisional” creado a partir de su actor de WordPress y su cuenta normal de Discourse en ese servidor?
La respuesta a corto plazo es que el plugin de Discourse tiene un conjunto de características de “Autorización” que actualmente le permite reclamar la propiedad de actores de otros servidores de Discourse o servidores de Mastodon, lo que fusiona cualquier usuario provisional de este tipo en su cuenta (lo que significa que ahora posee las publicaciones en su cuenta principal de Discourse). Ese conjunto de características podría extenderse a WordPress. Aprecio que esto sea un poco verboso, y podría ser más fácil entender lo que quiero decir con esta demostración:
La respuesta a más largo plazo es que las pruebas de identidad pueden integrarse en las actividades de ActivityPub en algún momento, lo que podría eliminar la necesidad de autorización impulsada por el usuario, lo que significa que la “reconciliación” podría ser (más) automática.
Quizás otra pregunta es si la “reconciliación” es necesaria, dado que Matthias todavía controla los atributos de identidad de su usuario provisional a través de su Actor de ActivityPub (que es editable en WordPress, y las ediciones se filtran al usuario provisional en Discourse).
Digo la mayor parte de esto como una forma de aclaración, para que podamos pasar a sus preguntas más matizadas e importantes. Espero que hasta ahora tenga sentido.
2 Me gusta
Tiene sentido.
En cuanto al problema de la moderación, me refiero a usar Discourse para moderar comentarios de WordPress. Esa es la funcionalidad que permitiría usar Discourse de manera similar a Coral. Esto se logra fácilmente si los comentarios de WordPress son en realidad comentarios de Discourse que se publican de WordPress a Discourse a través de la API. Simplemente funciona de inmediato. Esto permite, por ejemplo, usar cualquier herramienta de moderación impulsada por IA que proporcione Discourse. Me pregunto si se podría lograr algo similar con la integración de ActivityPub de WordPress/Discourse.
¿Cuál es la prueba de identidad para el usuario provisional? ¿Se pasa su dirección de correo electrónico desde el servidor de origen?
En cuanto a mi (personal) preocupación por no querer publicar contenido en todo el fediverso, parece que es técnicamente posible establecer una relación ActivityPub uno a uno entre un sitio de Discourse y un sitio de WordPress, pero me pregunto si este tipo de configuración no va en contra del propósito del protocolo ActivityPub.
Editar: podría valer la pena añadir que el objetivo es crear una relación beneficiosa para ambos entre un sitio web y un foro de Discourse asociado. Las herramientas de moderación de Discourse están destinadas a proporcionar la seguridad de que el sistema de comentarios del sitio web está bien moderado. La sección de comentarios del sitio web está destinada a ser utilizada para sembrar el sitio de Discourse con temas y usuarios.
2 Me gusta
La publicación que se convierte del objeto ActivityPub tiene en su mayoría* las mismas funciones de preprocesamiento y posprocesamiento aplicadas que una publicación creada a través de la API. El punto de entrada es diferente (es decir, un controlador de ActivityPub en lugar del controlador de publicaciones), pero la forma en que se crean las publicaciones es en su mayoría la misma.
*En términos más técnicos, si creas una publicación a través de la API, el procesamiento real lo realiza NewPostManager, que luego delega la mayor parte del trabajo a PostCreator. Lo principal que maneja NewPostManager (para nuestros propósitos aquí) es la cola de revisión. Todo lo demás se maneja en PostCreator.
Actualmente, el plugin ActivityPub omite NewPostManager y lo pasa a PostCreator en su propio PostHandler (es decir, el del plugin). Hice esto principalmente para reducir la complejidad en la implementación inicial. No hay una razón inherente por la que el PostHandler del plugin no pueda pasar la publicación a NewPostManager y beneficiarse de las comprobaciones de la cola de revisión.
En resumen, no hay una diferencia sustancial entre las publicaciones creadas a través del plugin ActivityPub y las creadas a través de la API normal.
Hay varias capas en esto.
-
En primer lugar, la SOLICITUD POST del origen a su servidor está firmada utilizando firmas HTTP para garantizar que la solicitud realmente se origina en el origen.
-
En segundo lugar, cada Actor (es decir, usuario) en ese origen tiene un UUID, es decir, un ID vinculado a su dominio, único en el fediverso. Se ve algo así:
https://angus.ngrok.io/ap/actor/f4b517bf6f81dbddfad3e44a45c9619d
Los correos electrónicos no se utilizan en ActivityPub.
-
Cada Actividad (por ejemplo, una Creación de un objeto similar a una publicación) que recibe está asociada con un ID de Actor. Y cada ID de Actor se puede resolver en atributos de Actor.
-
Por lo tanto, cuando recibe una “Actividad”, por ejemplo, la creación de un nuevo objeto similar a una publicación, en su servidor, conoce, según el dominio desde el que recibió la actividad, los atributos del Actor que realiza la Actividad. Usted confía en el dominio de envío aquí, pero esto siempre es así hasta el punto, por ejemplo, en que Discourse confía en las instancias de Wordpress con el plugin WP Discourse para enviar los atributos de usuario correctos asociados también.
Por lo tanto, el usuario en espera en sí mismo no necesita una prueba de identidad per se, de la misma manera que un usuario en espera por correo electrónico no necesita una prueba de identidad.
La necesidad de una prueba de identidad surge cuando la persona real asociada con el actor de ActivityPub, y otra cuenta de Discourse, como el ejemplo con Matthias anterior, quiere consolidar (o “conciliar”) su identidad. Puede que no les guste que tengan efectivamente dos “usuarios” en una sola instancia de Discourse. Notaría que, sin tal reconciliación, pueden controlar
-
Los atributos de identidad del Actor de ActivityPub / usuario en espera a través del dominio de origen, por ejemplo, al actualizar su perfil de Wordpress, esas actualizaciones se federan y Discourse aplica lo mismo); y
-
El contenido asociado con el Actor de ActivityPub / usuario en espera a través del dominio de origen, por ejemplo, al editar su comentario de Wordpress, se envía una actividad de Actualización que luego es procesada por Discourse.
Pero, sin embargo, pueden sentir que es “desordenado” tener efectivamente dos usuarios en Discourse. Es por eso que el plugin tiene su conjunto de funciones de “Autorización”, para permitirle demostrar que su usuario normal de Discourse está asociado con el actor de ActivityPub con su usuario en espera. Esto se hace actualmente a través de mecanismos de autorización específicos de la plataforma:
-
Para Mastodon, se hace a través de la API OAuth de Mastodon. Requiere que autentique su cuenta en Mastodon para demostrar que controla el actor relevante.
-
Para Discourse, se hace a través de la API de usuario. Esto es lo que se muestra en el video de mi publicación anterior.
-
Hay algunas formas en que lo mismo podría hacerse para Wordpress, por ejemplo, DiscourseConnect a través del plugin WP Discourse. Esto aún no está implementado.
Una vez que demuestre que posee el actor asociado con el usuario en espera, el usuario en espera se fusiona con su usuario normal, sus publicaciones se convierten en suyas, y cualquier Actividad nueva asociada con ese Actor se convierte automáticamente en suya. Pero este conjunto de funciones es realmente más para mejorar la experiencia del usuario y, estrictamente hablando, no es necesario. La persona real detrás de estos diversos usuarios controla tanto los atributos del usuario como su contenido desde el principio.
Sí, es posible canalizar el objetivo de las publicaciones salientes y restringir la fuente de las publicaciones entrantes. Si esto va en contra del propósito de ActivityPub es debatible. Estrictamente hablando, ActivityPub es solo un estándar. Argumentaría que no hay razón por la que no se pueda usar el estándar de esta manera. Históricamente, ActivityPub se ha asociado con redes sociales descentralizadas, particularmente Mastodon, que puede ser la razón por la que siente que este tipo de enfoque va en contra del propósito de ActivityPub. Pero haría una distinción entre el estándar ActivityPub en sí y sus implementaciones existentes aquí.
Además, en este contexto, señalaría que, al igual que el correo electrónico, lo que llamamos “ActivityPub” es en realidad una colección de estándares. El documento de estándares titulado “ActivityPub” debe leerse junto con otro documento de estándares llamado “ActivityStreams”, que describe los objetos principales en juego aquí. El estándar ActivityStreams es más firmemente “neutral al servicio” que el propio ActivityPub (es decir, menos ligado a redes sociales descentralizadas).
Para usar (otra) analogía, la cadena de bloques como tecnología es simplemente un libro mayor descentralizado, la primera vez que me lo explicaron me hizo pensar en el Sistema Torrens de registro de tierras, inventado en el siglo XIX (en Australia) por esencialmente las mismas razones por las que se inventó la cadena de bloques (es decir, para prevenir el fraude en las transacciones de propiedad). Pero la implementación más popular de la cadena de bloques es Bitcoin, que tiene un uso específico (diferente) y ciertas valencias culturales. La analogía no es la mejor, pero una forma de pensarlo es que Mastodon y las redes sociales descentralizadas son para ActivityPub lo que Bitcoin es para la cadena de bloques.
De hecho, una de las razones por las que ayudé a establecer un nuevo grupo de trabajo de ActivityPub para Foros de W3C con NodeBB, Flarum y otros es intentar cambiar el enfoque de la integración de ActivityPub de las implementaciones existentes (por ejemplo, Mastodon) a las preocupaciones de los foros, como las relacionadas con la moderación que usted está planteando. De hecho, tenemos nuestra próxima reunión hoy. Si tiene tiempo, me encantaría tener un compañero “Discourser” (¿es ese un término?) allí
4 Me gusta
Estoy hablando de usar las herramientas de moderación de Discourse para moderar los comentarios que aparecen en WordPress. Técnicamente, eso se podría hacer con una solicitud de API de Discourse o un Webhook; después de que ocurriera una acción de moderación en Discourse, se podría hacer una solicitud para cambiar el estado del comentario en WordPress.
Suponiendo que las cosas se cambien para que las publicaciones de ActivityPub se manejen en la cola de revisión, todavía habría un problema con el retraso entre el momento en que el comentario se publica inicialmente en WordPress y cuando aparece en Discourse. Creo que son un par de minutos, ¿verdad?
Para este caso en particular, uno de los principales argumentos de venta es “usar Discourse para moderar los comentarios de tu sitio web”. Continúa enumerando las funciones de moderación de Discourse, el sistema de niveles de confianza, la cola de revisión, las herramientas de moderación impulsadas por IA, etc. Estas son herramientas que serían útiles para blogs pequeños, pero un requisito para los sitios de noticias convencionales. Creo que la mejor manera de lograr esto es usar Discourse como la única fuente de verdad para los comentarios, en lugar de tener comentarios en dos (o más) bases de datos.
¡Eso es genial! Sin tener tiempo para pensarlo más, no creo que sería un gran representante de Discourse.
Tengo algunas preocupaciones generales sobre la idea de tratar los temas, las publicaciones y los usuarios como simples datos. Debe haber una manera de asegurarse de que no se pierda el contexto de dónde ocurre una discusión.
A un nivel más práctico, el protocolo ActivityPub despegó antes de la introducción de las leyes sobre daños en línea que se están introduciendo en varios países. Debe haber alguna garantía de que los servidores que consumen datos de un origen respetarán las solicitudes de eliminación. De lo contrario, los usuarios que generan contenido en un servidor de origen corren el riesgo de sufrir repercusiones legales si su contenido se considera posteriormente perjudicial en su país.
3 Me gusta