ActivityPub Support: Phase 1 RFC

[hellekin]

@Mevo

@hellekin Pardon me, but I don’t really see the “use case” here. I mean, why do it, what the benefits are, etc.

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.

[Mevo]

@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?]

[hellekin]

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…

[Mevo]

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

@Mevo

Now, here, it’s a bit more evolved as the communities would stay kind of separated, but they are linked

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.

[aschrijver (Arnold Schrijver)]

@Mevo

There are lots of nightclubs, restaurants, […] 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?

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.

@Mevo

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

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.

@Mevo

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

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.

[Mevo]

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.

[hellekin]

@angus ho ricevuto notizie dalla sovvenzione NGI per supportare lo sviluppo di questa funzionalità e l’offerta è stata rifiutata. L’anno prossimo proveremo a fare domanda per un’altra sovvenzione.

[Pink2DS (Sandra Snan)]

@Falco

possiamo andare e implementare la stessa API che usa Lemmy

Sarebbe fantastico.

[Thomas_Rother (Thommie Rother)]

Qualcuno può riassumere lo stato attuale (al 22/11) delle idee sull’implementazione di ActivityPub per Discourse? Dopo aver esaminato una serie di thread correlati, il mio quadro attuale è questo:

• c’è stato un tentativo di ottenere finanziamenti dall’UE nel 2019 per il lavoro di implementazione, ma la domanda è stata ritirata per alcuni motivi
• ad oggi, non esiste codice (plugin) che possa essere utilizzato per i test
• lo staff/il team principale di Discourse.org non ha una posizione comune sulla necessità di un “discourse federato”

Questo quadro è corretto? Lavoro con un partito politico più grande in Germania e potremmo davvero aver bisogno di una sorta di discorso decentralizzato in cui le notifiche di attività vengono condivise tra le istanze. Pertanto, sono interessato allo stato attuale di queste idee…

[Falco]

@Thomas_Rother

Questa immagine è corretta?

Sì.

@Thomas_Rother

Lavoro con un partito politico più grande in Germania e avremmo davvero bisogno di una sorta di discorso decentralizzato in cui le notifiche di attività vengono condivise tra le istanze.

Utilizziamo più istanze di Discourse per lavorare su Discourse e gli utenti ricevono notifiche centralizzate tramite:

• Notifiche push web (disponibili su Android, Windows, Linux, MacOS)
• DiscourseHub (disponibile su iOS e Android per i siti nel nostro hosting)
• Email (disponibile ovunque)

Senza contare la possibilità di iscriversi ai feed RSS, sincronizzare i segnalibri con il calendario tramite endpoint .ics, ecc.

Perché avresti bisogno di ActivityPub per questo?

[kem5]

Sì, basandosi sull’OP, i feed RSS sono probabilmente la soluzione migliore per avere un feed universalmente aggregato di Internet. E con siti come rss.app e movimenti come openrss.org, puoi ottenere praticamente un feed RSS per qualsiasi sito che desideri seguire in questi giorni.

[Thomas_Rother (Thommie Rother)]

Siamo nel bel mezzo della discussione qui e forse non ho ancora compreso tutti gli aspetti della discussione precedente.

Se passiamo da una configurazione centralizzata a una decentralizzata con più istanze di Discourse (devono essere ospitate in locale in Europa, AWS non è un’opzione), un tipo di messaggistica di attività “server-to-server” consentirebbe agli utenti di accedere solo su un sistema e ricevere comunque informazioni su attività interessanti da un altro.

L’e-mail è “sovraffollata” e vediamo un calo di copertura per le informazioni che fluiscono attraverso “newsletter standard”. ActivityPub (utilizzando l’API server-to-server) consentirebbe di raccogliere informazioni da diverse fonti su un “server preferito”.

I feed RSS sono effettivamente una possibile soluzione, ma ciò richiede la registrazione/autenticazione su diversi server. E lavoro manuale con una tecnologia diversa, la maggior parte degli utenti “non tecnici” non ha familiarità con essa.

[mcdanlj (Michael K Johnson)]

Mi piacerebbe invitare le persone nel fediverso a partecipare al mio server Discourse in un modo più ricco del semplice “oneboxing” manuale.

