Sì, ma sarebbe un plugin esteso e costoso.
1 Mi Piace
Con SSO o LDAP posso consentire l’accesso avanti e indietro senza dover spostare tutti a un unico accesso di dominio?
Ad esempio, ho i forum A, B, C. Vorrei che i membri del forum A potessero accedere e pubblicare con le proprie credenziali del forum A ai forum B e C. Lo stesso dovrebbe accadere ai membri registrati di B e C.
Penso che questo post e quelli successivi dovrebbero andare nel loro argomento separato poiché riguardano un sottoinsieme delle funzionalità discusse qui.
1 Mi Piace
Setup DiscourseConnect - Official Single-Sign-On for Discourse (sso) - Integrations - Discourse Meta potrebbe esserti d’aiuto 
1 Mi Piace
In teoria, suppongo che un’altra possibilità oltre a creare un plugin Discourse che funzioni come server del protocollo di federazione ActivityPub sarebbe quella di impostare account su un server ActivityPub separato che onori il protocollo API Social client, e avere un plugin Discourse che parli il protocollo client a quel server, piuttosto che essere un server ActivityPub. Questo potrebbe avere il beneficio di una più stretta integrazione nei nodi ActivityPub esistenti. Ma non credo che sia più facile da implementare del protocollo server, e richiederebbe molto più lavoro di configurazione manuale per l’operatore del forum rispetto all’essere un server del protocollo di federazione.
Nella mia idea su cosa implementare, per consentire la possibilità di interazione utente, ci dovrebbe essere un modo per distinguere gli attori-utente di Discourse dagli attori-sistema di Discourse (ad esempio, categorie). Potrei immaginare che @#slug@discourse.example.org sarebbe un attore di categoria, lasciando spazio per l’aggiunta successiva di attori utente @username@discourse.example.org. Ma data la prevalenza degli hashtag, ciò potrebbe semplicemente non funzionare nella pratica.
Sarebbe più semplice concentrarsi sui punti 1-3 partendo dal presupposto che 4-5 si avvicinano troppo al tentativo di trasformare Discourse in un server ActivityPub per scopi generali, il che sicuramente non è l’obiettivo.
2 Mi Piace
Mastodon utilizza le seguenti espressioni regolari per la convalida:
USERNAME_RE = /[a-z0-9_]+([a-z0-9_\\.-]+[a-z0-9_]+)?/i
MENTION_RE = /(?<=\^|[^\\/[:word:]])@((#{USERNAME_RE})(?:@[[:word:]\\.\\-]+[[:word:]]+)?)/i
Per quanto ne so, USERNAME_RE viene applicato agli utenti remoti, quindi non mi è chiaro come avere utenti e categorie di Discourse in namespace separati in quel modo. Esclude anche le normali slug delle sottocategorie. Anche @parentcategory:subcategory@discourse.example.org non funzionerà con quella RE.
Suppongo che potrebbe esserci un sottodominio opzionale @username@users.discourse.example.org, ma ciò richiederebbe più configurazione SSL e DNS e probabilmente verrebbe configurato in modo errato molte volte. Forse non vale la pena andare lì.
1 Mi Piace
Forse ha senso non creare una federazione con altre piattaforme, ma creare una federazione tra tutte le istanze di discourse, dato che il numero di istanze di discourse è molto elevato.
2 Mi Piace
C’è un enorme potenziale qui, di sicuro. Le possibilità e le fattibilità meritano un’attenta e sobria considerazione.
Questo potrebbe essere territorio Xanadu… (Leggi il post di Jeff sopra e segui il link al suo interno.) Una integrazione così ampia è probabilmente indesiderabile per la maggior parte degli amministratori/operatori di istanze Discourse. È in ordine un sondaggio formale di amministratori e operatori (al contrario di un “sondaggio per livello di traffico” nei forum di discussione).
Questo sembra un invito a hacking di sicurezza poiché offre le “chiavi del regno” a chiunque possa hackerare le credenziali utente di uno qualsiasi dei siti federati. Come minimo, queste funzionalità dovrebbero essere disattivate per impostazione predefinita o caricate esplicitamente come plugin, con la maggior parte delle funzionalità di sicurezza abilitate e bloccate. Zoom ci ha insegnato questa lezione lasciando giustamente la sua piattaforma aperta e facile da usare (per acquisire e coltivare rapidamente utenti in fase di avvio), ma poi ha dovuto bloccarla rapidamente una volta che i malintenzionati hanno trovato la porta d’ingresso sbloccata.
Tuttavia, una micro-federazione di siti sarebbe un impulso all’implementazione di Discourse. Se potessi creare un cerchio di siti per il mio comune che unisca lo stesso pool di utenti (ad esempio, cittadini della contea/città), questo metterebbe le persone in comunicazione e potrebbe consentire alcuni risultati positivi nella governance locale e nella vita comunitaria. Lo stesso principio si applica anche a qualsiasi azienda sufficientemente grande da giustificare l’overhead di amministrazione di più istanze Discourse, in modo che ogni divisione possa avere il proprio container Discourse con facile navigazione verso altre divisioni. *QUELLO sarebbe l’incarnazione di meta.discourse. *
Jeff, Sam e Co. [@codinghorror @sam] e/o il loro Comitato Direttivo dovrebbero prima decidere, tuttavia, se Discourse è una piattaforma sociale o una piattaforma aziendale. Il mio voto è per l’azienda perché vedo il maggior potenziale lì per entrambi i lati di questa divisione. L’azienda produrrà il maggior guadagno finanziario e il beneficio sociale immediato migliorando la capacità delle aziende di supportare i dipendenti (prendersi cura bene dell’azienda e l’azienda potrà prendersi cura bene di te). Alcuni di quei fondi commerciali potrebbero probabilmente supportare una fondazione social.discourse.org. È anche molto probabile che le funzionalità utili a un’azienda si trasferiscano bene nel dominio sociale. Questi due fattori creano un vantaggio generale per tutti.
I due domini devono essere distinti, tuttavia, perché sono così diversi. E le funzionalità “nice-to-have” dovranno necessariamente favorire qualunque versione sia il caso d’uso primario.
Fortunatamente, i benefici fluiscono in entrambe le direzioni poiché chiunque sia interessato a social.discourse.org ottiene la sua ricompensa dagli aspetti sociali della costruzione della comunità e dall’essere in grado di perseguire attività legate alla comunità, quindi lavorerà - e spesso lavorerà sodo - per queste ricompense non finanziarie. Questo lavoro social.discourse.org porterà inevitabilmente allo sviluppo e a funzionalità utili nel contesto aziendale e quindi restituirà valore a Enterprise Discourse Incorporated in cambio del supporto senza scopo di lucro della Social Discourse Foundation. Ancora più win-win.
Nota che non c’è un singolo punto esclamativo sopra. Questi sono solo fatti concreti e dichiarazioni di probabili risultati. Molto pragmatico.
Sto cercando una piattaforma GroupWare adatta per le mie aziende da diversi anni. Slack ha brevemente ispirato grandi speranze poiché è stato sviluppato per uso aziendale interno (e ha una storia delle origini molto interessante), ma non ha nemmeno superato la prima fase di screening. Sono molto colpito da Discourse e ottimista al riguardo.
1 Mi Piace
Questo è il punto centrale di questo argomento, ovvero tra le istanze di Discourse.
È affermato nell’OP:
2 Mi Piace
Giusto, e
e
una micro-federazione di siti sarebbe un vantaggio
Tutto in tema, no? 
Non necessariamente un prerequisito. C’è l’ecosistema dei plugin da considerare.
Funzionalità significativamente ampie vengono spesso sviluppate come plugin o persino Componenti del Tema (ove possibile) che non comportano un tale overhead amministrativo né una pianificazione centralizzata.
Questa è parte della bellezza dell’ecosistema Discourse.
Pavilion, ad esempio, ha creato Locations, Topic List Previews, Multilingual, Follow, Layouts, Custom Wizard (per citarne alcuni) senza consultare CDCK. Pertanto, in parte, il nostro coinvolgimento in questa discussione.
7 Mi Piace
Dio benedica i nostri sviluppatori di plug-in! Forniscono generosamente esempi di prova di concetto che possono essere testati sul campo e presi in considerazione per l’inclusione nel prodotto principale. Il tuo plug-in multilingue ne è un eccellente esempio!
Su python.org, questo ruolo è svolto dagli sviluppatori di librerie che a volte creano funzioni “da avere assolutamente” che vengono accettate per l’inclusione nel pacchetto principale di Python o nella libreria di distribuzione standard.
2 Mi Piace
Sto sostenendo Discourse per aggiungere il supporto alla federazione in una serie di argomenti su questo forum, come qui. Con il Fediverso che sta diventando mainstream ora, e Tumblr e forse Flickr e simili che aggiungono il supporto alla federazione, la domanda è se Discourse abbia più interesse ad aggiungere anche il supporto.
Sono stato contattato dallo sviluppatore principale di Flarum per consigli sull’implementazione di AP e ho rimandato alcuni link, tra cui quello appena menzionato.
PS. Su SocialHub, il forum di Discourse, la comunità di sviluppatori per il Fediverso, stiamo cercando da tempo come possiamo far parte del Fediverso poiché i forum separati si sono dimostrati una barriera troppo grande per la maggior parte delle persone per partecipare.
7 Mi Piace
Mi sono interessato leggermente a Mastodon ultimamente (abbastanza da acquistare un nome di dominio, ma non da installare effettivamente Mastodon), quindi ho letto un po’ sull’autenticazione di Discourse con Mastodon.
Ho trovato alcuni post che suggerivano che fosse più difficile di quanto si pensasse. Se ricordo bene, sembrava che fosse stata offerta una sovvenzione per sviluppare un plugin, ma sembra che sia fallita. La mia ipotesi è che si tratti di un problema da 10.000 dollari; se ho ragione, questo è il tipo di sostegno di cui avrai bisogno.
Modifica: ma stavo confondendo l’autenticazione con la federazione.
1 Mi Piace
La mia preoccupazione generale qui è che le idee sono generalmente enormi, è super difficile suddividerle in piccoli pezzi.
Trovo interessante l’idea di federare. Un possibile implementazione concreta potrebbe essere:
- Consentire agli amministratori di Discourse di federare una categoria.
- Gli utenti su Mastodon possono quindi seguirla, ad esempio seguire:
announcements@meta.discourse.org - Quando vengono creati nuovi argomenti di annunci, viene pubblicato un nuovo post federato con un estratto e un link all’originale.
- Man mano che gli utenti rispondono su Discourse, le nuove risposte vengono federate e attribuite (come risposte all’argomento originale).
- Quando qualcuno sul fediverso risponde, viene creato un post “ombra” sull’argomento attribuito all’autore su Mastodon.
Qualcosa del genere è almeno abbastanza piccolo da rientrare correttamente nella mia testa.
13 Mi Piace
Il problema con ActivityPub è che è uno standard aperto di facile lettura, ma implementarlo non ti rende ancora “parte del Fediverso”. Ci sono un sacco di altre cose da implementare e, per un dominio di forum di discussione, un vocabolario ActivityPub personalizzato per gli scambi di messaggi. Ci sono altri progetti da cui “avviare” e alcune librerie da adottare eventualmente, ma ci sarà effettivamente uno sviluppo significativo necessario.
In termini di advocacy… Personalmente ritengo che, se fatto bene, il supporto AP possa aggiungere punti di forza unici al prodotto. Non dover iscriversi a ogni forum è una cosa… è una barriera anche per me. Dovrei iscrivermi a un altro Discourse, solo per questo singolo post che voglio aggiungere?
Ma la federazione potrebbe portare molto più valore. Nel mio scenario da sogno installerei un Discourse personale o mi iscriverei a un’istanza che, come Mastodon, sarebbe completamente vuota all’inizio. Poi la riempirei con la struttura della community da solo, in base alle mie esigenze e interessi. Sceglierei questo gruppo tematico e lo aggiungerei sotto questa categoria, aggiungerei un altro gruppo.
Aggiornamento: Crosspost con @sam .. questa era una reazione a @pfaffman
5 Mi Piace
Sì, sarebbe un ottimo inizio. L’aggregatore di link di Lemmy funziona in modo simile, offrendo un federazione di Comunità. Nota che - sebbene sarebbe molto utile interagire più ampiamente - la federazione potrebbe essere implementata inizialmente solo tra istanze/tenant di Discourse.
Non tutto si adatta a Mastodon… è un’app di Microblogging, non supporta il markdown (anche se altre app fedi lo fanno).
Attualmente si sta lavorando al supporto per ulteriori Gruppi federati. Lemmy ne è un esempio. Bonfire aggiungerà cerchie simili a Google+, ecc.
3 Mi Piace
Sì! Questo è il flusso di lavoro che mi piacerebbe vedere. E promuovere. 
La lunghezza dell’estratto sarebbe comodamente configurabile, con 0 che significa l’intero articolo anziché un estratto. Si noti che il limite di 500 caratteri di Mastodon è arbitrario e non ha nulla a che fare con il Fediverse, ActivityPub o ActivityStream. I nodi Mastodon che gestisco attualmente hanno limiti di 2000 caratteri e il limite di social.kernel.org è di 31337 caratteri. Anche Mastodon di default, con il suo limite di 500 caratteri per la scrittura dei post, visualizza comunque post più lunghi senza problemi.
Una piccola difficoltà che vedo è che gli spazi dei nomi utente e categoria sono separati in Discourse ma sono lo stesso “Actor” in ActivityPub, e almeno Mastodon ha un’espressione regolare abbastanza restrittiva per riconoscere gli Actor. Dato @announcements@meta.discourse.org per la categoria Announcements, questo commento verrebbe federato come scritto da @mcdanlj@meta.discourse.org
Per impostazione predefinita, come amministratore di Discourse, vorrei usare lo slug della categoria come nome dell’Actor. Suppongo che, quando l’amministratore imposta la federazione per una categoria, selezioni il nome dell’Actor, che per impostazione predefinita sarà lo slug, e sarebbe (come un nome di gruppo) univoco rispetto ai nomi utente di Discourse.
(Tra l’altro, una volta mi preoccupavo dell’espressione regolare di Mastodon per riconoscere i nomi degli attori, ma penso che venga effettivamente utilizzata solo per menzionare le persone, il che non è comunque utile qui. Quindi potrebbe anche funzionare avere, ad esempio, #documentation:admins rappresentato come @documentation:admins@meta.discourse.org anche se vorrei assolutamente testarlo con diversi dei principali sistemi di microblogging, inclusi sicuramente Mastodon e Pleroma.)
3 Mi Piace
Penso che ciò che questo sembrerebbe in realtà dalla prospettiva di, diciamo, un utente di Mastodon o Pleroma, sarebbe che @announcements@meta.discourse.org boosterebbe / riposterebbe un post di argomento di, diciamo, @sam@meta.discourse.org e poi boosterebbe/riposterebbe anche un post di commento di, diciamo, @mcdanlj@meta.discourse.org come commento all’OP — Né l’OP né un commento viene effettivamente creato dalla categoria, viene creato da una persona, in una categoria.
Potrebbe essere che il plugin possa inizialmente implementare solo webfinger per gli Attori della categoria (per poterli seguire), ma potrebbe avere senso alla fine implementarlo anche per singoli utenti. Potrei ragionevolmente, su Mastodon, voler seguire @sam@meta.discourse.org per vedere i suoi post e commenti.
2 Mi Piace
Domanda: qual è lo stato attuale di questa discussione e i piani per possibili implementazioni? Hai bisogno di supporto per i test, ad esempio? O è una domanda “troppo prematura” 