Federation support for Discourse

It has nothing to actually do with Discourse so you’ll want to ask the feed2toot project. Good luck.

1 me gusta

Thanks James for the information

Keith

Matrix commenting might be interest, since it is able to federate / “bridge” with other chat systems. Not ActivityPub based, but it is both decentralized and currently supported to x-post to Matrix via Chat Integration plugin.

1 me gusta

«Por qué los protocolos federados no funcionan»

5 Me gusta

“el valor de la libertad”

1 me gusta

No me resulta muy convincente. Se reduce a:

  1. XMPP es un desastre
  2. La federación no resuelve las preocupaciones de privacidad en torno a los metadatos
  3. La afirmación «La agenda de direcciones del dispositivo es ahora la red social».

Lo primero puede ser cierto sin ser general, y el artículo ni siquiera intenta hacer un argumento general, más allá de «mira las plantillas de problemas de GitHub», lo cual… parece más una queja sobre cómo se implementa que un punto significativo.

Lo segundo parece perfectamente cierto, pero tampoco es la única razón para la federación, y para mí no parece un impedimento —lo perfecto es enemigo de lo bueno, etc.

Y lo tercero… no creo que sea cierto excepto en un sentido limitado, y en ese sentido, no es realmente lo que quiero. Sí, puedo tener más de 20 aplicaciones de mensajería en una carpeta en mi teléfono y la mayoría comparten una agenda… ¡pero eso no es «problema resuelto» para mí!

8 Me gusta

del sitio web de Meta (Discourse)

Es cierto que si estás escribiendo una aplicación de mensajería optimizada para la privacidad a cualquier costo, el enfoque de Moxie es una forma de hacerlo. Sin embargo, esto termina siendo un mundo perversamente cerrado: una red cerrada, donde los clientes no oficiales están prohibidos, sin plataforma sobre la cual construir, sin estándares abiertos, y terminas poniendo todos tus huevos en la misma canasta, confiando en que Signal, en el pasado, presente y futuro, mantendrá sus valores, se mantendrá y de alguna manera evitará el compromiso y la censura… a pesar de ser probablemente el objetivo de ataque de mayor valor en la red.

Simplemente, ese no es un mundo en el que quiera vivir.

Debemos todo el éxito de Internet (y mucho menos de la Web) a la apertura, la interoperabilidad y la descentralización. Declarar que la apertura, la interoperabilidad y la descentralización es “demasiado difícil” y no vale la pena el esfuerzo al construir una solución de mensajería es desechar todo el potencial de la vitalidad, la creatividad y la innovación que proviene de una red abierta. Claro, puedes terminar con una aplicación de mensajería súper privada, pero una que empiece a oler alarmantemente a un jardín vallado como la iniciativa Internet.org de Facebook, o una palabra clave de AOL, o el AMP de Google.

Por lo tanto, continuamos aceptando con gusto el desafío de Moxie para demostrar que está equivocado: para mostrar que es posible e imperativo crear una plataforma de mensajería descentralizada y abierta que (si usas aplicaciones y servidores de confianza) pueda ser tan segura y protectora de metadatos como Signal… e incluso más, dado que puedes ejecutar tu servidor fuera de la red, y no necesitas registrarte con un número de teléfono, y en el futuro puede que ni siquiera necesites un servidor.

4 Me gusta

Además, la publicación de Moxie es de 2016, solo dos años después de la introducción del protocolo Matrix, y dos años antes del lanzamiento de ActivityPub.

Así que, aunque es bueno que pueda alojar mi propio correo electrónico, esa es también la razón por la que mi correo electrónico no está cifrado de extremo a extremo, y probablemente nunca lo estará.

Desde entonces apareció Delta.chat, basándose en los protocolos de correo electrónico y Autocrypt, lo que hace que esta afirmación sea indudablemente errónea: el correo electrónico es E2EE, y lo era antes, con OpenPGP, pero, en efecto, Autocrypt hace que sea mucho más fácil para las personas usar el cifrado de extremo a extremo.

Sería totalmente factible que Discourse implementara Autocrypt y ciertamente ayudaría a lograr lo mejor de ambos mundos: centralizado y federado. Pero, por supuesto, si Discourse adoptara usuarios en escena como punto de entrada para la federación entre instancias de Discourse en primer lugar, tendría mucho más sentido discutir la federación. Los intereses de Moxie en ese momento eran justificar por qué no permitiría a las personas implementar sus propios servidores de Signal. Y sí, hay muchos protocolos en desarrollo para abordar todo tipo de problemas, incluida la actualización de clientes.

4 Me gusta

Esto parece una solicitud de función separada :wink: ¿te importaría crear otro tema detallando esto o ya existe uno sobre esto?

3 Me gusta

Creo que ya propuse esto hace tiempo en una discusión similar. Déjame buscarlo…

Siéntete libre de consolidar la propuesta en un nuevo tema de características.

5 Me gusta

Necesitamos reinventar USENET

2 Me gusta

Aquí hay otro artículo de Mathew sobre Matrix, una plataforma federada. Cita clave:

¡Es como si USENET hubiera tenido un bebé con la Web!

:smile:

1 me gusta

Hablar de e2e en una discusión de federación no tiene ningún sentido. ¿Alguien puede mover esas respuestas a un nuevo tema, por favor?

1 me gusta

Quizás el Protocolo Lemmy sea un buen comienzo.

