La community non ha confini: Discourse-as-a-Fabric - ideazione e brainstorming

Comunità
1

In ActivityPub Support: Phase 1 RFC I outlined an ideation exercise to evaluate the business case for having ActivityPub support in Discourse, and think beyond a MVP as-if Discourse was built from the ground up with federation in mind:

So hereby I will kick off the ideation with some brainstorming and without taking technical practicalities into account given current codebase. I realize there are many ins and outs and edge cases to all of this. This is a vision of what native federation support might look like. Here goes..

Community has no boundary

pexels-pixabay-262488
pexels-pixabay-2624883648×2736 924 KB

(Photo by Pixabay from Pexels)

We all share one planet :wink: intermingling in complex social structures. Why is a Discourse community restricted to a single forum?

I am admin of Humane Tech Community (HTC) and we cover a broad range of tech-related subject areas, having (sub)categories of “Freedom > Privacy”, “Alignment > Ethics”, “Alignment > Standards”. Too broad maybe, and many other Discourse forums exist that specialize on these categories, and in that field do a better job than we do. But for people interested in getting an overview of the entire field of humane technology the broad positioning makes sense.

Federating categories

What if I could federate our “Privacy” subcategory with e.g. the “Blog Posts” subcategory of the PrivacyTools forum? Maybe to only synchronise topics in one direction - as HTC’s privacy subcategory is broader in scope - where topics created at PrivacyTools appear on the HTC forum, and our members can interact with them. Topic posts on HTC forum are then transferred back to the topic at PrivacyTools and vice versa. The topics on both forums are kept in sync. Maybe I even want to one-way synchronize multiple PrivacyTools subcategories to “Privacy” at HTC. And why not sync with different privacy-related communities in a similar way.

Another example. Both the Feneas and SocialHub share a top-level “ActivityPub” category. There’s overlap in these, duplication, members from one community unaware of what is happening in the other community. This is an opportunity where “ActivityPub” is candidate for bidirectional synchronisation, where each forum then contains the same topic lists.

Federating tags and individual topics

Same can apply for tags, where a particular tag is configured to be federated. This might be e.g. set up such that any topic with #specification tag in SocialHub is federated to “Alignment > Standards” subcategory on HTC.

Topics may also be federated on a case-by-case basis, triggered by a toolbar command, where you specify the target forum to federate to, and maybe also select the remote category that the topic should appear under (i.e. the forum Category list is also federated for remote browsing).

Member mentions and profile views

When a topic is federated to another forum, any mentions within need to be adapted to reflect where the member resides. My @aschrijver handle at HTC might appear as @aschrijver@humanetech on the SocialHub forum after synching.

Since I am also a user on SocialHub in my profile settings I might connect the accounts, and after a verification this means that in the synched topics my local account handle can be shown.

When clicking a remote handle or member avatar the profile card of the remote forum is displayed. When clicking again to see the profile summary, it may show only the activity metrics on the local forum that resulted from synched topics interaction. Alternatively, and more interrestingly, it would show summaries from all known forums that are part of the federation config. E.g. I would then be able to find out that the response came from a very active, expert member on the other forum.

Direct messages and notifications

DM’s would be possible across all federated forums, not just locally, by tagging/mentioning the remote member in the DM. Other than that there would be no difference in the way that DM communnication takes place. It works the same as current local-only DM’s.

From all the federation stuff described above arises the need to also federate notifications. If I respond to a remote member’s post, like their post, or mention them in a synched topic thread, a UI notification may appear in the remote forum to notify the member. Email notifications are handle by the remote forum as well. However, if the member has linked accounts on both forums the notifications might be coming from the local forum where the interaction first took place.

Single sign-on

Note that in all the functionality described thus far, there’s no need to have SSO. A remote member does not have automatic privileged access to another federated forum. So what if they are mentioned in a one-way synchronised topic thread? In that case they will receive a UI notification and email coming from their own forum instance, and when clicking that are directed to the other forum (maybe in a new browser tab) where they can just view the topic. If they want to respond they have to first sign up and link accounts, to be able to respond.

Note that SSO is a tricky thing on the Fediverse, that has no good solution yet. But for Discourse-to-Discourse federation the SSO facility may be much easier to implement. If there were SSO integration, then clicking the notification might open the topic in-context within the current forum (as a ‘remote view’), and allow the member to interact with it seamlessly.

Federation management and complexity

This whole use case is described as-if Discourse was built from the ground up with federation support built-in. If all this is implemented it touches nearly all features of the product. Unlike the use case that started this thread - for FB-like personalized feeds - the federation here is carefully managed by forum staff, not on the whim of individual members.

