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

Nell’ActivityPub Support: Phase 1 RFC ho delineato un esercizio di ideazione per valutare il caso d’uso aziendale per il supporto di ActivityPub in Discourse, pensando oltre un MVP come se Discourse fosse stato costruito da zero con la federazione in mente:

Quindi, con questo, avvierò l’ideazione con un brainstorming, senza tenere conto delle pratiche tecniche date dall’attuale codebase. Sono consapevole che ci sono molti aspetti e casi limite in tutto questo. Questa è una visione di come potrebbe apparire il supporto nativo alla federazione. Si parte..

La comunità non ha confini

(Foto di Pixabay da Pexels)

Condividiamo tutti un unico pianeta :wink: mescolandoci in strutture sociali complesse. Perché una comunità Discourse è limitata a un singolo forum?

Sono amministratore della Comunità per la Tecnologia Umanistica (HTC) e copriamo un’ampia gamma di argomenti tecnologici, con (sotto)categorie come «Libertà > Privacy», «Allineamento > Etica», «Allineamento > Standard». Forse troppo ampio, e esistono molti altri forum Discourse specializzati in queste categorie, che in quel campo fanno un lavoro migliore del nostro. Ma per le persone interessate a ottenere una panoramica di tutto il campo della tecnologia umanistica, il posizionamento ampio ha senso.

Federare le categorie

E se potessi federare la nostra sottocategoria «Privacy» con, ad esempio, la sottocategoria «Post del Blog» del forum PrivacyTools? Forse solo per sincronizzare gli argomenti in una direzione, dato che la sottocategoria sulla privacy di HTC ha un ambito più ampio: gli argomenti creati su PrivacyTools apparirebbero sul forum HTC, e i nostri membri potrebbero interagire con essi. I post degli argomenti sul forum HTC verrebbero poi trasferiti all’argomento su PrivacyTools e viceversa. Gli argomenti su entrambi i forum vengono mantenuti sincronizzati. Forse voglio anche sincronizzare in una direzione più sottocategorie di PrivacyTools verso «Privacy» su HTC. E perché non sincronizzare con diverse comunità relative alla privacy in modo simile.

Un altro esempio. Sia Feneas che SocialHub condividono una categoria di livello superiore «ActivityPub». C’è sovrapposizione tra queste, duplicazione, membri di una comunità ignari di ciò che sta accadendo nell’altra comunità. Questa è un’opportunità in cui «ActivityPub» è un candidato per la sincronizzazione bidirezionale, dove ogni forum contiene quindi le stesse liste di argomenti.

Federare tag e singoli argomenti

Lo stesso può valere per i tag, dove un tag particolare è configurato per essere federato. Questo potrebbe essere, ad esempio, impostato in modo che qualsiasi argomento con il tag #specification su SocialHub sia federato alla sottocategoria «Allineamento > Standard» su HTC.

Gli argomenti possono anche essere federati su base caso per caso, attivati da un comando della barra degli strumenti, dove si specifica il forum di destinazione a cui federare e, forse, si seleziona anche la categoria remota sotto cui deve apparire l’argomento (cioè l’elenco delle Categorie del forum è anche federato per la navigazione remota).

Menzioni dei membri e visualizzazioni del profilo

Quando un argomento è federato a un altro forum, qualsiasi menzione all’interno deve essere adattata per riflettere dove risiede il membro. Il mio handle @aschrijver su HTC potrebbe apparire come @aschrijver@humanetech sul forum SocialHub dopo la sincronizzazione.

Poiché sono anche un utente su SocialHub, nelle impostazioni del profilo potrei collegare gli account, e dopo una verifica ciò significa che negli argomenti sincronizzati il mio handle dell’account locale può essere mostrato.

Cliccando su un handle remoto o sull’avatar di un membro, viene visualizzata la scheda del profilo del forum remoto. Cliccando di nuovo per vedere il riepilogo del profilo, potrebbe mostrare solo le metriche di attività sul forum locale che derivano dall’interazione con gli argomenti sincronizzati. In alternativa, e più interessante, mostrerebbe riepiloghi da tutti i forum noti che fanno parte della configurazione di federazione. Ad esempio, potrei scoprire che la risposta proviene da un membro molto attivo ed esperto dell’altro forum.

Messaggi diretti e notifiche

I DM sarebbero possibili su tutti i forum federati, non solo localmente, taggando/menzionando il membro remoto nel DM. A parte questo, non ci sarebbe alcuna differenza nel modo in cui avviene la comunicazione DM. Funziona allo stesso modo dei DM locali attuali.

Da tutte le funzionalità di federazione descritte sopra sorge la necessità di federare anche le notifiche. Se rispondo al post di un membro remoto, mi piace il suo post o lo menziono in un thread di argomento sincronizzato, una notifica UI potrebbe apparire sul forum remoto per avvisare il membro. Le notifiche via e-mail sono gestite anche dal forum remoto. Tuttavia, se il membro ha account collegati su entrambi i forum, le notifiche potrebbero provenire dal forum locale dove è avvenuta per prima l’interazione.

Single Sign-On (SSO)

