Sì, Discourse potrebbe fare qualcosa di simile con il suo widget di incorporamento dei commenti. Tra le altre cose, potrebbe aiutare a ridurre l’imbarazzo che alcune persone provano quando avviano un forum che ha solo pochi utenti attivi: AI sockpuppet accounts to jumpstart my community?. I nuovi siti Discourse potrebbero utilizzare post di blog per promuovere e popolare il loro forum. Questo è in qualche modo possibile ora, ma consentire agli utenti di commentare direttamente dal widget di incorporamento renderebbe il processo più fluido.
3 Mi Piace
Un semplice modulo di commenti collegato a Discourse sul lato Wordpress, in modo che i visitatori non debbano prima andare su Discourse e creare un account lì, prima di pubblicare un commento, aiuterebbe a ridurre l’attrito e a creare coinvolgimento, almeno per editori come me.
Per il mio caso d’uso, sarebbe ideale se un commentatore potesse lasciare il proprio commento semplicemente con un nome e un indirizzo email. Questo potrebbe quindi essere utilizzato per creare un utente in staging in Discourse e invitarlo a unirsi completamente per continuare la conversazione, senza impedirgli di lasciare il proprio commento.
Stiamo scoprendo che l’attrito aggiuntivo della creazione di un account per lasciare un commento su un articolo pubblicato rende difficile creare coinvolgimento e, in definitiva, far crescere la community nel nostro forum. Ad esempio, quando gli è stato chiesto della nostra sezione commenti (utilizzando l’attuale integrazione Discourse-Wordpress), un autore ci ha fornito il seguente feedback:
Riguardo all’area di conversazione: ora che lo menzioni… ricordo di averla vista. E all’epoca, ho pensato che l’avrei dimenticata per il momento dato che sembrava richiedere tempo per iscriversi. Questa è una forte prova di come la maggior parte delle persone si sentirebbe riguardo al dover passare attraverso quel processo. Normalmente sono quasi ossessionato dal vedere commenti sulla mia scrittura. Ricordo di aver riso tra me e me e di aver detto: “Suppongo di non essere abbastanza ossessionato da occuparmi di questo in questo momento”. Idealmente, lasceresti i commenti aperti a tutti senza processo di iscrizione. Ma qualsiasi livello di semplificazione/facilità migliorerebbe il coinvolgimento lì. Commenti come questi sono solitamente un impulso. Se le persone vengono ostacolate in qualche modo, tenderanno ad andare avanti e a non prendersi il tempo.
3 Mi Piace
Stavo giusto pensando a questo l’altro giorno. Stranamente mi è mancato avere i commenti di Wordpress sui miei post del blog perché sembrava così veloce per le persone iniziare, una barriera all’ingresso molto bassa.
Nonostante abbia un processo di registrazione molto semplice, al momento se qualcuno vuole commentare il post, deve visitare una nuova pagina. Penso che superare quella soglia possa sembrare troppo gravoso. Quasi come se volessi commentare A, ma devo visitare B per commentare A e poi tornare ad A per vedere il commento. Sarebbe più naturale commentare A proprio sotto A.
Mi piace l’idea di mettere in scena gli utenti. Potrei pensare di hackerare questo problema facendo in modo che il modulo di commento di Wordpress invii un’email al forum Discourse e poi crei un utente in quel modo, anche se immagino che potrebbe diventare più complesso integrarlo completamente in questo modo.
3 Mi Piace
Penso che questo fosse possibile in passato, ma sono abbastanza sicuro che Discourse ora confronta l’“Intestazione Mittente” dell’email con il suo Percorso di Ritorno. Se questi non corrispondono, l’email viene rifiutata. (Se Discourse non controllasse il Percorso di Ritorno, il sistema di commenti potrebbe essere facilmente abusato: qualsiasi indirizzo email potrebbe essere inserito nel modulo.)
Ci sono alcuni modi in cui si potrebbe affrontare il problema di Discourse come sistema di commenti. Penso che l’approccio migliore sarebbe che Discourse migliorasse il suo iframe di incorporamento dei commenti in modo che gli utenti potessero interagire con esso come utenti Discourse autenticati. Se ciò non fosse possibile, si potrebbe sviluppare un’applicazione web di commenti Discourse incorporata. Sarebbe un progetto interessante, ma vorrei essere sicuro che Discourse non fornisse funzionalità simili tramite il loro iframe di commenti incorporato prima di perseguirlo troppo a fondo.
Ci sono anche alcune possibili soluzioni specifiche per WordPress. La più semplice è abilitare i commenti di WordPress e il plugin WP Discourse. Il rischio è che ciò ridurrebbe l’attività sul forum Discourse. Penso che ci sarebbero comunque modi per aiutare con questo nell’interfaccia utente di WordPress, ad esempio, collegandosi a conversazioni correlate che stavano avvenendo su Discourse.
Sarebbe anche possibile sviluppare qualcosa di specifico per i siti WordPress che funzionassero come provider di Single Sign-On (SSO) di Discourse. Ne ho parlato in post precedenti in questo argomento. Per farlo bene potrebbero essere necessarie modifiche significative al plugin WP Discourse. A meno che (sto pensando ad alta voce qui):
Quello che sto cercando di indicare con lo screenshot qui sopra è che per il caso di un sito WordPress che è il provider SSO di Discourse, i commenti potrebbero essere visualizzati con l’iframe di commenti di Discourse. I commenti potrebbero essere creati tramite un modulo che invia alla API di Discourse. Ciò potrebbe richiedere alcune modifiche all’iframe di commenti di Discourse per garantire che si aggiorni quando viene aggiunto un nuovo commento, ma non richiederebbe agli utenti di poter interagire con esso come utenti Discourse autenticati.
4 Mi Piace
Quindi, se ho capito bene, l’idea sarebbe che il commentatore si registrasse sul lato WordPress, poi lasciasse un commento tramite l’iframe incorporato di Discourse, che verrebbe pubblicato sull’argomento su Discourse, quindi aggiornasse la visualizzazione su WordPress, in modo che appaia subito.
Il processo di registrazione di WordPress validerebbe l’email, suppongo. Ma ciò richiederebbe anche il passaggio a WordPress come provider SSO di Discourse, fattibile, ma in un certo senso sfortunato, perché sposta l’attrito sull’ altro lato per le persone che potrebbero semplicemente voler registrarsi al forum.
Tendo a concordare con quello che hai detto qui:
Se fosse addirittura possibile registrarsi direttamente nell’iframe, o almeno essere preparati, in modo che si possa procedere con il commento (che potrebbe essere pubblicato solo una volta convalidata l’email), mi sembrerebbe una soluzione che bilancia facilità d’uso e sicurezza.
2 Mi Piace
Sì, hai capito bene. Se WordPress è il provider SSO, il problema di consentire agli utenti di commentare gli argomenti di Discourse non è così difficile da risolvere. La parte complicata, in termini di lavoro con lo stato attuale del plugin WP Discourse, è capire come visualizzare i commenti su WordPress - attualmente la sezione commenti di WP Discourse non rispecchia le risposte dell’argomento di Discourse. Invece, viene visualizzata una selezione dei “migliori” commenti.
Sarebbe possibile aggiornare il plugin WP Discourse per gestire questo caso d’uso, ma per farlo correttamente richiederebbe di riscrivere completamente il modo in cui gestisce i commenti di Discourse. Non spetta a me decidere, ma penso che dedicare sforzi a migliorare l’iframe dei commenti di Discourse sarebbe un uso migliore del tempo.
5 Mi Piace
Vorrei aggiungere la mia voce per volere questa funzionalità.
Sarebbe davvero utile se gli utenti su WP potessero semplicemente registrarsi/accedere e commentare direttamente sotto un post su WP senza dover navigare verso il forum, in modo che il tutto sembri più un sistema di commenti. Il loro commento apparirebbe sia sotto il post che nel thread di discussione che è stato creato. E hanno sempre la scelta di pubblicare sia su discourse, wordpress o entrambi - senza interruzioni. Non ho idea di come questo verrebbe realizzato, ma sarebbe un modo davvero fluido per integrare i commenti di WP con Discourse che sembra meno goffo e senza dubbio migliorerebbe notevolmente il numero di commenti rispetto a quelli che otteniamo attualmente con il plugin esistente.
3 Mi Piace
Forse questo:
Ma dirotta completamente il login di Discourse per quanto ne so.
Ciò consentirebbe agli utenti di pubblicare commenti direttamente sotto un post di WordPress e popolare automaticamente quel post nel thread di Discourse corrispondente?
Ci sto lavorando ora. La prima versione è per un sito WordPress headless che utilizza il framework Remix per il suo front-end. Una volta fatto, farò una versione per i siti WordPress normali. Sarà probabilmente un plugin che estende il plugin WP Discourse. Spero che la maggior parte di ciò che sto facendo sul sito WordPress headless possa essere trasferito ai siti WordPress normali, ma potrebbe richiedere alcuni compromessi.
Consentire agli utenti di commentare direttamente da un sito esterno è banale da implementare. Il requisito principale è che il sito esterno abbia accesso alle credenziali dell’utente di Discourse. Ciò può essere fatto sia utilizzando il sito esterno come provider DiscourseConnect per Discourse, sia configurando Discourse come provider DiscourseConnect per il sito esterno.
Nel secondo scenario, in cui il sito esterno non è il provider DiscourseConnect per Discourse, la prima volta che un utente desidera commentare dal sito esterno, dovrà fare clic su un link per collegare il proprio account sul sito esterno al proprio account Discourse (o registrarsi su Discourse se non l’ha ancora fatto). Può essere abbastanza trasparente dal punto di vista dell’utente.
La modifica di cui sopra, tuttavia, non fa sì che il tutto sembri un normale sistema di commenti. Una normale aspettativa per un sistema di commenti è che si possano leggere e interagire con tutti i commenti. Il plugin WP Discourse visualizza solo una selezione di commenti estratti da un percorso speciale fornito da Discourse. Non fornisce alcuna funzionalità per interagire con i commenti.
Le parti difficili del problema sono:
- paginare tutti i commenti di un argomento su WordPress, tenendo presente che potrebbero essercene migliaia
- fornire un’interfaccia utente che dia all’utente un feedback su dove si trova in un lungo elenco di commenti
- capire come visualizzare i commenti che sono risposte dirette ad altri commenti. (La convenzione di Discourse per questo è in contrasto con il modo in cui la maggior parte dei sistemi di commenti gestisce le risposte.)
- consentire agli utenti di rispondere direttamente a un commento, mettere “mi piace” a un commento, modificare i propri commenti, ecc.
- gestire i commenti creati su Discourse che potrebbero contenere contenuti o markup che non possono essere facilmente visualizzati o con cui non si può interagire sul sito esterno. Ad esempio, onebox, sondaggi…
- fornire un modo per filtrare i commenti per più recenti, più vecchi, migliori, ecc…
Tutto ciò deve essere realizzato senza mettere un carico eccessivo sul server del sito esterno, fare troppe richieste API a Discourse o consumare troppa memoria sul dispositivo dell’utente (l’obiettivo è creare un sistema di commenti leggero). È realizzabile, ma non è qualcosa che può essere semplicemente inserito nel codice esistente di WP Discourse senza apportare modifiche significative ad esso.
4 Mi Piace
Sono contento di sentire che hai iniziato!
Solo un pensiero: dato che parte dell’idea è ridurre l’attrito per far commentare le persone in primo luogo, potrebbe essere una buona idea concentrarsi sulla fluidità di quel primo commento. Come accennato in precedenza, sembra che molte persone vogliano semplicemente poter commentare con il proprio indirizzo email; il problema allora è la validazione e il login, o la creazione dell’account (a seconda, suppongo, di come è configurato DiscourseConnect).
Una volta che un utente è entrato, mi aspetterei che sia più propenso a visitare l’argomento del forum corrispondente per ottenere tutte le funzionalità di discussione basate su Discourse. Spero solo che tutte quelle parti difficili del problema non ostacolino la soluzione del problema del “primo commento”. Avere migliaia di commenti per i quali dobbiamo trovare una soluzione per la paginazione sarebbe allora un “buon problema da avere”. 
4 Mi Piace
Questo è abbastanza per me perché i nuovi e i vecchi utenti parteciperanno e interagiranno tra loro. Non è un grosso problema per me, un esterno
Sì, è una preoccupazione genuina. Il primo passo è mettere online un sito demo. Avere un sito live su cui testare le cose dovrebbe rendere ovvi i punti di attrito.
Potrebbe essere tecnicamente possibile consentire agli utenti anonimi di commentare i post. L’unico modo non complicato a cui riesco a pensare sarebbe che i commenti vengano pubblicati per conto dell’utente anonimo da un utente reale. Questo però sembra un po’ strano.
So che WordPress ha un’impostazione per consentire agli utenti “ospiti” di creare commenti. Viene fornito con la limitazione che un commento “ospite” non sarà associato a un utente reale se l’utente che ha creato il commento ospite si registra sul sito dopo aver creato il commento. La pubblicazione “per conto” di un utente dovrebbe funzionare in modo simile: non ci sarebbe modo di sapere che l’utente che ha creato il commento anonimo era il proprietario dell’indirizzo email che aveva fornito con il commento.
Idealmente, gli utenti verranno autenticati sul sito esterno o su Discourse prima di creare un commento.
Dal punto di vista dell’utente, il minor attrito possibile sarebbe nel caso in cui il sito esterno sia il provider SSO per Discourse. Ciò consentirebbe loro di commentare gli argomenti di Discourse senza dover mai visitare il sito di Discourse.
Dal punto di vista del proprietario del sito, il modo tecnicamente più semplice per autenticare gli utenti sarebbe avere Discourse che funziona come provider di autenticazione per il sito esterno. Questa è la configurazione che sto attualmente utilizzando sul mio sito di test locale. Il sito esterno (Remix) non ha nemmeno una tabella utenti. Crea semplicemente una sessione utente basata sulla risposta dal percorso /session/sso_provider di Discourse.
Lo svantaggio dell’utilizzo di Discourse come provider di autenticazione per il sito esterno è che costringe gli utenti a passare attraverso il processo di registrazione/login di Discourse. Non c’è niente di sbagliato in quel processo, tranne per il fatto che sembra costringere gli utenti a scaricare tutte le risorse di Discourse quando potrebbero semplicemente voler lasciare un commento sul sito esterno. Quindi è un po’ lento. Indagherò ulteriormente…
Lo sarebbe Forse riduciamolo a centinaia per uno scenario più realistico. Il punto che sto cercando di fare è che il problema diventa complesso una volta superata 1 pagina di post (20 post).
Modifica: potrebbe essere possibile utilizzare gli inviti di Discourse per semplificare il processo: se un utente anonimo volesse commentare un post, verrebbe visualizzato un campo email insieme al modulo di commento. L’invio del commento attiverebbe Discourse per inviare un invito all’indirizzo email. Il commento verrebbe tenuto in coda fino all’accettazione dell’invito. Ciò consentirebbe agli utenti di creare il commento quando sentono l’ispirazione e dare loro un feedback immediato sullo stato del loro commento.
4 Mi Piace
Sono entusiasta di vedere quale sarà la soluzione di @simon qui.
Volevo solo far notare che una soluzione che si sta sviluppando su un binario diverso su questo fronte è l’uso di ActivityPub. Nella sua ultima versione, il plugin ufficiale di Wordpress ActivityPub ha aggiunto il supporto per il plugin Discourse ActivityPub.
Ciò significa che se hai installato il plugin Wordpress ActivityPub e il plugin Discourse ActivityPub, tutto ciò che devi fare è impostare una categoria per “Seguire” un attore di Wordpress che pubblica un post (o l’intero sito Wordpress) e i tuoi post di Wordpress appariranno come nuovi argomenti in quella categoria di Discourse.
(si noti che il plugin Wordpress ha un ritardo di pubblicazione, motivo per cui nel video ci vuole un minuto prima che appaia in Discourse; salta a 1:40 per vederlo apparire).
Il plugin Wordpress ActivityPub supporta anche l’ingestione di attività ed è già configurato per elaborare le attività in arrivo in risposta a un post come un “Commento” a quel post, tuttavia quella particolare parte non funziona ancora con le attività inviate dal plugin Discourse (penso che il plugin Wordpress non supporti ancora le note annunciate). Ma anche quello dovrebbe funzionare presto.
Vedi altro
6 Mi Piace
Nota che Matthias, il manutentore del plugin Wordpress, ha fatto funzionare questo, quindi presto dovrebbe esserci il supporto per la condivisione di pubblicazioni e il commento nativo bidirezionale tra Discourse e Wordpress (tramite ActivityPub).
https://socialhub.activitypub.rocks/t/this-is-a-test-federation/4164/2
https://pfefferle.org/this-is-a-test-federation/#comment-148
3 Mi Piace
Questo argomento è iniziato con l’idea che un sistema di commenti basato su Discourse potesse fornire funzionalità simili a Coral, con il vantaggio aggiunto di consentire ai commenti di un sito Web di confluire in normali argomenti di Discourse. Discourse fornisce la capacità di moderare i commenti di un sito Web e consente che le discussioni relative ai commenti avvengano sul forum.
Non credo che la necessità di moderazione debba essere argomentata.
La necessità di consentire ai commenti di confluire in effettivi argomenti di Discourse potrebbe essere meno ovvia. Parto dal presupposto che avere qualsiasi tipo di conversazione online sia difficile: la conversazione di persona fornisce tutti i tipi di segnali sottili che non esistono online. Avere conversazioni online significative con più di una manciata di persone è quasi impossibile. È qui che entra in gioco Discourse. La funzionalità di gruppo di Discourse fornisce la capacità di limitare chi può partecipare a un argomento. Ai gruppi di commentatori può essere consentito di partecipare ad argomenti di Discourse chiusi. Questo è in qualche modo l’opposto di come funziona il fediverso.
Detto questo, sono curioso di sapere come potrebbe funzionare l’integrazione tra Discourse e WordPress nel fediverso. Ad esempio, se Sally commenta il post di Bob su WordPress, cosa ci si aspetta che accada al commento di Sally se avesse un account Discourse? Cosa ci si aspetta che accada al commento di Sally se non avesse un account Discourse? C’è un modo in cui Sally potrebbe rifiutarsi di far pubblicare il suo commento nel fediverso?
Andando fuori tema, ma con i vari tipi di leggi sui danni online che vengono implementate o proposte nei paesi occidentali, se il commento di Sally viene ritenuto offensivo, chi è responsabile della sua pubblicazione? Presumo che questa sia una domanda senza risposta al momento.
3 Mi Piace
Interessante!
Il modo in cui suggerirei di pensare a come ActivityPub funziona sia con la moderazione che con il raggruppamento (e altri aspetti della comunicazione online) è che si tratta principalmente di uno standard di comunicazione. Fornisce alcuni meccanismi per gestire tali questioni, ma le lascia in gran parte ai vari client del sistema.
L’email come standard di comunicazione è un’analogia imperfetta, ma forse utile. “Email” è una raccolta di standard di comunicazione che ti consente di scambiare messaggi con chiunque su Internet. Ha vari problemi di “controllo qualità”, ad esempio lo spam. Ci sono alcuni aspetti della raccolta di standard che chiamiamo “email” che aiutano ad affrontare tali problemi (ad esempio, DMARC, DKIM, SPF ecc.), tuttavia forse il modo principale in cui viene gestito il controllo qualità è nei client di posta elettronica stessi. Gmail è diventato un client di posta elettronica popolare in parte perché ha indubbiamente gestito bene lo spam (e problemi simili di controllo qualità).
Seguendo l’analogia, Discourse sarebbe il “Gmail” di ActivityPub. Tutti gli strumenti di moderazione, il raggruppamento degli utenti e altre funzionalità che rendono Discourse una fantastica piattaforma di discussione sono (praticamente) ancora disponibili nel contesto di ActivityPub. Approfondirò questo aspetto iniziando a rispondere alle tue domande.
Inizierò descrivendo cosa succede, poi forse potremo passare alle domande più sfumate. Salterò molte cose qui, con l’obiettivo di rispondere alle basi:
-
Il commento di Sally viene pubblicato come oggetto ActivityPub da WordPress.
-
L’oggetto viene ingerito in Discourse e convertito in un post.
-
Se l’“Attore” di Sally è associato a un account utente in Discourse, il post sarà associato a quell’account utente. Se il suo Attore non è già associato a un account utente, verrà creato un utente temporaneo dall’attore di Sally e sarà il proprietario del post.
Puoi vedere quanto sopra in azione in questo argomento:
-
La categoria Discourse WordPress - SocialHub sta seguendo WordPress di Matthias.
-
Matthias ha pubblicato un nuovo articolo sul suo blog usando il suo normale account WordPress.
-
Questo è apparso in Discourse come un nuovo argomento, con il post associato a un utente temporaneo associato all’Attore di Matthias.
-
Il modo in cui funzionano i commenti è esattamente lo stesso.
Solo per rispondere alla domanda forse più ovvia: Matthias può riconciliare l’utente “temporaneo” creato dal suo attore WordPress e il suo normale utente Discourse su quel server?
La risposta a breve termine è che il plugin Discourse ha un set di funzionalità di “Autorizzazione” che attualmente ti consente di rivendicare la proprietà dei tuoi attori da altri server Discourse o server Mastodon, il che unisce eventuali utenti temporanei al tuo account (il che significa che ora possiedi i post nel tuo account Discourse principale). Quel set di funzionalità potrebbe essere esteso a WordPress. Apprezzo che questo sia un po’ prolisso e potrebbe essere più facile capire cosa intendo con questa demo:
La risposta a lungo termine è che le prove di identità potrebbero essere integrate nelle attività di ActivityPub a un certo punto, rimuovendo forse la necessità di autorizzazione guidata dall’utente, il che significa che la “riconciliazione” potrebbe essere (più) automatica.
Forse un’altra domanda è se la “riconciliazione” è necessaria, dato che Matthias controlla ancora gli attributi di identità del suo utente temporaneo tramite il suo Attore ActivityPub (che è modificabile su WordPress, le cui modifiche si riflettono sull’utente temporaneo su Discourse).
Dico la maggior parte di questo come forma di “pulizia della gola”, in modo da poter passare alle tue domande più sfumate e importanti. Spero di essere stato chiaro finora.
2 Mi Piace
È comprensibile.
Per quanto riguarda il problema della moderazione, sto parlando dell’uso di Discourse per moderare i commenti di WordPress. Questa è la funzionalità che permetterebbe a Discourse di essere utilizzato in modo simile a Coral. Questo è facile da ottenere se i commenti di WordPress sono effettivamente commenti di Discourse pubblicati da WordPress a Discourse tramite l’API. Funziona semplicemente “out of the box”. Ciò consente, ad esempio, di utilizzare strumenti di moderazione basati sull’intelligenza artificiale forniti da Discourse. Mi chiedo se qualcosa di simile possa essere ottenuto con l’integrazione ActivityPub di WordPress/Discourse.
Qual è la prova di identità per l’utente “staged”? Il suo indirizzo email viene passato dal server di origine?
Per quanto riguarda la mia (personale) preoccupazione di non voler pubblicare contenuti sull’intero fediverso, sembra che sia tecnicamente possibile impostare una relazione ActivityPub uno a uno tra un sito Discourse e un sito WordPress, ma mi chiedo se questo tipo di configurazione non vanifichi lo scopo del protocollo ActivityPub.
Modifica: potrebbe valere la pena aggiungere che l’obiettivo è creare una relazione “win-win” tra un sito web e un forum Discourse associato. Gli strumenti di moderazione di Discourse sono pensati per fornire rassicurazione sul fatto che il sistema di commenti del sito web sia ben moderato. La sezione commenti del sito web è pensata per essere utilizzata per popolare il sito Discourse con argomenti e utenti.
2 Mi Piace
Il post convertito dall’oggetto ActivityPub ha quasi* le stesse funzioni di pre-elaborazione e post-elaborazione applicate a un post creato tramite API. Il punto di ingresso è diverso (cioè un controller ActivityPub invece del controller dei post), ma il modo in cui i post vengono creati è per lo più lo stesso.
*In termini più tecnici, se crei un post tramite API, l’elaborazione effettiva viene eseguita tramite NewPostManager, che poi affida la maggior parte del lavoro a PostCreator. La cosa principale che NewPostManager gestisce (ai fini della presente discussione) è la coda di revisione. Tutto il resto è gestito in PostCreator.
Attualmente il plugin ActivityPub salta NewPostManager e lo passa a PostCreator nel proprio PostHandler (cioè del plugin). L’ho fatto principalmente per ridurre la complessità nell’implementazione iniziale. Non c’è una ragione intrinseca per cui il PostHandler del plugin non possa passare il post a NewPostManager e beneficiare dei controlli della coda di revisione.
In breve, non c’è una differenza sostanziale tra i post creati tramite il plugin ActivityPub e tramite la normale API.
Ci sono alcuni livelli a questo.
-
Innanzitutto, il POST dal server di origine al tuo server è firmato utilizzando firme HTTP per garantire che la richiesta provenga effettivamente dall’origine.
-
In secondo luogo, ogni Attore (cioè utente) su quell’origine ha un UUID, cioè un ID legato al proprio dominio, unico nel fediverso. Assomiglia a questo:
https://angus.ngrok.io/ap/actor/f4b517bf6f81dbddfad3e44a45c9619d
Le email non vengono utilizzate in ActivityPub.
-
Ogni Attività (ad esempio, una Creazione di un oggetto simile a un post) che ricevi è associata a un ID Attore. E ogni ID Attore può essere risolto in attributi Attore.
-
Quindi, nel momento in cui ricevi un’“Attività”, ad esempio la creazione di un nuovo oggetto simile a un post, sul tuo server, conosci, in base al dominio da cui hai ricevuto l’attività, gli attributi dell’Attore che sta eseguendo l’Attività. Ti fidi del dominio di invio qui, ma questo è sempre il caso nella misura in cui, ad esempio, Discourse si fida delle istanze di Wordpress con il plugin WP Discourse per inviare gli attributi utente corretti associati.
Quindi l’utente in staging stesso non ha bisogno di una prova di identità in sé, nello stesso modo in cui un utente in staging da email non ha bisogno di una prova di identità.
La necessità di una prova di identità sorge quando la persona reale associata all’attore ActivityPub, e un altro account Discourse, come l’esempio con Matthias sopra, vuole consolidare (o “riconciliare”) la propria identità. Potrebbe non gradire il fatto di avere effettivamente due “utenti” su un singolo Discourse. Vorrei notare che, senza tale riconciliazione, può controllare
-
Gli attributi di identità dell’Attore ActivityPub / utente in staging tramite il dominio di origine, ad esempio aggiornando il proprio profilo Wordpress, tali aggiornamenti vengono federati e Discourse applica gli stessi); e
-
Il contenuto associato all’Attore ActivityPub / utente in staging tramite il dominio di origine, ad esempio modificando il proprio commento Wordpress, viene inviata un’attività di aggiornamento che viene poi elaborata da Discourse.
Ma, tuttavia, potrebbe sentirsi “disordinato” avere effettivamente due utenti su Discourse. È per questo che il plugin ha il suo set di funzionalità “Autorizzazione”, per permetterti di dimostrare che il tuo normale utente Discourse è associato all’attore ActivityPub con il suo utente in staging. Questo viene attualmente fatto tramite meccanismi di autorizzazione specifici della piattaforma:
-
Per Mastodon viene fatto tramite l’API OAuth di Mastodon. Richiede l’autenticazione del tuo account su Mastodon per dimostrare che controlli l’attore pertinente.
-
Per Discourse viene fatto tramite l’API Utente. Questo è ciò che viene mostrato nel video nel mio post precedente.
-
Ci sono alcuni modi in cui la stessa cosa potrebbe essere fatta per Wordpress, ad esempio DiscourseConnect tramite il plugin WP Discourse. Questo non è ancora implementato.
Una volta che dimostri di possedere l’attore associato all’utente in staging, l’utente in staging viene unito al tuo utente normale, i suoi post diventano tuoi e qualsiasi nuova Attività associata a quell’Attore diventa automaticamente tua. Ma questo set di funzionalità è in realtà più per migliorare l’UX ed è strettamente parlando non necessario. La persona reale dietro questi vari utenti controlla fin dall’inizio sia gli attributi utente che i loro contenuti.
Sì, è possibile canalizzare il target delle pubblicazioni in uscita e limitare la fonte delle pubblicazioni in entrata. Se questo vada contro lo scopo di ActivityPub è discutibile. Strettamente parlando, ActivityPub è solo uno standard. Sostengo che non c’è motivo per cui non si possa usare lo standard in questo modo. Storicamente, ActivityPub è stato associato a reti sociali decentralizzate, in particolare Mastodon, motivo per cui potresti sentire che questo tipo di approccio vada contro lo scopo di ActivityPub. Ma farei una distinzione tra lo standard ActivityPub stesso e le sue implementazioni esistenti qui.
Inoltre, in questo contesto, vorrei notare che, come l’email, quello che chiamiamo “ActivityPub” è in realtà una raccolta di standard. Il documento standard intitolato “ActivityPub” deve essere letto insieme a un altro documento standard chiamato “ActivityStreams”, che descrive gli oggetti principali in gioco qui. Lo standard ActivityStreams è più saldamente “neutro rispetto al servizio” di ActivityPub stesso (cioè meno legato alle reti sociali decentralizzate).
Per usare (un’altra) analogia, la blockchain come tecnologia è semplicemente un registro decentralizzato, la prima volta che mi è stata spiegata mi ha fatto pensare al Torrens System of land registration, inventato nel XIX secolo (in Australia) per le stesse ragioni per cui è stata inventata la blockchain (cioè per prevenire frodi nelle transazioni immobiliari). Ma l’implementazione più popolare della blockchain è Bitcoin, che ha un uso specifico (diverso) e certe valenze culturali. L’analogia non è delle migliori, ma un modo per pensarci è che Mastodon e le reti sociali decentralizzate sono per ActivityPub ciò che Bitcoin è per la blockchain.
Infatti, uno dei motivi per cui ho contribuito a istituire un nuovo gruppo di lavoro W3C ActivityPub for Forums con NodeBB, Flarum e altri è cercare di spostare l’attenzione dell’integrazione ActivityPub dalle implementazioni esistenti (ad esempio, Mastodon) alle preoccupazioni dei forum, come quelle relative alla moderazione che stai sollevando. In realtà abbiamo il nostro prossimo incontro oggi. Se hai tempo, mi piacerebbe avere un altro “Discourser” (è un termine?) lì
4 Mi Piace
Sto parlando dell’utilizzo degli strumenti di moderazione di Discourse per moderare i commenti che appaiono su WordPress. Tecnicamente ciò potrebbe essere fatto con una richiesta API di Discourse o un Webhook - dopo che un’azione di moderazione è avvenuta su Discourse, una richiesta potrebbe essere fatta per cambiare lo stato del commento su WordPress.
Supponendo che le cose vengano modificate in modo che i post di ActivityPub vengano gestiti dalla coda di revisione, ci sarebbe comunque un problema con il ritardo temporale tra quando il commento viene inizialmente pubblicato su WordPress e quando appare su Discourse. Credo che siano un paio di minuti?
Per questo caso particolare, uno dei principali punti di forza è “usa Discourse per moderare i commenti del tuo sito web”. Continua elencando le funzionalità di moderazione di Discourse, il sistema di livelli di fiducia, la coda di revisione, gli strumenti di moderazione basati sull’IA, ecc. Questi sono strumenti che sarebbero utili per i blog più piccoli, ma un requisito per i siti di notizie mainstream. Sto pensando che il modo migliore per raggiungere questo obiettivo sia utilizzare Discourse come unica fonte di verità per i commenti, invece di avere commenti che esistono su due (o più) database.
Fantastico! Senza avere il tempo di pensarci ulteriormente, non credo che sarei un ottimo rappresentante di Discourse.
Ho alcune preoccupazioni generali sull’idea di trattare argomenti, post e utenti come semplici pezzi di dati. Deve esserci un modo per assicurarsi che il contesto di dove si sta verificando una discussione non vada perso.
A livello più pratico, il protocollo ActivityPub è decollato prima dell’introduzione delle leggi sui danni online che vengono introdotte in vari paesi. Deve esserci una qualche garanzia che i server che consumano dati da un’origine rispettino le richieste di cancellazione. Altrimenti, gli utenti che generano contenuti su un server di origine rischiano ripercussioni legali se i loro contenuti vengono successivamente ritenuti dannosi nel loro paese.
3 Mi Piace