Lo mismo aquí. No puedo cambiar el propietario de un hilo. A pesar de que la categoría NO está federada.
Esas son advertencias, no errores. No significan necesariamente que algo esté mal, están ahí para darte más información sobre lo que está sucediendo. Podría haber una serie de razones por las que el contenido del Fediverso no se procesa, muchas de las cuales tienen que ver con la persona que envía el contenido. Si no quieres que aparezcan en tus registros, desactiva el registro detallado para el complemento ActivityPub (activity pub verbose logging).
¿El tema está en una categoría de ActivityPub o tiene una etiqueta de ActivityPub?
¿Se creó el tema en una categoría de ActivityPub o con una etiqueta de ActivityPub?
Tenga en cuenta que el cambio del propietario de los temas está deshabilitado intencionalmente para los temas de ActivityPub. En cuanto a por qué es así, consulte lo anterior:
Es una categoría con Activitypub, pero estamos hablando del propietario del hilo que no está involucrado con activitypub, ya que es una cuenta diferente.
Creo que debería haber una opción para permitir cambiar el propietario de todos modos, de lo contrario, no tiene sentido que Discourse tenga la ventana modal para cambiar el propietario.
Además, cambiarlo sin enviar ninguna actualización a activitypub es perfecto para nosotros.
1 me gusta
Entiendo que la gente quiera la capacidad de cambiar la propiedad de las publicaciones. El problema a abordar a este respecto es el que describí anteriormente, específicamente esto:
El contenido que aparece en tu Discourse proviene de un servicio del cual no eres Administrador y sobre el cual, si no fuera por ActivityPub, no tendrías ningún control. Simplemente extender la capacidad de cambiar el autor de ese contenido sin la debida consideración de ese hecho no sería prudente.
En cuanto al contenido redactado por usuarios de tu Discourse en un tema que se publica a través de ActivityPub, considera qué debería suceder si se realizan actualizaciones al contenido una vez que hayas cambiado el autor de la publicación. ¿Hacemos lo siguiente?
- Dejamos de publicar actualizaciones de ActivityPub; o
- ¿Las publicamos por el Actor “antiguo” (usuario); o
- ¿Las publicamos por el Actor “nuevo” (usuario)?
Publicar actividades de actualización para un Objeto existente con un Actor nuevo (es decir, 3) funcionará con Discourse (como intenté dar una solución para esta pregunta), pero no funcionará con otros servicios de ActivityPub. De hecho, ya he insistido en este punto, por esta razón, en el ecosistema de ActivityPub. Ver aquí:
Y tengo un PR pendiente en Mastodon para hacer posible el punto 3.
Para dar un ejemplo de solo uno de los problemas aquí, considera el caso en el que estás publicando contenido de ActivityPub con tu cuenta (y tu nombre y foto) adjuntos. Uno de tus “competidores” sigue tu contenido. En su servidor, cambian la propiedad de todas las publicaciones con tu contenido para que sean publicaciones suyas (con su nombre y su foto) en lugar de tuyas. Eso podría, de manera algo comprensible, molestarte. Sí, por supuesto, esto es posible de todos modos con código personalizado, pero la pregunta es si quieres incorporar eso en las funcionalidades predeterminadas del plugin.
Pensando en esto durante la noche, un enfoque que podría aliviar esto un poco es si agregáramos el Actor de publicación a la visualización del estado de ActivityPub:
Estoy abierto a otras ideas en esa línea.
Cierto, creo que simplemente eliminaré la ventana modal por completo en los temas de ActivityPub hasta que resolvamos la pregunta subyacente aquí.
2 Me gusta
Entiendo el problema, en nuestro caso usamos Activitypub con una cuenta para cada categoría y publicamos esa actualización.
Por lo tanto, a quién pertenece el hilo no nos importa tanto en Activitypub para los diversos casos, por esta razón digo que deberíamos poder hacerlo de todos modos.
ActivityPub no se trata solo de cómo usas tu foro, sino de cómo tu foro interactúa con el resto del fediverso. Además, para construir algo en el plugin, también debemos tener en cuenta otros casos de uso.
No quiero dar la impresión de que permitir el cambio del propietario de una publicación no es un problema que se esté considerando activamente, o que no se permitirá en una actualización futura. Estoy interesado en cualquier idea que la gente tenga para resolver los problemas subyacentes aquí, algunos de los cuales he expuesto anteriormente.
Abordando este ejemplo, sería razonable prohibir el cambio de propiedad de las publicaciones que han sido federadas, mientras se permite a los administradores cambiar la propiedad de las publicaciones creadas dentro de esa instancia de Discourse, independientemente de si están federadas.
Un administrador puede hacerse pasar por un usuario. Por lo tanto, un administrador puede, dentro de la plataforma con sus funcionalidades existentes, crear contenido haciéndose pasar por cualquier usuario de la plataforma. Espero que los administradores no abusen de este poder; yo no lo hago. Sin embargo, ese poder es similar en impacto a la capacidad de cambiar la propiedad de una publicación, federada o no. En general, “un administrador puede hacer algo nefasto” ya es cierto de innumerables maneras.
Estoy de acuerdo (al menos en la medida en que entiendo 
) en que cambiar la propiedad de una publicación que se realizó por federación (¿por lo tanto, no una publicación de tema?) no tiene mucho sentido. A diferencia de cambiar la propiedad de las publicaciones realizadas en el sitio, no recuerdo haber visto un caso de uso articulado.
Me gusta esto no solo desde el punto de vista de la robustez contra este tipo de ataque, sino para hacer más visible la federación, facilitando que un visitante del sitio encuentre actores a los que seguir. ¿Cómo se vería esto para un caso en el que hay un actor de categoría (y, tal vez algún día, un actor de sitio) y un actor de persona? ¿Tendrías una lista?
- Publicado por
[@categoría@sitio](enlace) - Publicado por
[@persona@sitio)(enlace)
1 me gusta
Gracias por tu útil análisis.
De acuerdo.
Este análisis solo se aplica a las publicaciones no federadas. La pregunta no es si cambiar el propietario de una publicación tiene sentido para Discourse en sí. La pregunta es qué efectos tiene el cambio de propiedad en el contenido federado. Si cambias la propiedad de una publicación local que ha sido federada, tienes que lidiar con esta pregunta:
Comenzaría señalando que tanto la opción 1 como la 2 tienen problemas sustanciales, que puedo detallar si es necesario. La respuesta puede ser la que el plugin ya admite, es decir, “3”, sin embargo, si seguimos ese camino, sucederá lo siguiente (asumiendo que mi PR actual a Mastodon no se fusiona):
- El tema se federará.
- Las publicaciones del tema aparecerán en Mastodon.
- El administrador del sitio cambia el propietario de la publicación.
- El nuevo propietario de la publicación realiza varias ediciones en la publicación.
- Las ediciones no llegan a Mastodon (ni a ninguna otra plataforma ActivityPub).
Y a partir de eso:
- Alguien vendrá aquí y dirá “mis ediciones no se están federando”. La razón por la cual no será inmediatamente obvia porque, en lo que respecta a Discourse, se están federando.
El punto clave aquí es que si tomáramos este enfoque, seríamos la primera plataforma en el fediverso (que yo sepa) en hacerlo. Ser el único nodo en un sistema interconectado de nodos que hace algo no es algo deseable. Podemos impulsar un cambio al respecto, pero tendríamos que ser conscientes de que eso es lo que estaríamos intentando.
Dicho esto, ya he implementado la opción 3, y sospecho que será la respuesta final que me permitirá eliminar esta restricción. Todavía tengo la esperanza de que alguien pueda encontrar un enfoque ligeramente más matizado, o algo en lo que aún no haya pensado.
Solo se enumeraría el Actor attributedTo del objeto, por lo que solo habría uno.
1 me gusta
Veo la fealdad. El proceso de pensamiento que me llevó allí es algo así como esto…
Podría imaginar ingenuamente algo como el #3 con solo un poquito del #2 — Para federar también una actualización generada del usuario antiguo que se añade a la última versión que publicaron, algún texto generado por el sistema en la parte superior o inferior, algo vagamente como “para futuras actualizaciones, sigue @newuser@site”.
Entonces tendría sentido (de nuevo, ingenuamente) asignar un nuevo ID a la publicación actualizada bajo el nuevo attributedTo y que se utiliza para las actualizaciones del nuevo propietario.
Un caso límite obvio para mí sería cambiar la propiedad al propietario original: ¿vuelve al ID de publicación antiguo o se asigna otro ID? Pensaría que revierte, en cuyo caso el ID de publicación federado tendría que ser una clave para una tupla (usuario, publicación de Discourse). Esperaría que esto requiriera una migración para admitirlo con compatibilidad retroactiva.
Todo eso como un experimento mental me hace apreciar más claramente por qué no estarías ansioso por apresurarte antes de que se considere tu propuesta de cambio a Mastodon. 
Excluyendo que tu PR de Mastodon sea aceptado, podría imaginar poder marcar publicaciones individuales como no federadas, que se federarían como una eliminación si previamente fueron federadas, y/o podrían hacerse con el plugin instalado pero antes de que se habilitara la federación, y luego permitir el cambio de propiedad solo para publicaciones no federadas. Todas las publicaciones para las que quiero poder cambiar la propiedad son publicaciones que no son valiosas de federar, hasta donde yo sé.
Podría imaginar que eso sería valioso incluso si tu PR de Mastodon es aceptado y se admite el cambio de propiedad. No estoy seguro de que tenga sentido federar las publicaciones de temas de categoría, por ejemplo. Al menos, creo que excluiría todas ellas de la federación en mi sitio, incluso si se admitiera el cambio de propiedad, si tuviera la opción de excluirlas.
Un experimento mental interesante, sin embargo, esto no funcionaría por algunas razones.
- No sigues a usuarios individuales en la actividadpub de discourse.
- No puedes cambiar el ID de un objeto activitypub existente (tendrías que crear un nuevo objeto).
- Como dices, si la propiedad cambiara de nuevo, o múltiples veces, terminarías con múltiples objetos para una publicación, lo cual sería inmanejable.
Una cosa que puedo hacer ahora en esta línea es cambiar la restricción a si la primera publicación en un tema local está publicada. Eso ayudará con algunos temas como dices.
1 me gusta
Mi malentendido; Pensé que también habías creado la capacidad de hacer eso, así como actores de categoría. (No es una solicitud de función, solo un malentendido).
Eso era lo que intentaba describir, y claramente fallé. En cualquier caso, estaba destinado a ser algo así como una reductio ad absurdum. 
¡Eso sería maravilloso! 
1 me gusta
Hola, ¿hay alguna limitación para Lemmy?
No puedo seguir: @batepapo@lemmy.eco.br, por ejemplo.
De hecho, sí puedo seguir. Incluso aparece el botón “Dejar de seguir” debajo del perfil, pero cuando actualizo la página, todo desaparece.
1 me gusta
¡Gran trabajo! Tengo una pregunta sobre los minutos de retraso en la entrega de ActivityPub. ¿Hay alguna forma de desactivar la función para que la publicación sea visible de inmediato?
Configurar 1 minuto es casi inmediato, pero también deseo publicar en tiempo real.
1 me gusta
@David_Ghost lee esto
2 Me gusta
Esto es lo primero que he notado también. ¿Cuál sería el inconveniente de añadir el título de un nuevo tema a la publicación distribuida a través de ActivityPub?
[Título del tema de Discourse]
[línea vacía]
[Texto del tema de Discourse, como se publica ahora]
La gente de Lemmy estaba trabajando en añadir compatibilidad con Discourse. Está en mi agenda revisarlo.
Eso significa que Discourse está enviando un “Seguir” pero no está recibiendo un “Aceptar” de Lemmy.
Actualmente, solo puedes hacer esto usando una variable de entorno (por ejemplo, establecida en tu archivo app.yml)
DISCOURSE_ACTIVITY_PUB_DELIVERY_DELAY=0
El título de un tema ya se publica. Es el name de la colección asociada al tema.
Así es como la federación de Discourse a Discourse, o de Discourse a NodeBB, o de Discourse a cualquier plataforma similar a un foro incluye los títulos de los temas. Mastodon no procesa los títulos. Si pusiéramos el título del tema en el contenido de la Nota como sugieres, esto plantearía problemas, por ejemplo, para cuando el contenido se federara a plataformas que admiten títulos.
Fundamentalmente, la limitación que describes es que Mastodon es una plataforma de microblogging. Ya hemos añadido funcionalidad para acomodar eso, es decir, el marcado [note][/note] para permitirte dirigir el contenido que estás federando. Si deseas tener una federación adecuada similar a un foro, te sugiero que te federes con otras instancias de Discourse.
Sí, hay muchas instancias de Mastodon. Pero también hay muchas instancias de Discourse. Si una instancia de Discourse con la que deseas federarte aún no está configurada para hacerlo, estaré encantado de ayudarles a configurarla.
5 Me gusta
¿Es posible eliminar Actores?
Y, ¿sería posible configurar varias categorías, para que publique todo lo nuevo en Discourse?
De lo contrario, alguien tendría que seguir xx identificadores en Mastodon para obtener todo el contenido de todas las categorías.
Puedes deshabilitar un Actor, lo que deshabilita todo lo relacionado con ese actor.
Si eliminas la categoría o la etiqueta con la que está asociado el actor, se eliminará el Actor. Actualmente no es posible eliminar un actor de forma aislada. Te recomendaría simplemente deshabilitar el Actor.
Esto puede ser posible en el futuro (a medio o largo plazo) si añadimos un actor de “Aplicación” para un Discourse completo. La federación de todo en un Discourse a través de un único Actor probablemente siempre será un caso de uso de nicho.
1 me gusta
Hm, está bien. Quizás mi comprensión de las posibilidades es diferente…
Ayer lo configuré y funcionó bien. Eliminé las publicaciones en Discourse, porque solo lo estaba probando, pero las publicaciones siguen en línea en Mastodon. Así que pensé que podría eliminar la cuenta para eliminar también el contenido de Mastodon.
Si solo lo deshabilito, el contenido sigue en línea en Mastodon.
Y si no puedo eliminarlo, no podré usar ese identificador con otras categorías en el futuro. Es posible que quiera cambiar algunas categorías en el futuro, pero no podré usarlo con ese identificador que tiene xx seguidores. ASÍ QUE necesito crear un nuevo identificador y todos tendrán que seguirlo de nuevo. No veo ninguna ventaja en solo deshabilitar un identificador que ya no necesito.
Y: Cuando deshabilito un identificador, el otro también se deshabilita. ¿Así que solo puedo ejecutar varios identificadores o nada?
Pero eso es lo que quiero, ¿o lo estoy entendiendo mal? Quiero informar a las personas en una red social sobre las discusiones en todo mi Discourse y no solo para una etiqueta o categoría. Cuando ejecuto una sección de “Noticias”, puedo entenderlo, pero quiero que todos participen en las discusiones, así que tengo que publicar todo y no solo una categoría.