Si noti che in tutte le funzionalità descritte finora, non c’è bisogno di avere SSO. Un membro remoto non ha accesso privilegiato automatico a un altro forum federato. Quindi, cosa succede se viene menzionato in un thread di argomento sincronizzato in una direzione? In tal caso, riceverà una notifica UI e un’e-mail provenienti dalla propria istanza del forum, e cliccandoci sopra verrà reindirizzato all’altro forum (magari in una nuova scheda del browser) dove potrà semplicemente visualizzare l’argomento. Se vuole rispondere, deve prima registrarsi e collegare gli account, per poter rispondere.

Si noti che l’SSO è una cosa complicata sul Fediverse, che non ha ancora una buona soluzione. Ma per la federazione da Discourse a Discourse, la funzionalità SSO potrebbe essere molto più semplice da implementare. Se ci fosse un’integrazione SSO, cliccando sulla notifica si potrebbe aprire l’argomento nel contesto all’interno del forum corrente (come una «vista remota»), permettendo al membro di interagire con esso in modo trasparente.

Gestione della federazione e complessità

Tutto questo caso d’uso è descritto come se Discourse fosse stato costruito da zero con il supporto alla federazione integrato. Se tutto questo viene implementato, tocca quasi tutte le funzionalità del prodotto. A differenza del caso d’uso che ha avviato questo thread - per i feed personalizzati simili a FB - la federazione qui è gestita attentamente dallo staff del forum, non sull’impulso dei singoli membri.

Gran parte della configurazione della federazione è roba riservata solo agli amministratori. Dovrebbe essere fatta strategicamente e con un buon piano, per mantenere l’organizzazione della comunità e i contenuti intuitivi e logici. L’impostazione della federazione è costruita gradualmente nel tempo come parte del flusso di lavoro di costruzione della comunità, non qualcosa che viene aggiunto casualmente.

Interoperabilità

Certo, questa visione del supporto di ActivityPub non deve essere limitata a Discourse. Qualsiasi progetto software compatibile potrebbe diventare parte del tessuto comunitario distribuito. Ad esempio, il software open-source per la costruzione di comunità forem e la piattaforma di decisione collaborativa loomio, entrambi dei quali ho appena indicato nella direzione di questo post. Ma Discourse ha l’opportunità di prendere l’iniziativa in tutto questo.

Integrazione con il Fediverse

Tutto il supporto alla federazione finora era limitato al dominio aziendale del forum/comunità, ma con l’integrazione di ActivityPub l’interoperabilità può ora espandersi per abbracciare il più ampio Fediverse, abilitando numerosi casi d’uso aziendali entusiasmanti. Ne elenco solo alcuni che mi vengono in mente a caso:

  • Annunciare i post del forum su tutto il fediverse con toot sulle piattaforme di microblogging Mastodon / Pleroma.
  • Le immagini incorporate vengono caricate automaticamente su PixelFed e servite da lì (ottimo per le comunità come Blender).
  • La barra degli strumenti data/ora permette di impostare un evento completo Mobilizon rivolto al fediverse, con tutte le funzionalità RSVP.
    • L’integrazione è abilitata in due direzioni, dove le Discussioni Mobilizon sull’evento sono in realtà argomenti Discourse.
  • Creare argomenti PeerTube con funzionalità video speciali, dove i post sono il thread di commenti su PeerTube.
    • Lo stesso vale per Owncast se aggiungono il supporto AP (vedi questa issue).
  • Il tuo argomento pubblicato diventa automaticamente un post del blog Writefreely più un thread di commenti.
  • Incorpora parti del tuo forum in Nextcloud come app tramite il suo supporto ActivityPub.
  • Integra funzionalità podcast tramite Funkwhale (vedi il recente video sul supporto podcast).
  • Ottieni informazioni sul profilo da Flockingbird, rete sociale professionale in sviluppo (simile a LinkedIn).

E guarda il numero in costante crescita di app sulla ActivityPub Watchlist e lascia che la tua fantasia ti guidi :smiley:

Conseguenze

Dimentica per un momento tutti gli ostacoli e gli ostacoli tecnici e considera cosa significa avere tutto questo per Discourse come prodotto. O meglio, poiché Discourse non è più «solo un prodotto»: Discourse è diventato un tessuto comunitario distribuito.

Lo staff del forum non è più solo questo. Adottano una prospettiva molto più ampia sulla costruzione della comunità. Sia la comunità che i contenuti della comunità esistono in tutto il tessuto di Discourse. Lo staff guarderà attivamente ad altre istanze di Discourse, avvicinando il loro staff per forgiare partnership e creare interessanti design di federazione per tagliare e dividere la propria organizzazione comunitaria e i contenuti per renderli più interessanti per la base di membri della comunità.

Anche i membri della comunità sono molto meglio serviti. Contenuti più interessanti fluiranno verso il loro «portale» del forum e il forum sarà più attivo di quanto non lo sarebbe se fosse solo una cosa locale. I membri della comunità potranno scoprire e interagire con i membri di altre istanze di forum in tutto il tessuto. In realtà, il confine della comunità è stato rimosso: La comunità non ha confini.

17 Mi Piace

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

2 Mi Piace

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

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

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

@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

@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

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

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

(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

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

(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

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

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.

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

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

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:


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

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

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

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