ActivityPub Support: Phase 1 RFC

Característica
45

There are many instances of Discourse. I don’t know exactly but I have accounts on a few dozens. It’s impossible to keep track of everything and many times I come across topics in distinct but no so different communities discussing similar issues, that could well be shared across instances since some of the participants are repeating themselves across discussions. It would really help to be able to share such topics across instances without having to login several times, cross-reference topics and not have a fluid discussion with interested parties.

Having ActivityPub users treated as staged users the same way emails users foreign to a Discourse instance are treated seems to be a good compromise to start with.

An RSS feed would certainly help you track ongoing topics at a single place but would not bring anything different from the Discourse Hub app, nor would it allow you to participate.

46

@hellekin I don’t know about this. Maybe you’re right, maybe you aren’t.
There are lots of nightclubs, restaurants, supermarkets, softwares, etc. Some are even pretty close. Geographically and/or in term of what they offer. Should one have the view that it’s “stupid” different places offering the same thing are separated? And these places should be merged to only have a centralized one?

Now, here, it’s a bit more evolved as the communities would stay kind of separated, but they are linked. Remains the question if all communities are the “same”: It is the same rules, the same atmosphere, the same kind of people, etc? This may be what makes a community a “special place” worth (actively) participating on: The fact that it’s unique. It has a unique vibe, a unique kind of humor going on, etc. A unique IDENTITY. People being a huge aspect of this: Who goes here or there. What kind of person.

Maybe this is a view on DIVERSITY: Mixing up everything, and ending up with something the “same” everywhere, because it’s so mixed up.

On the other hand, we have LINKS and QUOTES. Nothing prevents anyone from linking, quoting and summarizing what happens somewhere else. And here, you can keep the identity of each place, and not render everything the “same”.

Anyway, this may be the core questions behind the ActivityPub principle itself, and the willingness to implement it with Discourse. Of course, if it’s only optional, anyone can do as he wishes. and options are generally a good thing, IMHO (I’m not really sure why a successful community would want its content to be shared outside, and people to be able to interact with it from the outside).

[That’s a little some “Demolition man” thing where there are only Taco Bell restaurants left, isn’t it?]

1 me gusta
47

I’m not sure how your view relates to my previous post. I did not say anything about merging communities, simply some common topics. And even then I only suggested user accounts could be the proxy…

48

And isn’t this, “merging” the offerings of different communities? You still “merge” some content, even if, as said in the previous message:

There seem to be a unwillingness to do it from the Discourse team, and an unclear advantages/use case on top of this. If you don’t see how my previous post relates to the subject, then ok. My apologies. forget about it.

49

Absolutely not. But I would like to read about them in my local newspaper, or - in a more specialized case - an Italian gastronomy guide for connaisseurs. The fact that things are not all the same, are what makes it worth subscribing to them. Back to the web and communities, linking an quoting are valuable of course. But they are another use case, different than sharing a topic between forums and viewing the thread in context, maybe participate directly.

You are right that in some cases you don’t want to mix identities and certainly not completely merge dispersed communities altogether. But you may selectively merge only those parts where it makes sense. Be it on a topic-by-topic basis, certain (sub)categories, tags or specific groups of people sharing content.

It is not really about ActivityPub either. The protocol is quite low-level, building on top of HTTP. You can build anything with it. Very often when mentioning ActivityPub, people automatically tend to think of microblogging (Mastodon) as that is the most popular application until now. If you consider this domain, everyone is sort of creating their own ‘unique community’ with it, defined by who they follow. This creates their personal timeline. Other than that they may have chosen to create their account on e.g. mastodon.technology and their server timeline loosely has the theme “technology” to it. But this domain does not really fit Discourse, of course. It is microblogging, not community forums after all.

Currently some microblogging applications are extending their domain with the concept of Groups. You might see this as a community concept that extends across the server boundary. So while I’m on mastodon.technology I might subscribe to the “spaghetti” group, and “climate change”. But it is still just microblogging → everything is compressed and flattened into my timelines.

What is a succesful community? What are its bounderies, what is inside and outside? These may be very clearly defined, and relate to identity and diversity. One thing they do not relate to per se, are specific server boundaries!

Though I went very broad in Community has no boundary, it is thinking without these artificial server boundaries I addressed (and how that may increase quality, quantity and activity of the community. I did not go into identity, which is a good point to also address). Thanks for responding there @Mevo, I’ll reply in due time.

5 Me gusta
50

Thanks @aschrijver , this is very helpful.
I take from the first paragraph the idea to “use it wisely”.
About the second paragraph, I was referring more to the idea of what it enables/does, than the protocol itself, when talking about “ActivityPub”. The “sharing/linking content” idea, or “freeing the content from servers boundaries”, like you talk about it.

The idea of some kind of shift of control/power is interesting: It would not really be the community owners who control anymore “their” users, “their” content (what they host, at least), what people have access to when coming to their place, how information is organized and grouped, etc. The users would be more in control and more free to pick what they want, from where they want, and make their “own menu”.

I can see how this may be appealing from the user’s POV, and how it may be a little scary/worrying from a community owner POV.

Taking a restaurant analogy, I agree I was probably getting a little too far with my point of merging several places, but I think your analogies are too soft: It’s more than what you describe, IMHO. It’s going to one restaurant and being able to order a dish from another place, made by the chef of that place. It may raise questions (which was a big part of my point) as to why the restaurant owner who pays well that chef, and maybe had troubles to attract him and retain him, would want to NOT have a clear reason for customers to come to HIS restaurant anymore. Your answer is kind of: It’s great from a customer POV. Yes, sure, I agree.

But anyway, you may be right on this, and the point I’m making looks quite like the fears of companies with open source in the past.

51

@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.

2 Me gusta
52

Eso sería genial.

2 Me gusta
53

¿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…

5 Me gusta
54

Sí.

Usamos múltiples instancias de Discourse para trabajar en Discourse y los usuarios reciben notificaciones centralizadas a través de:

  • Notificación Push Web (disponible en Android, Windows, Linux, MacOS)
  • DiscourseHub (disponible en iOS y Android para sitios en nuestro hosting)
  • Correo electrónico (disponible en todas partes)

Sin mencionar la posibilidad de suscribirse a feeds RSS, sincronizar marcadores con tu calendario a través de puntos finales .ics, etc.

¿Por qué necesitarías ActivityPub para eso?

5 Me gusta
55

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.

3 Me gusta
56

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.

2 Me gusta
57

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. :smiling_face:

3 Me gusta
58

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…

3 Me gusta
59

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.

60

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. :heart:

7 Me gusta
61

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.

2 Me gusta
62

@SeriousFun01 lee Federation support for Discourse - #87 by angus y las siguientes publicaciones para una actualización aquí. :tada:

3 Me gusta