ActivityPub Support: Phase 1 RFC

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.

@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 « J'aime »

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…

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.

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 « J'aime »

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.

@angus, nous avons eu des nouvelles de la subvention NGI pour soutenir le développement de cette fonctionnalité et l’offre a été rejetée. Nous essaierons de postuler à une autre subvention l’année prochaine.

2 « J'aime »

Ce serait plutôt génial.

2 « J'aime »

Quelqu’un peut-il résumer le statut actuel (au 22/11) des réflexions autour de l’implémentation d’ActivityPub pour Discourse ? Après avoir parcouru un certain nombre de fils de discussion connexes, mon image actuelle est la suivante :

  • une tentative a été faite pour obtenir un financement européen en 2019 pour les travaux d’implémentation, mais la demande a été retirée pour certaines raisons
  • à ce jour, il n’existe aucun code (plugin) pouvant être utilisé pour les tests
  • le personnel/l’équipe principale de Discourse.org n’a pas de position commune sur la nécessité d’un “Discourse fédéré”

Cette image est-elle correcte ? Je travaille avec un grand parti politique en Allemagne et nous pourrions vraiment avoir besoin d’une sorte de discours décentralisé où les notifications d’activité sont partagées entre les instances. Par conséquent, je m’intéresse à l’état actuel de ces idées…

5 « J'aime »

Oui.

Nous utilisons plusieurs instances Discourse pour travailler sur Discourse et les utilisateurs reçoivent des notifications centralisées via :

  • Notifications Push Web (disponibles sur Android, Windows, Linux, MacOS)

  • DiscourseHub (disponible sur iOS et Android pour les sites hébergés par nos soins)

  • Email (disponible partout)

Sans oublier la possibilité de s’abonner aux flux RSS, de synchroniser les signets avec votre calendrier via des points de terminaison .ics, etc.

Pourquoi auriez-vous besoin d’ActivityPub pour cela ?

5 « J'aime »

Oui, d’après le message original, les flux RSS sont probablement la meilleure solution pour avoir un flux universellement agrégé d’Internet. Et avec des sites comme rss.app et des mouvements comme openrss.org, vous pouvez pratiquement obtenir un flux RSS pour n’importe quel site que vous souhaitez suivre de nos jours.

3 « J'aime »

Nous sommes en pleine discussion ici et peut-être que je n’ai pas encore saisi tous les aspects de la discussion précédente.

Si nous passons d’une configuration centralisée à une configuration décentralisée avec plusieurs instances Discourse (elles doivent être hébergées sur site en Europe, AWS n’est pas une option), une messagerie d’activité de type « serveur à serveur » permettrait aux utilisateurs de se connecter sur un seul système et d’obtenir quand même des informations sur des activités intéressantes provenant d’un autre.

L’e-mail est « surchargé » et nous constatons une baisse de couverture pour les informations circulant via les « newsletters standard ». ActivityPub (utilisant l’API serveur à serveur) permettrait de collecter des informations de différentes sources sur un « serveur préféré ».

Les flux RSS sont en effet une solution possible, mais cela nécessite une inscription/authentification sur différents serveurs. Et un travail manuel avec une technologie différente, la plupart des utilisateurs « non techniques » ne la connaissent pas.

2 « J'aime »

J’aimerais inviter les gens du fediverse à participer à mon serveur Discourse d’une manière plus riche que le oneboxing manuel.

Bien que j’utilise un flux RSS (et, en fait, je l’utilise pour suivre le nouveau contenu sur plusieurs instances Discourse), un plugin sortant uniquement ActivityPub / ActivityStream rencontrerait les gens là où ils vont en masse, et aiderait à accroître l’accessibilité de l’information dans les forums Discourse.

Je reconnais que l’équipe de Discourse est fondamentalement en désaccord avec cela, et c’est leur prérogative. L’une des forces énormes de Discourse est que, en tant que véritable open source qui est réellement construit publiquement et non jeté par-dessus le mur, nous ne sommes pas tous obligés d’être d’accord. :smiling_face:

3 « J'aime »

Peut-être que les réflexions autour d’ActivityPub dans Discourse ont besoin d’un peu plus de maturité, tant sur le plan technique que stratégique.

J’espère que le « désastre Twitter » actuel forcera plus de gens (surtout au niveau politique) à réfléchir à ce qui ne va pas avec leur propre « souveraineté numérique ». Et, peut-être, cela inclura également de nouvelles opportunités pour de véritables solutions open-source dans le domaine des discussions numériques publiques et communautaires…

3 « J'aime »

Jusqu’à présent, nous avons fait pression pour ActivityPub dans Discourse et entendu de nombreuses voix essayer d’expliquer pourquoi elles avaient besoin d’ActivityPub… Mais nous n’avons pas entendu l’équipe @Discourse expliquer pourquoi elle ne voulait pas l’implémenter. J’ai essayé de répondre à chaque argument avancé avec une approche plausible, mais au final, il n’y a aucune clarté sur la façon dont les identifiants distants changeraient quoi que ce soit aux niveaux de confiance, étant donné que les comptes distants peuvent toujours être considérés comme staged localement, et limités comme le sont actuellement les utilisateurs staged.

Il existe plusieurs fils de discussion connexes. Je voulais souligner que @sam a clairement indiqué que ma caractérisation ici selon laquelle « l’équipe de Discourse est fondamentalement en désaccord avec cela » était erronée ou obsolète :

Je m’attendrais à ce que la raison pour laquelle CDCK n’alloue pas ses ressources à ce travail soit que peu ou pas de leurs clients payants s’en soucient, ou du moins le priorisent par rapport à d’autres travaux de fonctionnalités. Je soupçonne qu’il y a beaucoup plus d’intérêt communautaire que d’intérêt corporatif pour ce travail à l’heure actuelle et pour l’avenir prévisible. Si CDCK entreprend ce travail, les coûts d’opportunité liés au non-développement d’autres fonctionnalités demandées par leurs clients pourraient être importants. (Je n’ai aucune connaissance interne à ce sujet.)

Compte tenu du commentaire de Sam lié ci-dessus, si un groupe de développeurs de la communauté Discourse tient suffisamment à construire un plugin, je m’attendrais à ce que CDCK investisse dans la coopération avec ces développeurs pour examiner et fusionner toute modification de base nécessaire pour rendre ce plugin efficace. Mon expérience avec les petites contributions que j’ai apportées à Discourse est qu’ils ont priorisé les efforts pour examiner et aider au travail qu’ils n’auraient pas priorisé eux-mêmes. :heart:

7 « J'aime »

Étant simplement un utilisateur de Discourse (hébergeant une instance mineure) et un utilisateur récent, je n’ai rien de concret à offrir en termes d’approche technique. Mais j’ai remarqué que WordPress, via son plugin, devient une présence majeure dans le fediverse. En février 2023, plus de 750 sites web fédèrent, ce qui est déjà plus que de nombreuses plateformes de fédération dédiées. Le potentiel est donc là pour que toutes les communautés Discourse (qui le souhaitent) fassent partie de quelque chose de plus intégré, “comme par magie”. Le principal inconvénient est que (très probablement) les protocoles de fédération évolueront avec plus d’adoption, ce serait donc un véritable engagement pour que la fonctionnalité associée évolue en conséquence.

2 « J'aime »

@SeriousFun01 lire Federation support for Discourse - #87 by angus et les publications suivantes pour une mise à jour ici. :tada:

3 « J'aime »