Much of federation config is admin-only stuff. It should be done strategically and with a good plan, so as to keep the community organization and content intuitive and logical. The federation set up is built gradually over time as part of community-building workflow, not something that is casually added.

Interoperability

Of course this vision of ActivityPub support need not be restricted to Discourse. Any compatible software project could become part of the distributed community fabric. For instance forem’s open-source community building software and loomio collaborative decision-making platform, both of whom I just pointed in the direction of this post. But Discourse has the opportunity to take the lead in all this.

Fediverse integration

All of the federation support so far was limited to the forum/community business domain, but with ActivityPub integration interoperability can now expand to embrace the broader Fediverse, enabling numerous exciting business cases. Just to list some that randomly pop up with me now:

  • Announce forum posts fediverse-wide with toots on the Mastodon / Pleroma microblogging platforms.
  • Embedded images are auto-uploaded to PixelFed and served from there (nice for e.g. Blender communities).
  • Date/time toolbar allows setting up a full Mobilizon Event facing the fediverse, with full RSVP features.
    • Integration is 2-way enabled, where Mobilizon Discussions on the event are actually Discourse topics.
  • Create PeerTube topics with special video features, where the posts are the comment thread at PeerTube.
    • Same holds for Owncast if they add AP support (see this issue).
  • Your published topic automatically becomes a Writefreely blog post plus comment thread.
  • Embed parts of your forum into Nextcloud as an app via its ActivityPub support.
  • Integrate podcast features via Funkwhale (see recent video about podcasting support).
  • Obtain profile info from Flockingbird, professional social network under development (LinkedIn-like rolodex).

And look at the ever growing number of apps on the ActivityPub Watchlist and let your fantasy guide you :smiley:

Consequences

Forget for a moment all the technical hurdles and obstacles and consider what having this means for Discourse as a product. Or rather as Discourse no longer being ‘just-a-product’: Discourse has become a distributed community fabric.

Forum staff are no longer just that. They’ll adopt a much broader perspective to community-building. Both the community and community content exists all across the Discourse fabric. Staff will be actively looking at other Discourse instances, approaching their staff to forge partnerships and create interesting federation designs to slice and dice their community organization and content to be most interesting for the community member base.

The community members themself are also much better served. More interesting content will flow to their forum ‘portal’ and the forum will be more active than if it were just a local thing. Community members will be able to discover and interact with members of other forum instances all across the fabric. In fact the community boundary has been removed: Community has no boundary.

17 Mi Piace
Humanetech category layout
Forum owners, how do you "fight" Facebook groups?
ActivityPub Support: Phase 1 RFC
Using Discourse as a social media platform
Federation support for Discourse
ActivityPub Support: Phase 1 RFC
ActivityPub Support: Phase 1 RFC
2

Per essere onesti, ho solo dato una scorsa veloce, ma: quale problema stai cercando di risolvere con questa idea di tessuto?

2 Mi Piace
3

Prima di tutto, ho delineato una serie di possibilità senza restrizioni, da utilizzare come input per il brainstorming. Ma personalmente, ho due problemi su cui vorrei vedere dei miglioramenti: uno come membro della comunità e uno come facilitatore della comunità (personale attivo su 5 forum attualmente, dove pubblico occasionalmente contenuti incrociati):

  • Come membro della comunità, ho account su 15-20 forum Discourse, gestendo account (alcuni dimenticati) e password, e controllando quelli più popolari in modo alternato, sito per sito. Tutti questi hanno molte aree di contenuto sovrapposte, date le mie interessi. Ora, se mi chiedeste di unirmi al vostro fantastico forum sul mio argomento preferito, sarei comunque molto esitante a farlo e a creare un altro account.

  • Come facilitatore della comunità, ho un problema simile e correlato. La mia comunità potrebbe essere piccola, e potreste decidere di unirvi a quell’altra comunità con contenuti su argomenti simili e parzialmente sovrapposti. O viceversa. O forse non sapete nemmeno dell’esistenza di quell’altra grande comunità (magari io, come facilitatore della comunità, so che esiste, ma dedicherei un argomento fissato per informare i miei membri?).

Con il supporto alla federazione in atto, ci sarebbe un vantaggio reciproco per i facilitatori della comunità di cooperare in partnership e plasmare l’organizzazione dei forum per le nostre rispettive audience, trarre beneficio dai punti di forza reciproci. Nello specifico, questo comporterebbe:

  • La possibilità di fornire contenuti di qualità superiore selezionando le fonti più appropriate da federare.
  • Una base di membri più ampia – l’aggregato della federazione – e quindi più persone con cui avere discussioni interessanti.
  • Livelli di attività più elevati in tutte le istanze del forum che partecipano alla federazione, il che aiuta a trattenere i visitatori ricorrenti.

