Hay muchas instancias de Discourse. No sé exactamente cuántas, pero tengo cuentas en varias docenas. Es imposible llevar un control de todo y, con frecuencia, me encuentro con temas en comunidades distintas pero no tan diferentes que discuten problemas similares, los cuales podrían compartirse fácilmente entre instancias, ya que algunos participantes se repiten en las discusiones. Sería de gran ayuda poder compartir estos temas entre instancias sin tener que iniciar sesión varias veces, cruzar referencias de temas y mantener una conversación fluida con las partes interesadas.
Tratar a los usuarios de ActivityPub como usuarios en fase de prueba, de la misma manera en que se tratan a los usuarios de correo electrónico ajenos a una instancia de Discourse, parece ser un buen compromiso para empezar.
Un feed RSS sin duda ayudaría a rastrear temas en curso en un solo lugar, pero no aportaría nada diferente a la aplicación Discourse Hub, ni permitiría participar en las discusiones.
@hellekin No estoy seguro de esto. Quizás tengas razón, quizás no. Hay muchos clubes nocturnos, restaurantes, supermercados, programas informáticos, etc. Algunos están incluso bastante cerca, geográficamente y/o en cuanto a lo que ofrecen. ¿Debería uno considerar “tonto” que lugares diferentes ofrezcan lo mismo y estén separados? ¿Y que estos lugares deban fusionarse para tener solo uno centralizado?
Ahora bien, en este caso es un poco más evolucionado, ya que las comunidades seguirían estando, en cierto modo, separadas, pero estarían vinculadas. Queda la pregunta de si todas las comunidades son “lo mismo”: ¿Tienen las mismas normas, la misma atmósfera, el mismo tipo de personas, etc.? Esto puede ser lo que convierte a una comunidad en un “lugar especial” que vale la pena participar (activamente): El hecho de que sea única. Tiene un ambiente único, un tipo de humor particular, etc. Una IDENTIDAD única. Las personas son un aspecto fundamental de esto: Quién va aquí o allá. Qué tipo de persona.
Quizás esto sea una visión de la DIVERSIDAD: Mezclarlo todo y terminar con algo “igual” en todas partes, porque está tan mezclado.
Por otro lado, tenemos ENLACES y CITAS. Nada impide que cualquiera enlace, cite y resuma lo que ocurre en otro lugar. Y aquí, puedes mantener la identidad de cada lugar y no hacer que todo sea “igual”.
De todos modos, estas pueden ser las preguntas centrales detrás del propio principio de ActivityPub y la voluntad de implementarlo con Discourse. Por supuesto, si es solo opcional, cualquiera puede hacer lo que quiera. Y las opciones suelen ser algo bueno, IMHO (no estoy muy seguro de por qué una comunidad exitosa querría que su contenido se compartiera fuera y que la gente pudiera interactuar con él desde fuera).
[Esto es un poco como la película “Demolition Man”, donde solo quedan restaurantes de Taco Bell, ¿verdad?]
No estoy seguro de cómo tu punto de vista se relaciona con mi publicación anterior. No dije nada sobre fusionar comunidades, simplemente sobre algunos temas comunes. Y aun así, solo sugerí que las cuentas de usuario podrían ser el intermediario…
¿Y esto no es, en esencia, ‘fusionar’ las ofertas de diferentes comunidades? Aún así, ‘fusionas’ algo de contenido, incluso si, como se dijo en el mensaje anterior:
Parece haber una falta de voluntad por parte del equipo de Discourse para hacerlo, además de ventajas o casos de uso poco claros. Si no ves cómo mi mensaje anterior se relaciona con el tema, entonces está bien. Mis disculpas. Olvídalo.
Absolutamente no. Pero me gustaría leer sobre ellos en mi periódico local, o, en un caso más especializado, en una guía gastronómica italiana para conocedores. El hecho de que las cosas no sean todas iguales es lo que hace que valga la pena suscribirse a ellas. Volviendo a la web y a las comunidades, enlazar y citar son, por supuesto, valiosos. Pero son otro caso de uso, diferente a compartir un tema entre foros y ver el hilo en contexto, tal vez participar directamente.
Tienes razón en que en algunos casos no quieres mezclar identidades y, desde luego, no fusionar completamente comunidades dispersas. Pero puedes fusionar selectivamente solo aquellas partes donde tenga sentido. Ya sea sobre una base de tema por tema, ciertas (sub)categorías, etiquetas o grupos específicos de personas que comparten contenido.
En realidad, tampoco se trata de ActivityPub. El protocolo es bastante de bajo nivel, construido sobre HTTP. Puedes construir cualquier cosa con él. Muy a menudo, al mencionar ActivityPub, la gente tiende automáticamente a pensar en microblogging (Mastodon), ya que es la aplicación más popular hasta ahora. Si consideras este dominio, todos están creando su propia “comunidad única” con él, definida por a quién siguen. Esto crea su línea de tiempo personal. Aparte de eso, pueden haber elegido crear su cuenta en, por ejemplo, mastodon.technology, y su línea de tiempo del servidor tiene vagamente el tema “tecnología”. Pero este dominio realmente no se ajusta a Discourse, por supuesto. Es microblogging, no foros comunitarios, después de todo.
Actualmente, algunas aplicaciones de microblogging están ampliando su dominio con el concepto de Grupos. Podrías verlo como un concepto comunitario que se extiende más allá de los límites del servidor. Así que, aunque esté en mastodon.technology, podría suscribirme al grupo “espagueti” y al de “cambio climático”. Pero sigue siendo solo microblogging → todo se comprime y se aplan en mis líneas de tiempo.
¿Qué es una comunidad exitosa? ¿Cuáles son sus límites, qué está dentro y qué está fuera? Estos pueden estar muy claramente definidos y relacionarse con la identidad y la diversidad. Una cosa a la que no se relacionan per se son los límites específicos del servidor.
Aunque fui muy amplio en La comunidad no tiene límites, es pensar sin estos límites artificiales del servidor que abordé (y cómo eso puede aumentar la calidad, cantidad y actividad de la comunidad). No entré en la identidad, que es un buen punto para abordar también. Gracias por responder allí @Mevo, responderé a su debido tiempo.
Gracias @aschrijver, esto es muy útil.
De lo que dice el primer párrafo, entiendo la idea de “usarlo con sabiduría”.
En cuanto al segundo párrafo, cuando hablo de “ActivityPub”, me refería más a lo que permite/hace que al protocolo en sí. Me refiero a la idea de “compartir/enlazar contenido” o de “liberar el contenido de los límites de los servidores”, como tú lo expresas.
La idea de cierto cambio en el control/poder es interesante: ya no serían los dueños de la comunidad quienes controlan a “sus” usuarios, a “su” contenido (al menos el que alojan), a quién tiene acceso al llegar a su espacio, cómo se organiza y agrupa la información, etc. Los usuarios tendrían más control y más libertad para elegir lo que quieren, desde donde quieran, y crear su “propio menú”.
Puedo ver cómo esto puede ser atractivo desde la perspectiva del usuario, y cómo puede resultar un poco aterrador/preocupante desde la perspectiva del dueño de una comunidad.
Usando la analogía de un restaurante, coincido en que probablemente me excedí un poco al hablar de fusionar varios lugares, pero creo que tus analogías son demasiado suaves: es más de lo que describes, en mi opinión. Se trata de ir a un restaurante y poder pedir un plato de otro lugar, preparado por el chef de ese lugar. Esto puede plantear dudas (que fue gran parte de mi punto) sobre por qué el dueño del restaurante que paga bien a ese chef, y quizás tuvo dificultades para atraerlo y retenerlo, querría que ya no hubiera una razón clara para que los clientes vengan a SU restaurante. Tu respuesta es algo así como: es genial desde la perspectiva del cliente. Sí, claro, estoy de acuerdo.
Pero de todos modos, puedes tener razón en esto, y el punto que estoy planteando se parece bastante a los temores que tenían las empresas con el código abierto en el pasado.
@angus, recibimos noticias de la subvención NGI para apoyar el desarrollo de esta función y la oferta fue rechazada. Intentaremos solicitar otra subvención el próximo año.
¿Alguien puede resumir el estado actual (a partir del 22/11) de las ideas sobre la implementación de ActivityPub para Discourse? Después de revisar varios hilos relacionados, mi imagen actual es la siguiente:
Hubo un intento de obtener financiación de la UE en 2019 para el trabajo de implementación, pero la solicitud fue retirada por algunas razones.
Hasta ahora, no hay código (plugin) que pueda usarse para pruebas.
El personal/equipo principal de Discourse.org no tiene una posición común sobre la necesidad de un “discourse federado”.
¿Es correcta esta imagen? Trabajo con un partido político importante en Alemania y realmente podríamos necesitar algún tipo de discurso descentralizado donde las notificaciones de actividad se compartan entre instancias. Por lo tanto, estoy interesado en el estado actual de estas ideas…
Sí, basándonos en el OP, los feeds RSS son probablemente la mejor solución para tener un feed universalmente agregado de Internet. Y con sitios como rss.app y movimientos como openrss.org, puedes obtener prácticamente un feed RSS de cualquier sitio que quieras seguir hoy en día.
Estamos justo en medio de la discusión aquí y quizás todavía no he captado todos los aspectos de la discusión anterior.\n\nSi cambiamos de una configuración centralizada a una descentralizada con múltiples instancias de Discourse (deben alojarse en las instalaciones en Europa, AWS no es una opción), un tipo de mensajería de actividad de "servidor a servidor" permitiría a los usuarios iniciar sesión en un solo sistema y aún así obtener información sobre actividades interesantes de otro.\n\nEl correo electrónico está "superpoblado" y vemos una disminución en la cobertura de la información que fluye a través de "boletines estándar". ActivityPub (usando la API de servidor a servidor) permitiría recopilar información de diferentes fuentes en un "servidor preferido".\n\nLos feeds RSS son, de hecho, una posible solución, pero esto requiere registro/autenticación en diferentes servidores. Y trabajo manual con una tecnología diferente, la mayoría de los usuarios "no técnicos" no están familiarizados con eso.
Me encantaría invitar a la gente del fediverso a participar en mi servidor de Discourse de una manera más rica que el “oneboxing” manual.
Si bien uso un feed RSS (y, de hecho, lo uso para rastrear contenido nuevo en múltiples instancias de Discourse), un plugin saliente de ActivityPub / ActivityStream cumpliría con la gente donde ha estado yendo en masa, y ayudaría a aumentar la accesibilidad de la información en los foros de Discourse.
Reconozco que el equipo de Discourse no está de acuerdo fundamentalmente con esto, y esa es su prerrogativa. Una de las grandes fortalezas de Discourse es que, como un verdadero código abierto que se construye públicamente y no se lanza por la borda, no todos tenemos que estar de acuerdo.
Quizás los pensamientos sobre ActivityPub en Discourse necesiten madurar un poco más, tanto técnica como estratégicamente.
Espero que el actual “desastre de Twitter” obligue a más personas (especialmente a nivel político) a reflexionar sobre lo que está mal en su propia “soberanía digital”. Y, quizás, esto también incluya nuevas oportunidades para soluciones reales de código abierto en el área de las discusiones digitales públicas y comunitarias…
Hasta ahora hemos estado promoviendo ActivityPub en Discourse y hemos escuchado muchas voces tratando de explicar por qué necesitan ActivityPub… Pero no hemos escuchado al equipo de @Discourse por qué no quieren implementarlo. Cada argumento que se presentó intenté abordarlo con un enfoque plausible, pero al final no hay claridad sobre por qué los identificadores remotos cambiarían algo en los niveles de confianza, dado que las cuentas remotas aún pueden considerarse preparadas localmente y limitadas como los usuarios preparados ahora.
Hay varios hilos relacionados. Quería destacar que @sam dejó claro que mi caracterización aquí de que “el equipo de Discourse discrepa fundamentalmente de esto” era incorrecta o estaba desactualizada:
Esperaría que la razón por la que CDCK no está aplicando sus recursos a hacer este trabajo es que pocos de sus clientes de pago se preocupan por esto, o al menos lo priorizan sobre otro trabajo de características. Sospecho que hay mucho más interés comunitario que interés corporativo en este trabajo en este momento y en el futuro previsible. Si CDCK asume este trabajo, los costos de oportunidad de no construir otras características que sus clientes están pidiendo podrían ser significativos. (No tengo conocimiento interno aquí).
Dado el comentario de Sam vinculado anteriormente, si a un grupo de desarrolladores de la comunidad de Discourse les importa lo suficiente como para construir un plugin, esperaría que CDCK invierta en cooperar con esos desarrolladores para revisar y fusionar cualquier cambio central necesario para que ese plugin sea efectivo. Mi experiencia con las pequeñas contribuciones que he hecho a Discourse es que han priorizado el esfuerzo para revisar y ayudar con el trabajo que no habrían priorizado hacer ellos mismos.
Siendo simplemente un usuario de Discourse (alojando una instancia menor) y uno reciente, no tengo nada concreto que ofrecer en términos de cómo abordar esto técnicamente. Pero noté que WordPress, a través de su plugin, se está convirtiendo en una presencia importante en el fediverso. A febrero de 2023, hay más de 750 sitios web federados, lo que ya es más que muchas plataformas de federación dedicadas. Por lo tanto, existe el potencial de hacer que todas las comunidades de Discourse (que lo deseen) formen parte de algo más integrado “mágicamente”. La principal advertencia es que (muy probablemente) los protocolos de federación evolucionarán con una mayor adopción, por lo que esto sería realmente un compromiso para que la funcionalidad relacionada evolucione junto con ellos.
