Esistono molte istanze di Discourse. Non so esattamente quante, ma ho account su diverse dozzine. È impossibile tenere traccia di tutto e spesso mi imbatto in argomenti in comunità distinte ma non troppo diverse che discutono di problemi simili, che potrebbero essere condivisi tra le istanze, dato che alcuni partecipanti si ripetono nelle discussioni. Sarebbe davvero utile poter condividere tali argomenti tra le istanze senza dover accedere più volte, incrociare i riferimenti degli argomenti e non avere una discussione fluida con le parti interessate.
Trattare gli utenti ActivityPub come utenti in fase di staging, allo stesso modo in cui vengono trattati gli utenti email esterni a un’istanza di Discourse, sembra un buon compromesso per iniziare.
Un feed RSS aiuterebbe certamente a tenere traccia degli argomenti in corso in un unico posto, ma non apporterebbe nulla di diverso rispetto all’app Discourse Hub, né permetterebbe di partecipare.
@hellekin Non saprei dire. Forse hai ragione, forse no. Ci sono moltissimi nightclub, ristoranti, supermercati, software, ecc. Alcuni sono persino piuttosto simili, geograficamente e/o per quanto riguarda l’offerta. Si dovrebbe ritenere “stupido” che luoghi diversi offrano le stesse cose e siano separati? E che questi luoghi dovrebbero essere fusi in un’unica entità centralizzata?
In questo caso, però, la situazione è un po’ più evoluta: le comunità rimarrebbero in qualche modo separate, ma collegate. Resta il dubbio se tutte le comunità siano davvero “uguali”: hanno le stesse regole, la stessa atmosfera, lo stesso tipo di persone, ecc.? Forse è proprio questo che rende una comunità un “luogo speciale” degno di una partecipazione attiva: il fatto di essere unica. Ha un’atmosfera unica, un tipo di umorismo peculiare, ecc. Una IDENTITÀ unica. Le persone sono un aspetto fondamentale di tutto ciò: chi viene qui o lì, che tipo di persona.
Forse questa è una visione della DIVERSITÀ: mescolare tutto e finire con qualcosa di “uguale” ovunque, proprio perché è troppo mescolato.
D’altra parte, abbiamo LINK e CITAZIONI. Niente impedisce a chiunque di collegarsi, citare e riassumere ciò che accade altrove. E in questo modo si può mantenere l’identità di ogni luogo, senza rendere tutto “uguale”.
Comunque, queste potrebbero essere le domande fondamentali alla base del principio di ActivityPub stesso e della volontà di implementarlo con Discourse. Certo, se è solo opzionale, ognuno può fare come preferisce. E le opzioni sono generalmente una buona cosa, a mio parere (non sono davvero sicuro del perché una comunità di successo vorrebbe condividere il proprio contenuto all’esterno e permettere alle persone di interagire con esso dall’esterno).
[È un po’ come in “Demolition Man”, dove sono rimasti solo i ristoranti Taco Bell, vero?]
Non sono sicuro di come la tua visione si relazioni al mio post precedente. Non ho detto nulla riguardo alla fusione delle comunità, semplicemente alcuni argomenti in comune. E anche in quel caso, ho solo suggerito che gli account utente potrebbero fungere da intermediari…
E non è forse questo ‘unire’ le offerte di comunità diverse? Si continua a ‘unire’ alcuni contenuti, anche se, come detto nel messaggio precedente:
Sembra esserci una riluttanza da parte del team di Discourse a farlo, oltre a vantaggi/casi d’uso poco chiari. Se non vedi come il mio post precedente si colleghi all’argomento, va bene. Le mie scuse. Dimenticalo.
Assolutamente no. Ma mi piacerebbe leggerne sui quotidiani locali o, in un caso più specializzato, su una guida gastronomica italiana per intenditori. Il fatto che le cose non siano tutte uguali è proprio ciò che rende valevole l’abbonamento. Tornando al web e alle comunità, collegare e citare è senz’altro prezioso. Tuttavia, si tratta di un caso d’uso diverso rispetto alla condivisione di un argomento tra forum e alla visualizzazione del thread nel suo contesto, magari partecipando direttamente.
Hai ragione: in alcuni casi non si desidera mescolare le identità e certamente non si dovrebbero fondere completamente comunità disperse. Tuttavia, è possibile fondere selettivamente solo le parti in cui ha senso. Che sia su base argomento, determinate (sub)categorie, tag o specifici gruppi di persone che condividono contenuti.
Non si tratta davvero nemmeno di ActivityPub. Il protocollo è piuttosto di basso livello, costruito sopra HTTP. Con esso si può costruire qualsiasi cosa. Spesso, quando si menziona ActivityPub, le persone tendono automaticamente a pensare al microblogging (Mastodon), poiché è l’applicazione più popolare fino ad oggi. Se si considera questo ambito, tutti stanno in qualche modo creando la propria “comunità unica”, definita da chi seguono. Questo genera la propria timeline personale. Oltre a ciò, potrebbero aver scelto di creare il proprio account su, ad esempio, mastodon.technology, e la timeline del loro server ha approssimativamente il tema “tecnologia”. Tuttavia, questo dominio non si adatta davvero a Discourse, ovviamente. Si tratta di microblogging, non di forum comunitari, dopotutto.
Attualmente, alcune applicazioni di microblogging stanno estendendo il loro dominio con il concetto di Gruppi. Potresti vederlo come un concetto di comunità che si estende oltre i confini del server. Quindi, mentre sono su mastodon.technology, potrei iscrivermi al gruppo “spaghetti” e a “cambiamento climatico”. Ma è sempre solo microblogging → tutto viene compresso e appiattito nelle mie timeline.
Cos’è una comunità di successo? Quali sono i suoi confini, cosa c’è dentro e cosa fuori? Questi possono essere molto chiaramente definiti e relativi all’identità e alla diversità. Una cosa a cui non si riferiscono di per sé sono i confini specifici dei server!
Anche se ho affrontato l’argomento in modo molto ampio in La comunità non ha confini, sto riflettendo senza questi artificiali confini dei server che ho menzionato (e su come ciò possa aumentare la qualità, la quantità e l’attività della comunità). Non ho approfondito l’identità, che è un ottimo punto da affrontare anch’esso. Grazie per la risposta lì, @Mevo, risponderò a tempo debito.
Grazie @aschrijver, è molto utile.
Dal primo paragrafo ricavo l’idea di “usarlo con saggezza”.
Per quanto riguarda il secondo paragrafo, quando parlavo di “ActivityPub”, mi riferivo più all’idea di cosa abilita o fa, piuttosto che al protocollo stesso. L’idea di “condividere/collegare contenuti” o di “liberare i contenuti dai limiti dei server”, come hai detto tu.
L’idea di un certo spostamento di controllo/potere è interessante: non sarebbero più i proprietari della comunità a controllare i propri utenti, i propri contenuti (quelli che ospitano, almeno), a cosa le persone hanno accesso quando arrivano nel loro spazio, come le informazioni sono organizzate e raggruppate, ecc. Gli utenti avrebbero più controllo e sarebbero più liberi di scegliere ciò che vogliono, da dove vogliono, e di creare il proprio “menu personale”.
Vedo come questo possa essere attraente dal punto di vista dell’utente e come possa essere un po’ spaventoso o preoccupante dal punto di vista del proprietario della comunità.
Usando un’analogia con un ristorante, concordo sul fatto che probabilmente stavo esagerando con il mio punto di fondere più luoghi, ma penso che le tue analogie siano troppo leggere: secondo me, è più di quello che descrivi. Si tratta di andare in un ristorante e poter ordinare un piatto da un altro posto, preparato dallo chef di quel posto. Questo può sollevare domande (che era una parte importante del mio punto) sul perché il proprietario del ristorante che paga bene quello chef, e che forse ha avuto difficoltà ad attirarlo e trattenerlo, vorrebbe non avere più una ragione chiara per cui i clienti vengano nel SUO ristorante. La tua risposta è più o meno: è fantastico dal punto di vista del cliente. Sì, certo, sono d’accordo.
Comunque, potresti avere ragione su questo, e il punto che sto facendo assomiglia molto alle paure delle aziende riguardo all’open source in passato.
@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.
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…
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.
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.
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.
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à…
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.
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:
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.
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.