Tre aspetti – qualità, quantità e attività – che sono fondamentali per qualsiasi comunità di successo :slight_smile:

8 Mi Piace
ActivityPub Support: Phase 1 RFC
5

Sono d’accordo, può essere davvero un problema. Risolvo questo problema aggiungendo il feed RSS delle comunità Discourse e attivando le e-mail di riepilogo settimanali integrate.

5 Mi Piace
6

Ho appena finito di leggere “The Square and the Tower” di Niall Ferguson, un libro che esplora l’influenza delle reti sociali (connessioni sociali informali e spesso poco conosciute tra individui) nella storia mondiale. Non è un libro perfetto, ma rafforza costantemente il tuo punto secondo cui “la comunità non ha confini”. Le reti distribuite sono più resilienti, innovative ed egualitarie rispetto alle gerarchie. Discourse si descrive come “un reboot da zero, un tentativo di ripensare a cosa dovrebbe essere un forum di discussione moderno su Internet oggi, in un mondo di smartphone, tablet, Facebook e Twitter onnipresenti”. A meno che l’ambizione di Discourse non sia semplicemente di essere l’ultimo e migliore software per forum per un certo periodo, l’integrazione con ActivityPub è la strada più chiara per sfidare seriamente Facebook, Google, Twitter e altri, ribaltando le aspettative su ciò che una comunità online può essere.

8 Mi Piace
7

@aschrijver Certo, personalmente amo le idee e il ragionamento.

Questo sembra essere realizzabile abbastanza “facilmente”. Per la parte degli account, potresti utilizzare un Discourse principale che funga da provider SSO. Altri forum Discourse dovrebbero solo unirsi al sistema per creare una base utenti centrale: il tuo nome utente è riservato per te su tutti i Discourse che lo utilizzano. Idealmente, gli amministratori/proprietari dei forum si unirebbero alla creazione del proprio forum. Sarebbe possibile unirsi anche in seguito, dovresti “solo” risolvere tutti i doppi nomi utente che appaiono in quel momento: l’amministratore dovrebbe far cambiare il nome utente ai suoi utenti quando il nome è già in uso nel sistema.

Per la parte delle partnership, i plugin che utilizzano Matterbridge e/o l’API di Discourse dovrebbero essere in grado di fare tutto. Ci sarebbe da fare qualche sviluppo e affinamento di plugin qui.

In alternativa, per i nuovi forum, potrebbe esserci una soluzione per un approccio “multisito”: crea categorie su un Discourse principale (potrebbe essere lo stesso del provider SSO per l’idea sopra), e una categoria = un “forum”. Aggiustando alcune cose, potresti “bloccare” un po’ di persone all’interno della categoria, rimuovere i riferimenti alle principali “categorie” e riproporlo come diversi “forum”. Attivando le sottocategorie, ogni forum ha comunque 2 livelli di categorie. Ci sono degli aggiustamenti da lavorare, ma questo abilita direttamente una base utenti comune e la messaggistica privata inter-utente (sei sullo stesso Discourse!).

Puoi combinare i 2 approcci: avere forum ospitati sul Discourse principale e altri esterni che si collegano ad esso. Penso che tradurre la tua visione in realtà sia possibile abbastanza facilmente. Sono potenzialmente disposto a lavorare su questo se c’è interesse (avrei bisogno di qualche aiuto, però). Ho registrato il dominio webforum.link che può essere utilizzato per questo.

Nota (dopo aver visto il post precedente): ActivityPub è qualcosa di “aperto”. Le idee sopra sarebbero molto più “chiuse” e limitate ai forum Discourse. Non sarebbe nemmeno così facile unirsi.

3 Mi Piace
8

@aschrijver, facendo seguito al nostro scambio di post su ActivityPub Support: Phase 1 RFC - #50 by Mevo e cercando anche di portare la discussione qui (questo è un argomento più appropriato):

C’è una cosa che ho trovato piuttosto interessante di recente: alcune persone hanno creato un marketplace gratuito e decentralizzato chiamato Openbazaar. L’idea era fondamentalmente avere qualcosa di totalmente aperto, dove chiunque potesse mettere in vendita qualsiasi cosa, senza alcuna possibilità di restrizione o censura. Si basa sulle criptovalute per i pagamenti, ed è possibile recensire i venditori e c’è un sistema di moderatori per arbitrare eventuali transazioni che vadano storte o presentino problemi. ZERO COMMISSIONI sulle transazioni, il tutto è al 100% gratuito (ci sarebbe una piccola commissione per il moderatore che deve intervenire, se necessario).