Ya tienes el modo de lista de correo, y funciona de manera similar (excepto que es a través de Fedi).

Hay un evento de Zoom 2022-04-28T20:00:00Z

En el mundo actual de las redes sociales, hemos visto cómo las plataformas se desvían al enfrentarse a los azotes de la desinformación y el trolling. En regímenes autoritarios, las plataformas enteras se bloquean fácilmente. Y sí, un multimillonario puede comprar una plataforma y cambiar las reglas.

¿Serían mejores las redes sociales descentralizadas (o P-2-P), donde no hay una entidad central que controle? ¿Cómo se eliminan las publicaciones dañinas cuando no hay un centro de mando central? Los fundadores de algunas de las principales redes sociales descentralizadas, desde Matrix hasta Manyverse y la nueva iniciativa Bluesky, le guiarán a través de las posibilidades. Con demostraciones de cómo utilizar estas alternativas peer-to-peer a Facebook, Slack y Twitter.

Sobre nuestros ponentes:

Jay Graber es CEO de Bluesky, la iniciativa financiada por Jack Dorsey y Twitter, “para desarrollar e impulsar la adopción a gran escala de tecnologías para la conversación pública abierta y descentralizada”.

Matthew Hodgson es Co-fundador de https://matrix.org/. Matrix es una red abierta para la comunicación segura y descentralizada con más de 40 millones de usuarios.

Andre Staltz es Creador de Manyverse, una “red social sin lo malo” gratuita y de código abierto, construida sobre el protocolo peer-to-peer SSB.

Este evento forma parte de una serie de talleres presentados por Metropolitan New York Library Council, Internet Archive, DWeb y Library Futures. Más información aquí: https://metro.org/decentralizedweb

Por favor, revise nuestro Código de Conducta, nuestra Declaración sobre Puntos de Vista y los detalles sobre los Servicios de Intérprete aquí: https://metro.org/code-of-conduct

6 Me gusta

Esto. Posiblemente también integrando acciones remotas de “Me gusta”.

He notado que el Fediverso se ha vuelto notablemente más activo y poblado desde que Elon Musk comenzó su oferta de adquisición de Twitter.

En las instancias de Discourse que administro (tres en este momento), me encantaría poder usar Mastodon (en mi caso) para poder seguirlas y “amplificarlas” a una audiencia más amplia, para hacer que la información en mis instancias sea más accesible y visible para una multitud de otros a quienes les pueda importar. Todas mis instancias son para expandir el alcance del conocimiento público sobre diversos temas, y un rico soporte para compartir a través de la integración de ActivityPub sería útil para lograr ese objetivo.

Convertir RSS a ActivityPub no ayudaría mucho.

Si este fuera mi proyecto, sería en fases y comenzaría de forma sencilla:

  1. Solo publicación: Categorías como Actores, incluyendo respuestas a temas debidamente enhebradas con inReplyTo. Estas se envían a los seguidores por publicación al mismo tiempo que, por ejemplo, las publicaciones se reenvían a integraciones de chat. Esto requeriría publicar (al menos algunas) categorías como Actores y almacenar Seguidores para cada Actor. Estos Actores de categoría no seguirían ni darían “me gusta”. No se utilizaría acceso autenticado. Honraría Actividades de “Me gusta”, Bloqueo y Deshacer. Quizás también un Actor para todo el servidor, para seguir fácilmente toda la actividad en el servidor.
  2. Mínima bidireccionalidad: Opcionalmente, aceptar acciones remotas de “Me gusta”.
  3. Más bidireccionalidad: Interactuar con acciones de “Anuncio” (es decir, compartir, republicar, amplificar), ya sea agregándolas como “me gusta” o mostrándolas por separado.
  4. Interacción del usuario: Opcionalmente, soporte de webfinger para usuarios, para permitir seguir a los usuarios como Actores y ver todas sus publicaciones. Opcionalmente, limitado por grupo (podría querer limitarlo a TL2, por ejemplo), la capacidad de interactuar en mensajes privados con Actores externos de ActivityPub. Esto podría posiblemente implementar la colección de publicaciones “me gusta” del usuario (al menos las públicas) en la colección liked.
  5. Bidireccionalidad textual: Opcionalmente, aceptar respuestas de no miembros a través de ActivityPub como comentarios, pero esta es complicada porque ingenuamente la reflejaría como una nueva publicación, por lo que los seguidores la verían dos veces. Probablemente requeriría que las publicaciones se marquen con su referencia externa y no se publiquen en las bandejas de entrada de los seguidores.

Explícitamente no querría admitir el “seguimiento” de Actores de ActivityPub desde dentro de Discourse; hacer de Discourse un clon de (por ejemplo) Mastodon parece una gran pérdida en general. En el lenguaje de la especificación de ActivityPub, no sería un “Servidor Federado conforme a ActivityPub” y eso está bien. Tampoco el componente cliente del protocolo tiene cabida en este plan.

6 Me gusta

Encontré esta discusión sobre implementaciones de ActivityPub en Rails. Podría valer la pena continuar la discusión allí. :person_shrugging:

2 Me gusta

¿Alguna sugerencia sobre cómo podría federar 4 foros? Son bastante grandes (100k, 20k, 50k, 20k miembros). Total 200k.

No puedes federar. Podrías configurar la autenticación SSO o LDAP personalizada, que todos los usuarios pueden compartir para acceder a cada foro con credenciales comunes.

También puedes intentar crear un plugin para integrarlos.