Sebbene utilizzi un feed RSS (e, di fatto, lo utilizzi per monitorare nuovi contenuti su più istanze Discourse), un plugin ActivityPub / ActivityStream solo in uscita incontrerebbe le persone dove si stanno dirigendo in massa e contribuirebbe ad aumentare l’accessibilità delle informazioni nei forum Discourse.

Riconosco che il team di Discourse è fondamentalmente in disaccordo con questo, e questa è una loro prerogativa. Uno dei grandi punti di forza di Discourse è che, essendo un vero open source costruito pubblicamente e non “gettato oltre il muro”, non dobbiamo essere tutti d’accordo.

[Thomas_Rother (Thommie Rother)]

Forse i pensieri su ActivityPub in Discourse hanno bisogno di maturare un po’ di più, sia tecnicamente che strategicamente.

Spero che l’attuale “disastro di Twitter” costringa più persone (specialmente a livello politico) a ripensare a cosa c’è di sbagliato nella propria “sovranità digitale”. E, forse, ciò include anche nuove opportunità per vere soluzioni open-source nell’area delle discussioni digitali pubbliche e basate sulla comunità…

[hellekin]

Finora abbiamo spinto per ActivityPub in Discourse e abbiamo sentito molte voci cercare di spiegare perché hanno bisogno di ActivityPub… Ma non abbiamo sentito dal team di @Discourse perché non vogliono implementarlo. Ogni argomento che è stato presentato ho cercato di affrontarlo con un approccio plausibile, ma alla fine non c’è chiarezza sul perché gli identificatori remoti cambierebbero qualcosa nei livelli di fiducia, dato che gli account remoti possono ancora essere considerati staged localmente, e limitati come gli utenti staged ora.

[mcdanlj (Michael K Johnson)]

Ci sono più thread correlati. Volevo sottolineare che @sam ha chiarito che la mia caratterizzazione qui secondo cui “il team di Discourse è fondamentalmente in disaccordo con questo” era errata o obsoleta:

Federation support for Discourse

My general concern here is that the ideas are generally enormous, it is super hard to break them down into small pieces. I do find the idea of federating interesting. A possible concrete implementation could be: Allow Discourse admins to federate a category. Users on mastodon can then follow it, eg follow: announcements@meta.discourse.org When new announcement topics are created, a new post is federated with an excerpts and link to the original. As users respond on discourse, new replies are…

Mi aspetterei che il motivo per cui CDCK non sta impiegando le proprie risorse per fare questo lavoro sia che pochi o nessuno dei loro clienti paganti si preoccupano di questo, o almeno lo danno priorità rispetto ad altri lavori di funzionalità. Sospetto che ci sia molto più interesse della comunità che interesse aziendale in questo lavoro in questo momento e per il futuro prevedibile. Se CDCK intraprende questo lavoro, i costi opportunità nel non costruire altre funzionalità che i loro clienti stanno chiedendo potrebbero essere significativi. (Non ho conoscenze interne qui.)

Dato il commento di Sam collegato sopra, se un gruppo di sviluppatori della comunità Discourse ci tiene abbastanza a costruire un plugin, mi aspetterei che CDCK investa nella cooperazione con quegli sviluppatori per rivedere e unire eventuali modifiche principali necessarie per rendere efficace quel plugin. La mia esperienza con i piccoli contributi che ho apportato a Discourse è che hanno dato priorità allo sforzo di rivedere e aiutare con il lavoro che non avrebbero dato priorità a fare da soli.

[SeriousFun01]

Essendo semplicemente un utente di Discourse (ospitando una piccola istanza) e un utente recente, non ho nulla di concreto da offrire in termini di approccio tecnico. Ma ho notato che WordPress, tramite il suo plugin, sta diventando una presenza importante nel fediverso. A febbraio 2023 ci sono oltre 750 siti web che federano, un numero già superiore a molte piattaforme di federazione dedicate. Quindi il potenziale c’è per rendere “magicamente” tutte le community di Discourse (che lo desiderano) parte di qualcosa di più integrato. L’unico inconveniente è che (molto probabilmente) i protocolli di federazione si evolveranno con una maggiore adozione, quindi questo sarebbe davvero un impegno per far evolvere la funzionalità correlata di conseguenza.

[mcdanlj (Michael K Johnson)]

@SeriousFun01 leggi Federation support for Discourse - #87 by angus e i post successivi per un aggiornamento qui.