Insomma, sulla carta, questa cosa è fantastica, a mio avviso. Eppure, non ha mai davvero decollato. D’altro canto, eBay o Amazon, che si prendono commissioni piuttosto alte su ogni singola transazione, funzionano benissimo.

Il punto è che avere qualcuno che controlla qualcosa, che ha un incentivo a farla funzionare perché ne trae profitto finanziario e che investirà verso questo obiettivo, solitamente rende le cose funzionare meglio rispetto a idee gratuite, aperte e nobili. Può essere molto triste, ma nella pratica, è questo che sembra accadere nella vita reale.

Mastodon ha soppiantato Facebook e Twitter? Lo farà mai? Gli utenti non sembrano stufi della quantità di pubblicità che devono subire su Facebook.

Comunque, mi sembra che tu non abbia preso in considerazione questo aspetto nella tua visione sulla federazione. Quindi, eccolo qui, perché tu possa forse considerarlo (o almeno esserne a conoscenza). Non significa che avere l’opzione di federare cose o instaurare partnership non sia una buona idea. Ma andare per la “federazione totale” potrebbe anche rimuovere l’appeal di gestire un software, che diventa solo un “nodo” e non è più qualcosa che controlli. È piuttosto diverso, almeno.

1 Mi Piace
9

L’evoluzione dell’utilizzo di una piattaforma non è lineare. Prendiamo l’esempio di Signal: Snowden disse «usate Silent o Signal» e l’app fece progressi. Rimase comunque una nicchia. Quando un Gafam ha gestito male la comunicazione ed Elon Musk ha detto «usate Signal», centinaia di migliaia di utenti sono arrivati perché hanno valutato simultaneamente gli stessi criteri e l’app di destinazione ha risposto alle loro esigenze.

Alcuni utenti potrebbero aver lasciato Twitter e Facebook di recente, senza grande copertura mediatica, perché il principale fornitore di reazioni nel loro feed ha visto i propri account cancellati.

Più il sistema diventa caotico sui social media, maggiore è la probabilità che gli utenti si impegnino simultaneamente in un massiccio «disinstalla app1, installa app2».

1 Mi Piace
10

Non sono sicuro che l’esempio di Signal sia davvero comparabile. Qui c’è una chiara funzionalità aggiunta e un MOTIVO per cui gli utenti dovrebbero usarla: «Usa comunicazioni crittografate in modo che ciò che dici rimanga privato e nessuno possa ascoltarlo». Si passerebbe da comunicazioni non crittografate a comunicazioni crittografate.

Ma quando si passa da una piattaforma «chiusa» e «isolata» a una «aperta», se pensiamo alla «federazione completa», porta davvero qualcosa agli utenti? Aggiunge davvero una funzionalità per loro? Alcuni potrebbero dire di sì, vedendo come partecipano a diverse comunità e come queste potrebbero essere aggregate (capisco bene quanto sia oneroso accedere a xx comunità diverse).. Ma allo stesso tempo, se tutti gli utenti si spostassero verso una singola comunità «chiusa» diventando dominante, per loro sarebbe praticamente la stessa cosa. Non sono sicuro che noterebbero la differenza o desidererebbero l’«apertura».

Le persone tengono al contenuto, alle interazioni e così via, ma importa loro come funziona tecnicamente e chi lo controlla? Il passaggio alla «federazione» è in qualche modo un passaggio dal CONCORRERE al CONDIVIDERE per le comunità. Potrebbero essere amici tra loro ed essere d’accordo nell’inviare utenti da una all’altra, ma competono ancora quando sono chiuse.

Il tuo secondo punto è interessante: una «federazione» potrebbe prevenire ban, cancellazione di account e censura? QUESTO potrebbe essere una funzionalità «aggiunta» per le persone. Attualmente con ActivityPub, immagino che si possa essere bannati dai singoli siti, ma si può continuare a pubblicare nel resto della federazione… purché il sito in cui ti sei registrato non ti banni? @aschrijver, sai come funziona? (Non conosco bene ActivityPub). Sei registrato a un livello federativo, o sei registrato su uno dei siti appartenenti alla federazione? Si può essere bannati a livello federativo? O è impossibile? (Si suppone che sia impossibile?)

