Solo una nota de que actualmente estamos en este paso
5 Me gusta
¡Esto se ve genial!
Recientemente instalé un servidor Discourse para nuestra Cooperativa CoSocial que ejecuta un servidor Mastodon. Terminé instalando el plugin OAuth2 para que solo aceptemos inicios de sesión desde nuestro servidor Mastodon → https://members.cosocial.ca (instalación nueva y bastante simple, solo “prueba de OAuth”).
Mi pregunta / solicitud de función es que sea posible fusionar/combinar actores de Mastodon en cuentas de Discourse, de modo que cuando las cuentas en Mastodon respondan, puedan ser vinculadas / propiedad de la cuenta de Discourse asociada.
Cómo Lemmy No Hace Esto
Documenté cómo Lemmy no hace esto: puedes interactuar a través de Mastodon, y se crea una cuenta en Lemmy para esa cuenta de Mastodon, pero en realidad no puedes iniciar sesión y usar las funciones de primera clase de Lemmy con tu cuenta de Mastodon.
4 Me gusta
Eso está en la agenda…
Y ya está en la cola para su revisión
3 Me gusta
Genial. Parece que mis usuarios del plugin Discourse OAuth necesitarían “confirmar de nuevo” para interoperar con este plugin AP.
Creo que está perfectamente bien en esta etapa, solo quiero señalar el servidor OAuth como un ángulo más, siempre y cuando no entre en conflicto. Lo “deseable” sería “si OAuth con servidor Mastodon, entonces vincular automáticamente la identidad del actor AP”. Totalmente futuro y también único para este tipo de configuración.
(¡Y disculpas por no haber abierto la página para ver esa parte! ¡Genial!)
1 me gusta
La PR que añade este conjunto de características ya se ha fusionado.
Como señaló Angus anteriormente, lo siguiente es la verificación de usuarios a través de tokens OAuth.
2 Me gusta
Los problemas que vi anteriormente con el markdown sin procesar que se mostraba también parecen estar afectando a meta. Estoy siguiendo a @feature@meta.discourse.org y hace unas horas, se creó esta publicación que fue federada desde ese Actor:
Esto apareció en Mastodon con errores de esta manera:
En Elk, se ve así; un poco mejor:
Acabo de empezar a seguir a @feature@meta.discourse.org en mi cuenta pura de Mastodon para probar esto, pero por supuesto eso es demasiado tarde para ver esta publicación en particular allí. 
Así que el markdown incrustado que vi anteriormente desde mi propia instalación no era una base de datos defectuosa, o si lo era, era un problema de base de datos compartido con meta y, por lo tanto, probablemente no asociado con mis pruebas.
2 Me gusta
Sí, puedo reproducir esto, veo una salida similar en una instancia de Mastodon y en Ivory (aplicación de iOS).
2 Me gusta
No estoy seguro de si esto está funcionando bien. El plugin está habilitado y creé un tema en una categoría con ActivityPub habilitado, pero no veo la insignia junto a las publicaciones (y mi intento de seguir al actor de ActivityPub de la categoría pareció fallar, ya que se comporta como lo haría un servidor si los seguimientos necesitaran ser aprobados manualmente por un usuario).
Acabo de notar que el mismo problema pareció ocurrir con Feature en Meta.
1 me gusta
Sería genial entender el objetivo final de las restricciones, sin preocuparse por el estado intermedio.
Por ejemplo, creo que vi una referencia en una PR de que se bloqueará el cambio de propietarios de las publicaciones si el plugin está habilitado. Como administrador, tengo que usar esa función en raras ocasiones (por ejemplo, al cambiar el moderador de categoría, hago que el nuevo moderador principal de la categoría sea el propietario de la categoría sobre la publicación fija). Espero que, al final, esto se manifieste como una eliminación y una nueva publicación, o incluso que simplemente se ignore, en lugar de bloquear el cambio de propiedad.
También me pregunto sobre mover publicaciones entre categorías. Tengo que hacer eso con bastante frecuencia, especialmente cuando los usuarios nuevos publican en la categoría incorrecta. Ingenuamente esperaría que resultara en que un actor de categoría elimine su impulso y el nuevo actor de categoría agregue un impulso, pero sin eliminar la publicación subyacente, de modo que si alguien más hubiera visto e impulsado una publicación, su impulso no desaparecería solo porque el impulso del actor de categoría desapareció.
En general, sería de gran ayuda saber qué esperan que se prohíba cuando se agregue este plugin, después de que se complete el desarrollo de la función especificada actualmente, independientemente de las restricciones que estén vigentes en este momento.
1 me gusta
@hello-smile6 Estoy viendo lo mismo con el plugin actualizado hoy:
No veo la configuración para ello, así que asumo que es un error.
2 Me gusta
Gracias por el informe adicional. Estoy investigando esto.
Gracias por el informe, lo estamos investigando.
Aprecio tu punto de vista, sin embargo:
-
Mientras el plugin se está desarrollando activamente, intentar explicar las cosas de esta manera sería improductivo, ya que la explicación puede cambiar.
-
Hay bastantes escenarios y casos límite diferentes que el plugin ya maneja, para que yo explique cada uno narrativamente en esta etapa llevaría demasiado tiempo (es decir, hacer esto de forma efectiva en esta publicación larga varias veces). Ya hay más de 400 especificaciones para el plugin.
-
Sin embargo, las restricciones a menudo se explican narrativamente en los comentarios de las PR y commits, que creo que ya estás leyendo.
Esto se discutió en profundidad en la PR:
He restringido el cambio de propietarios de publicaciones y la creación de wikis de publicaciones, incluso para administradores, en temas AP. Esto se debe a que las publicaciones remotas de AP deben conservar la fidelidad con el original y ambas acciones pueden romper esa fidelidad.
Puede haber una manera de hacer que la federación funcione tanto con wikis como con el cambio de propietarios de publicaciones, sin embargo, sugiero que lo agreguemos como una “característica” en una PR futura, ya que implicará multiplicar o cambiar el actor asociado con un objeto que está federado en múltiples plataformas. Creo que nunca podremos permitir el cambio de propietarios de publicaciones importadas de AP (notas), ya que la asociación actor/objeto no es propiedad de Discourse, sino del lugar donde se escribió el contenido. Para dar una analogía ilustrativa, en este contexto, la eliminación de una publicación asociada con una nota importada es menos una “eliminación” en sí misma que una opción para no mostrar una nota.
Hay bastantes escenarios diferentes que involucran el movimiento de publicaciones. Manejaré el específico que has mencionado por ahora, a saber, mover una publicación entre dos categorías diferentes habilitadas para ActivityPub.
Asumes que la única vez que se mueve una publicación entre categorías es cuando la publicación se publica inicialmente en la categoría incorrecta, y el movimiento ocurre poco después de que se realizó la publicación. ¿Qué pasa si, 4 meses después de que se realizó una publicación, mueves esa publicación a otra categoría porque quieres consolidar una cierta colección de publicaciones en un nuevo tema en una categoría diferente? ¿Tendría sentido enviar un “Deshacer” para el impulso original en ese escenario?
Esto depende de si estamos hablando de la configuración de la Primera Publicación o de la Configuración Completa del Tema. Para la primera, agregaremos un botón para que la primera publicación se publique manualmente para abordar específicamente el escenario de movimiento de categoría. Para la segunda, agregar automáticamente un impulso puede tener sentido, lo pensaré un poco más.
Entiendo tu punto de vista, sin embargo, ya he compartido bastantes detalles sobre el estado final en la especificación de la Fase 2 anterior. Más allá de esa especificación, y diciéndolo de la manera más suave posible, hay demasiados casos de uso y escenarios para discutirlos todos en profundidad contigo, y luego también con el equipo de Discourse.org, mientras trabajo en ellos 
Actualizaré el OP con una descripción general del comportamiento esperado una vez que se complete la Fase 2.
1 me gusta
No puedo reproducir este problema. Acabo de seguir feature@meta.discourse.org desde una cuenta de prueba de Mastodon y no vi ningún error (ni en Mastodon ni en Discourse).
1 me gusta
¿Podría estar relacionado con la instancia de la que lo seguí, hace algo inusual esta instancia?
Oh, vaya, en mi intento de hacer una pregunta clara, soné como si estuviera pidiendo mucho trabajo. Pido disculpas por la mala comunicación. Agradezco la reflexiva respuesta.
Eso era lo que quería preguntar, no actualizaciones detalladas continuas en este hilo. Mi “después” en “después de que se complete el desarrollo de la función especificada actualmente” estaba destinado a indicar cuándo sería valioso tener la aclaración, no a pedir que ahora describiera el estado futuro. Mi pregunta estaba formulada de manera ambigua. ¡Lo siento!
Esto es lo que realmente quería entender: ¿El objetivo final, en términos generales, es restringir Discourse solo a lo que soporta ActivityPub canónico, o es federar desde una experiencia nativa de Discourse sin restricciones al fediverso sobre una base de mejor esfuerzo? Mi experiencia pasada con integraciones de Discourse me había llevado a esperar el mejor esfuerzo; ahora entiendo que su plan es buscar la fidelidad en su lugar, a costa de la funcionalidad de Discourse, y no solo como una medida temporal durante el desarrollo.
No estoy asumiendo eso. ¿Por qué cuatro meses harían una diferencia aquí? Está recién en una categoría federada, ¿por qué eso no haría que la categoría federada la impulsara? Yo, al menos, habría esperado ingenuamente que eso sucediera. A menudo veo a personas impulsar publicaciones de muchos meses de antigüedad, así que no conozco ninguna razón particular por la que esto sería diferente.
Y sí, creo que tendría sentido enviar un Deshacer para el impulso original. Eso parece ser común. (De hecho, Deshacer un impulso y luego un nuevo impulso parece ser un mecanismo típico para “impulsar” contenido; no relacionado con este propósito, pero ilustrando que Deshacer en un impulso se usa comúnmente y, por lo tanto, no debería causar problemas a otras implementaciones de ActivityPub).
Veo lo mismo ahora mismo para feature@meta.discourse.org desde mastodon.cloud, que creo que está ejecutando Mastodon estándar.
1 me gusta
Personalmente, no lo pienso de ninguna de las dos maneras. Discourse.org establecerá la agenda general aquí, pero en términos generales las decisiones se toman en función de cómo funciona y qué es práctico. Si hay una forma sensata y sostenible de permitir cambios de autoría en todas las publicaciones, independientemente de su procedencia, entonces genial.
Centrándonos solo en deshacer el impulso original, ¿ese Deshacer específico no parece servir para un propósito? También es, argumentablemente, un poco sorprendente en algunos escenarios, como intentó mostrar mi ejemplo. La intención del cambio de categoría podría no ser revertir (Deshacer) la “descubribilidad” original del contenido. Puede ser para cambiar la organización del contenido más adelante por una razón diferente.
En otras palabras, aplicar una reversión automática del Anuncio original en un cambio de categoría en Discourse funciona en algunos escenarios, pero no en otros. E incluso en escenarios donde parece tener más sentido, el Anuncio original no está causando ningún daño. Por lo tanto, persiguiendo los principios de menor daño y menor sorpresa, parece que simplemente dejar el Anuncio original en su lugar tiene más sentido. Disculpas si me estoy perdiendo algo.
Para pensarlo desde otro ángulo, no creo que sea correcto pensar en las actividades de Anuncio de un Actor de Categoría como sinónimas del rol taxonómico de las Categorías mismas. Un Anuncio es la forma en que un actor de Categoría comparte contenido con sus seguidores, pero no es una taxonomía en sí misma. Es una forma en que el contenido se descubre dentro del Fediverso. No creo que deba haber una relación 1:1 entre las categorías y las actividades de Anuncio de los actores de categoría.
3 Me gusta
Ah. Entonces es realmente una pregunta para el equipo. 
Eso también tiene sentido. Estoy de acuerdo, no hay mucho valor en deshacer el impulso.
Entonces es una señal activada por flanco; significaría “una publicación acaba de entrar en esta categoría, ya sea al ser escrita o al ser movida a la categoría”. Eso es conceptualmente simple.
Entonces pensaría en cambiar la autoría de una publicación de la misma manera. Sería el nuevo actor creando una nueva actividad para la publicación del nuevo autor, y no hay necesidad particular de hacer nada con la actividad antigua realizada bajo el antiguo autor, porque el antiguo autor no estaría escribiendo ninguna edición y no debería ser acreditado por esos nuevos cambios. En realidad, no eliminaron su publicación en Discourse, por lo que eliminar la actividad del autor original no necesariamente reflejaría alguna verdad fundamental. Pero lo que había sido publicado antes por el actor del antiguo autor sería lo que habían escrito, y no habría razón para eliminar esas publicaciones. Y si alguien siguiera el enlace de regreso a Discourse, vería el contenido y la autoría actuales, con (si se tienen suficientes permisos) la vista del historial de edición.
La misma lógica se aplica a los wikis. Aparecen en Discourse bajo una autoría singular pero permitiendo que otros escriban. Las actualizaciones de otros autores no se atribuyen ampliamente (a menos que tenga suficientes permisos para leer el historial). En realidad, no es particularmente significativo si esa atribución se muestra con un avatar en la vista web dentro de Discourse o un actor de activitypub asociado con una actividad; el resultado final es la atribución presentada al lector humano en el otro extremo de una u otra canalización de renderizado.
1 me gusta
Hm, no estoy seguro de estar de acuerdo. El resultado final de esto serán dos Notas idénticas en el Fediverso, autorizadas por diferentes Actores, ambas visibles en múltiples plataformas. Para una persona nueva que llega a ese contenido por primera vez, verá el mismo contenido autorizado por diferentes personas. Por el contrario, cuando cambias un autor en Discourse, esencialmente reescribes la historia; para una persona nueva que llega al contenido por primera vez, solo ve al nuevo autor. Hay una diferencia ahí, ¿no crees?
No estoy seguro de entender completamente. ¿Estás diciendo que todas las ediciones de la publicación wiki, por parte de cualquier usuario, deberían tratarse como actividades de Actualización estándar atribuidas al Actor original (es decir, la persona que la publicó)?
Tenga en cuenta que este es el tema de esta PR, acompañado de notas explicativas.
4 Me gusta