@hellekin Gracias por el informe. Siempre ocurrirá una cierta cantidad de solicitudes fallidas en un servicio ActivityPub, ya que los actores en el fediverso van y vienen. Por ejemplo, parece que:
La URL https://activitypub.example del primer registro no es una URL real (¿la cambiaste?)
El usuario https://mas.to/users/rikvipcode del segundo registro ya no existe
El usuario https://mastodon.social/users/ejovoni46709 del tercer registro ya no existe
La verbosidad de los registros está ahí para ayudar a depurar, sin embargo, si están saturando tus registros, puedes activarlos o desactivarlos usando la configuración del sitio activity pub verbose logging. El valor predeterminado es desactivado.
Estaremos buscando mejorar el manejo de errores en la fase dos si es necesario, pero hasta ahora parece que los fragmentos que publicaste son esperados, es decir, los Actores ya no están en el fediverso.
Actualmente, la forma en que el plugin maneja los fallos de entrega es rastrearlos de la misma manera que lo hace Mastodon, es decir, si hay 7 días de fallo a un punto final, se marcará como “no disponible” y ya no se intentarán las solicitudes.
De hecho, pero el código de estado es 410, lo que significa que la cuenta puede haberse movido (si hay una “Tombstone” — ¿se comprueba esta condición?)
Acabo de configurar un Discourse autoalojado completamente nuevo con tu plugin AP en https://federation.cafe, y estoy viendo algunos errores 403 en los Registros de Errores de Discourse (y las publicaciones no se están compartiendo).
Me pregunto si podría ser porque hay guiones, ¿tal vez?
[Discourse Activity Pub] GET request to https://bofh.social/internal/fetch failed: Expected([200, 201, 202, 301, 302, 307, 308]) <=> Actual(403 Forbidden)
El plugin MVP se prueba contra Mastodon. Veo que estás usando Pleroma allí. Sé que Pleroma cumple con ActivityPub y funciona con Mastodon, sin embargo, aún no hemos analizado de cerca qué ajustes podrían ser necesarios (si los hay) para garantizar la compatibilidad. Pero sigo interesado en ver qué está pasando aquí.
Parece que las solicitudes fallaron debido a un error de autenticación en tu servidor Pleroma (eso es lo que significa un error 403). Como puedo obtener ese endpoint GET usando una solicitud cURL no autenticada, sospecho que podría ser la autenticación HTTP la que está fallando en el extremo de Pleroma.
Para probar lo último (es decir, el punto 2), ¿podrías revisar tus registros de Pleroma (parece que tú también eres el administrador de ese servidor?) si es posible para ver si puedes obtener más detalles al respecto?
Gracias por tus comentarios @bmann. ¿Podrías ampliar el caso de uso que tienes en mente aquí? Con un ejemplo si es posible.
Este tema es el mejor lugar para mantenerse al tanto de los desarrollos. Cuando definamos un plan de fase 2, lo compartiré aquí. Mientras tanto, la mejor manera de ayudar es compartir los casos de uso específicos para los que estás utilizando, o te gustaría utilizar, el plugin.
El caso de uso es utilizar Discourse como un nodo AP más completo. Hay muchas maneras más sencillas de publicar contenido en AP (por ejemplo, usar feeds RSS de categorías y Zapier o Buffer), pero desarrollar una capacidad AP más completa solo se puede hacer como un plugin/integración.
Article es el tipo ActivityStream que está destinado a artículos completos. Dependiendo de la interfaz del cliente, mostrará una vista previa y luego un enlace para mostrar el artículo completo en línea (muy parecido a las advertencias de contenido, pero con “leer más”).
Note es el tipo de microblogging.
Al tener publicaciones Article completas, las personas pueden leer / impulsar / responder directamente en sus clientes AP.
Y, por supuesto, sería interesante conocer su hoja de ruta si van a seguir una instancia AP más de microblogging, o ir en una dirección de foro federado como Lemmy o Kbin, especialmente dadas las recientes noticias de Reddit.
@angus, @pmusaraj ¿han visto la convocatoria de financiación de NGI Sargasso? Es un aviso bastante corto pero podría ser útil para seguir desarrollando este plugin (a menos que ya tengan otros planes).
Hola a todos, me complace decir que la segunda fase del trabajo en este plugin ha sido aprobada. Esto es en lo que ya hemos comenzado a trabajar, con el objetivo de lanzarlo en aproximadamente 3,5 meses.
Soporte para editar Notas después de su publicación
Soporte para que los usuarios de Discourse verifiquen su identidad en Mastodon para que los posts de Discourse creados a partir de sus Toots se asocien con su cuenta de usuario de Discourse.
Permitir a un usuario realizar el flujo de Autorización OAuth de Mastodon con el servidor de Mastodon donde está almacenada su cuenta. Esto se inicia desde la configuración de la cuenta del usuario de Discourse.
Usando el token de acceso de Mastodon del usuario de Discourse, obtener y almacenar el ID de AP de su cuenta de Mastodon y almacenarlo con su cuenta de Discourse.
Asociar todas las actividades de Discourse asociadas con Actividades de AP de un Actor que tenga el ID de AP de un usuario de Discourse con ese usuario de Discourse, ya sea que se hayan realizado antes o después de que el usuario verificara su identidad.
No puedo hacer promesas en esta etapa, pero es muy probable que haya actualizaciones intermedias tanto para la federación de actualizaciones como para la segmentación de audiencia (publicación pública).
Esa es una limitación conocida. Hasta que se admitan las ediciones federadas, el plugin bloquea las ediciones de contenido federado y no hay ninguna configuración para deshabilitar esto.
Oh, lo siento por haber entendido mal. @feature@meta.discourse.org y @announcements@meta.discourse.org al menos se están federando desde aquí, y esta elección es la razón número uno por la que no he habilitado esto para Maker Forums…
Sí, este es el primer elemento de la Fase 2 en el que he trabajado. De hecho, ya hay una PR para ello, así que pronto tendrás algo de alivio en ese frente.