@jibe-b La domanda non riguardava davvero il passaggio da app1 a app2, ma il confronto tra singole app chiuse e qualcosa di federato (qualcosa di aperto). Possono esserci anche singole app chiuse con forti politiche di libertà di parola che non bannano le persone (è molto facile dirlo a posteriori, ma il «fornitore di reazioni» avrebbe potuto prevederlo). Puoi garantire un ambiente senza ban decentralizzando totalmente e rimuovendo la possibilità di bannare da chiunque. Non credo che prevenire la censura fosse l’obiettivo iniziale di @aschrijver, però.

1 Mi Piace
11

(Ho citato dei brani per brevità). L’analogia del ristorante si rompe in questo punto. È come se fossi seduto a due tavoli contemporaneamente, in un ristorante più grande e “aggregato” con più persone con cui festeggiare. Quello che dici può essere vero, ma dipende interamente da come le cose vengono implementate.

Mentre il topic RFC di ActivityPub e il caso d’uso di @hellekin mettono gli individui in pieno controllo, nella mia descrizione sopra lascio la struttura della comunità interamente nelle mani dello staff della comunità. Loro stabiliscono partnership con altre comunità e potrebbero essere in grado di condividere solo sezioni trasversali della propria comunità basandosi sul consenso reciproco.

Pensavo che farlo sarebbe stato più nell’interesse di Discourse (l’azienda) così come dei gestori della comunità che si impegnano così tanto per costruire la propria identità e la propria base di membri. Cioè, sarebbe stato più un caso d’uso commerciale. Quindi lo staff rimarrebbe in pieno controllo e si occuperebbe anche di mantenere l’organizzazione della comunità costitutiva completa e intuitiva. Sono gli “editori del tessuto della comunità”.

Se si permettesse piena libertà agli utenti di Discourse di riempire il loro ‘portale’ vuoto con contenuti di forum da ovunque, si otterrebbe una dinamica comunitaria completamente diversa. Il caso d’uso ha valore, per casi specifici, ma è completamente diverso dal caso d’uso in cui “lo staff mantiene il controllo”. Naturalmente, sono possibili anche tutte le sfumature di grigio intermedie.

Sì, ne sono a conoscenza e amo l’idea di OpenBazaar come mercato decentralizzato, tuttavia sono le criptovalute che mi hanno dissuaso dal provarlo. È una questione di fiducia. Per molte persone, questo potrebbe averle trattenute. Ma a parte questo, sono gli enormi effetti di rete delle Big Tech consolidate a rendere molto difficile l’ingresso ai nuovi arrivati, che lanciano un nuovo servizio, lo pubblicizzano su siti con milioni di visitatori giornalieri e riescono a operare in perdita fino a quando il progetto non decolla finalmente.

Sì, sono d’accordo su questo. È il motivo per cui non mi sono concentrato sulla “piena libertà”, ma piuttosto sul caso d’uso dello “staff in controllo”, come descritto sopra. Dove il supporto di ActivityPub aggiunge un USP a Discourse come prodotto per i gestori della comunità, i clienti paganti. Bene… se scelgono un abbonamento ospitato nel cloud, s’intende.

In tal senso, Discourse (l’azienda) potrebbe rendere gli abbonamenti più interessanti fornendo servizi a valore aggiunto, come un servizio di scoperta e matchmaking in cui i gestori della comunità di diverse comunità cercano attivamente partnership e cooperazioni per arricchire le loro comunità (e implicitamente quelle reciproche). Il servizio potrebbe essere accessibile a chiunque o solo ai clienti di un piano a pagamento.

Dovrebbero volerlo? Perché dovrebbe essere l’obiettivo? ActivityPub come protocollo permette a molte applicazioni diverse in molti domini diversi di interoperare a qualsiasi livello. Ogni progetto / app / prodotto perseguirà i propri obiettivi e, per il software commerciale, i propri USP.

La prima parte è importante. Scegli la tua federazione con saggezza. La piena federazione non dovrebbe mai essere l’obiettivo se perdi tutta la tua identità come prodotto facendolo.

Prima di tutto, c’è una differenza tra “federazione” e “il fediverso”. Se costruisci una federazione utilizzando ActivityPub, puoi farla funzionare in qualsiasi modo desideri. Se la costruisci con l’obiettivo di integrarsi con il Fediverso, allora ci sono alcuni standard de facto consolidati su come funzionano le cose. Un ban a livello di utente su tutto il fediverso non è possibile, e i ban su istanze specifiche si basano sulle decisioni dei moderatori di ogni singola altra istanza e sono configurati nelle liste di blocco e di permesso. Queste liste sono spesso condivise (come le liste dei blocchi pubblicitari) e possono portare al blocco completo di certe istanze in tutto il fediverso (“sono spinte ai margini del fediverso”).

Un buon video che spiega il concetto è:

Come i forum, ogni istanza federata nel Fediverso è moderata. E penso che sia una cosa buona. C’è ancora piena libertà, perché puoi avviare la tua istanza di forum/server senza moderazione dove tutto è consentito. Altri hanno la libertà di bloccarti in base a questo.

4 Mi Piace
12

Delegare la gestione della community

Dato che si tratta di un brainstorming libero e ho appena visto questo argomento Richiesta di volontari Community Manager :mega:   … ho pensato:

→ E se la gestione della community fosse federata?

Sei un nuovo community manager su un forum Discourse appena installato, un completo neofita dell’interfaccia di amministrazione e delle pratiche di costruzione della community. E se potessi chiamare l’aiuto di un community manager esperto per un certo periodo di tempo per darti consigli e controllarti da vicino?

So che direte: “Perché non creare semplicemente un account staff su quel forum.. non serve alcuna federazione!” e avreste ragione. Ma capovolgiamo la situazione e rendiamola forse più interessante: E se volessi offrire le mie competenze su Discourse e nella gestione della community sia come volontario che come professionista (cioè a pagamento)?

Vorrei poter gestire in modo produttivo il maggior numero possibile di community nel mio ‘portafoglio clienti’. Questo porta a un triplice vantaggio:

  • I nuovi community manager possono ottenere un servizio di onboarding per iniziare più rapidamente.
  • I community manager possono beneficiare più ampiamente delle loro competenze, oltre alla loro stessa community.
  • I due punti precedenti significano che Discourse ha aggiunto un altro USP (Unique Selling Proposition) al proprio prodotto.

Come potrebbe apparire allora? Non lo so.. molte possibilità. Alcuni suggerimenti, in ciascuno dei quali l’amministratore delegato lavora dal proprio portale forum tramite federazione, gestendo potenzialmente molte community:

  • L’amministratore delegato può impostare le Impostazioni del forum, installare plugin/componenti/css, che il vero amministratore approva prima che entrino in vigore.
  • L’amministratore delegato ha accesso a categorie e gruppi riservati allo Staff e partecipa alle discussioni per dare i propri consigli.
  • L’amministratore delegato gestisce i segnalazioni sollevate nel forum, dove solo l’argomento con la segnalazione viene federato al suo portale.
  • L’amministratore delegato, conoscendo il panorama delle community, aiuta a organizzare partnership con altre community e la condivisione di contenuti.

Considera quanto sopra quanto segue:

Questo potrebbe essere anch’esso un servizio a valore aggiunto e può essere combinato con quanto sopra. Tutte le parti coinvolte hanno interesse a verificare che gli amministratori delegati siano buoni community manager fino a un certo punto. Discourse (l’azienda) potrebbe permettere alle persone di diventare amministratori delegati solo se sono su un abbonamento (a pagamento?). Discourse o un partner potrebbero offrire un corso di gestione della community che, una volta superato, rilascia un certificato con il timbro di approvazione di @codinghorror.

Bene.. che ti piaccia l’idea o no. È stata una bella sessione di brainstorming per me, ha ha :grinning_face_with_smiling_eyes:
Forse puoi renderla migliore?

Modifica:

Discourse stesso utilizzerebbe questo servizio. All’inizio del nostro abbonamento a pagamento, un membro del team di Discourse faceva parte dello staff del nostro forum per offrire lo stesso tipo di aiuto. In questo modo possono farlo dal proprio remoto ‘cockpit’, o.. delegarlo.

Un’altra cosa che riguarda la condivisione di parti di una community.. Più volte quando ho pubblicato un argomento su Meta chiedendo aiuto specifico, l’argomento è stato reso privato (a volte perché conteneva informazioni sensibili) e gestito come un ‘biglietto di supporto’ dal team di Discourse. Con la federazione potrei avere la parte di Supporto di Meta integrata nel mio stesso forum.

4 Mi Piace
13

(Formattazione mia). Mi piace davvero questa definizione, @JE-FF, e si adatta perfettamente all’approccio innovativo da adottare con i concetti di ‘la comunità non ha confini’ e ‘discourse come tessuto’. Tuttavia, dubito, come ho anche detto a @Mevo, che Discourse voglia davvero sfidare i social media delle Big Tech. Potrebbero farlo se volessero, ma non c’è bisogno. Discourse è già di per sé piuttosto di successo ed è posizionato diversamente oggi, ovvero come SaaS multi-tenant, una ‘nuvola di forum di comunità indipendenti’. Tuttavia, estendendo i concetti di comunità oltre i confini dei tenant, potrebbero essere meglio posizionati contro i loro rivali, sia nello spazio dei forum che in quello dei social media.

2 Mi Piace
14

Un grande grazie, @aschrijver. È molto chiaro e, onestamente, sono quasi d’accordo con te su tutto ciò che hai detto. Ho scritto i miei messaggi con l’idea che ciò che proponevi fosse un “passo intermedio” con la “federazione completa (e totalmente aperta)” come obiettivo finale. Ora non sono nemmeno sicuro da dove derivi questa idea, e potresti non aver mai detto nulla del genere. Potrebbe essere un fraintendimento (e un’idea inventata) da parte mia, o forse ho mescolato cose dette da altre persone.

ActivityPub per tutto ciò che potrebbe permettere di fare, mentre puoi comunque scegliere come gestire le cose: sì, tutto questo mi sembra fantastico. Immagino tu abbia ragione: potrebbe esserci confusione tra ActivityPub e Fediverso (l’hai già spiegato nell’altro argomento su ActivityPub).

Personalmente, amo tutte le idee che hai portato. Per quanto riguarda la “gestione della comunità” federata, potrebbe essere molto utile avere accesso a moderatori in questo modo. Moderatori che potresti utilizzare temporaneamente quando la tua comunità si scalda, o quando c’è, ad esempio, un evento speciale che richiede più moderatori (tutto ciò era forse incluso nel concetto di “gestione della comunità” nella tua mente. Hai parlato di segnalazioni, ma potresti avere accesso anche a più persone di tipo “amministratore”, oltre ai “moderatori” o ai “community manager”, se definisci questi compiti come diversi).

Come è stato detto in precedenza, tutto questo può essere realizzato “a parte” tramite plugin e/o un sito secondario (potrebbe esserci un sito secondario di “freelance” che elenca e propone servizi con persone che lavorano direttamente nella comunità. Non è bello come avere la propria piattaforma da cui gestire tutto da remoto e in modo aggregato grazie a ActivityPub, ma sarebbe già un buon inizio).

Tutto dipende se il team di Discourse vorrà utilizzare alcune di queste idee per implementarle direttamente in Discourse o meno.

4 Mi Piace
15

Non sono d’accordo. Ho utilizzato configurazioni multi-sito per facilitare la proprietà di gruppo di un’istanza Discourse, in cui un gruppo ristretto può diventare parte dello Staff mantenendo un collegamento diretto con la comunità più ampia. Secondo me, giocare con i confini della comunità la potenzia applicando il principio di sussidiarietà: le decisioni vengono prese il più vicino possibile alla pratica.

16

Innanzitutto, sembri interpretare ciò che ha detto come 'gli utenti si comporteranno male senza un certo

17

Sì, si trattava principalmente di mostrare quanto ampio sia l’arco delle opzioni disponibili e la piena flessibilità per adattarsi a scenari specifici. Se mi concentro esclusivamente sul ‘pallone’ di ActivityPub, ciò consente all’implementatore delle funzionalità di federazione il pieno ‘controllo del pallone’. I casi d’uso implementati sono tutti ugualmente validi (assumendo che siano stati progettati deliberatamente come parte dello sviluppo del prodotto).

Vedo che il caso di @hellekin non rientra effettivamente nell’estremo della piena libertà, e sarebbe interessante approfondire ulteriormente. @hellekin gestisce più forum di me, e in modo creativo, come si può vedere sul forum SocialHub, dove i singoli team di software ActivityPub hanno il controllo delle proprie sezioni del forum. Questi team spesso dispongono anche di un altro forum indipendente (ad esempio, nel caso di Mastodon). È necessario incoraggiarli a svolgere il ‘doppio lavoro’ per mantenere la comunità AP aggiornata sulle estensioni di federazione personalizzate che integrano nei propri software. Oltre a ciò, SocialHub ospita, per così dire, forum satelliti.

3 Mi Piace
18

Ho appena deciso di registrarmi su un altro forum Discourse, solo per aiutarli e fornire (copiando e incollando) alcuni suggerimenti utili su argomenti di altri forum. Ancora un altro account utente Discourse da gestire.

Il forum è Fedeproxy, un nuovo progetto ActivityPub che mira a sincronizzare tra loro le forge di codice (repository di Github, Gitlab, Gitea, ecc.). Potrebbe diventare un’implementazione del protocollo Forgefed ed è interessante menzionarlo qui per due motivi:

  1. Questo è un ulteriore esempio di un dominio aziendale completamente diverso che può trarre grande beneficio dalla federazione ActivityPub.
  2. Se Discourse avesse il supporto per la federazione, la categoria #development di questo forum potrebbe essere sincronizzata bidirezionalmente con la sottocategoria #software di SocialHub, senza la necessità di lavorare su due forum e duplicare le discussioni.

Aggiornamento:

Sul forum Fedeproxy, un utente (che peraltro non ha voluto registrarsi qui, solo per lasciare un unico post) mi ha indicato un’ontologia Linked Data interessante per le comunità, la Specificazione dell’ontologia core SIOC, dove il progetto SIOC sta per “Comunità online semanticamente interconnesse”. L’ontologia definisce le seguenti semantiche in Linked Data:


semantically-interlinked-online-community-ontology
semantically-interlinked-online-community-ontology600×379 30.1 KB

Lo menziono qui perché evidenzia il pensiero in termini di dominio aziendale e vocabolari e può essere un’ispirazione per il brainstorming :slight_smile:

(PS. Non fatevi fuorviare dal termine “Web Semantico” nelle specifiche SIOC. Non è di questo che si tratta – troppo complesso – ma piuttosto dalla ricerca di vocabolari Linked Data chiusi per definire un particolare dominio.)

Aggiornamento 2:

Oggi ho scoperto un ottimo progetto, anch’esso in un dominio simile a quello di Discourse, e ho avviato lì una discussione intitolata “La comunità non ha confini”:

PubPub fa parte del Knowledge Futures Group, che sta anche lavorando al progetto Open Distributed Knowledge Graph Underlay (che si avvicina a un’idea che ho per l’aggregazione di conoscenze dai forum Discourse).

Aggiornamento 3:

Mi sono reso conto che la discussione sulla Comunità è molto più ampia di Discourse da solo, poiché i concetti di comunità sono così universali nella nostra società. Per il Fediverse ho avviato una discussione sulla standardizzazione di un dominio Community e sulla modellazione di un’estensione ActivityPub basata su di esso:

7 Mi Piace
19

ActivityPub è una buona idea, ma anche software di nuova implementazione che lo adottano come componente di primo livello devono colmare diverse lacune nelle specifiche. Quindi, per noi ha senso aspettare e vedere come evolverà la situazione.

Inoltre, è assolutamente fattibile realizzarlo come plugin, se si tratta di qualcosa per cui un gruppo particolare è particolarmente appassionato.

13 Mi Piace
20

Sarebbe fantastico vedere una tale integrazione richiesta tramite pull request nell’app chat-integration, così da poter semplicemente pubblicare cross-post per tag, categoria o menzione dopo aver aggiunto le nostre credenziali. Saluti!

7 Mi Piace
21

Grazie @codinghorror. Sì, è vero che nello specifico ActivityPub ci sono delle lacune. Ma sono presenti più o meno deliberatamente, sia perché gli autori della specifica non volevano creare uno standard tecnologico onnicomprensivo, enorme e complesso, sia perché, al momento della stesura, non sapevano come si sarebbe evoluta la specifica. Quindi hanno atteso implementazioni di riferimento (questo ha anche avuto alcuni svantaggi, ad esempio Mastodon utilizza un’API client personalizzata invece della parte Client-to-Server della specifica, ma Mastodon ha anche definito alcune utili estensioni di namespace da utilizzare).

Attualmente la maggior parte di queste lacune è stata colmata da altri standard aperti (anche se ce ne sono ancora alcune da colmare). Esistono le firme HTTP per la federazione Server-to-Server (o, meno utilizzate, le firme JSON-LD), mentre per le menzioni utente federate si utilizza Webfinger. Il Client-to-Server utilizza OAuth2 Client Credentials e esistono specifiche de facto come NodeInfo / NodeInfo2 per comunicare le capacità del server.

Sono d’accordo nel dire che un gran numero di cose discusse in questo thread (probabilmente la maggior parte) può essere implementato utilizzando i plugin e le eccellenti API di Discourse. Come dice @sunjam, sarebbe davvero fantastico se qualcuno si cimentasse in questo :slight_smile:

Sulla base di questo brainstorming, ho avviato alcune discussioni più generali sul forum SocialHub, a cui vorrei fare riferimento:

Aggiornamento 2021/03/07: Su SocialHub, nel topic sulla creazione di un’estensione AP per il vocabolario della comunità, ho approfondito come Discourse si inserirebbe in un modello di comunità. Vedi il mio post:

7 Mi Piace