Un problema comune che molti utenti di Discourse affrontano è l’impossibilità di visualizzare un aggregato di tutti i gruppi di interesse a cui sono iscritti. Non esiste un modo semplice per consumare contenuti da più istanze di Discourse sotto forma di un feed utente centrale e sociale. Le piattaforme centralizzate come Reddit risolvono questo problema offrendo un singolo accesso per tutte le community e un feed aggregato di tutte le community visualizzato in un unico flusso sulla pagina di destinazione di reddit.com. È quest’ultima funzionalità che vorremmo replicare in Discourse tramite il protocollo ActivityPub.
Ad esempio, la Persona A frequenta più istanze di Discourse: una per la politica, due per gli hobby, una per il forum del proprio quartiere, ma non ha modo di consumare tutti i contenuti pertinenti in un unico feed. Al contrario, se si sono uniti a più gruppi Facebook o subreddit di Reddit, i post più rilevanti appaiono già nel proprio feed.
Specifica (v1)
Potremmo prototipare un MVP abilitando le seguenti funzionalità tramite un plugin di Discourse:
Generare un feed ActivityPub su richiesta (per ogni pagina che ha già un feed RSS)
Simile all’aggiunta di .rss all’URL, questo permetterà di recuperare i contenuti utilizzando il protocollo AP richiedendo l’endpoint corretto.
Potremmo persino abilitare questa funzionalità per contenuti privati aggiungendo le chiavi API dell’utente all’URL.
Consentire agli amministratori del forum di abilitare ActivityPub (in uscita) su base per categoria o mantenerlo attivo di default? (Credo che @Falco avesse alcune idee a riguardo)
Trovare un modo per consumare questi contenuti su un forum Discourse / feed Mastodon (in entrata)
Prossimi Passi
Abbiamo assolutamente bisogno di iniziare in piccolo, quindi per prima cosa dobbiamo decidere un insieme piccolo e fattibile di funzionalità che andranno nella prima iterazione. Ho studiato il protocollo ActivityPub, ma non sono ancora molto familiare con il suo funzionamento interno. Pertanto, invito altri che hanno mostrato grande interesse in questo argomento a unirsi alla discussione (@Falco, @hellekin, @merefield) per aiutarci a costruire una specifica fattibile per la prima iterazione e a raccomandare modifiche alla specifica sopra.
Inizierei chiedendo: non dovremmo concentrarci inizialmente sul cosa e non sul come? L’architettura tecnica arriva dopo? Il motivo per cui lo dico è che scegliere troppo presto potrebbe limitare la funzionalità.
Mi piacerebbe vedere per la Versione 1. delle liste di ‘Scoperta della Scoperta’, a partire da:
Una lista ‘Ultime’, che mostri un’anteprima di ogni argomento recente dalle fonti incluse (una semplice unione delle ‘Ultime’ da tutte le fonti)
Una lista ‘Seguiti’, che mostri un’anteprima di ogni argomento per cui hai selezionato di essere notificato in caso di attività. (questa idea trae spunto dall’app mobile esistente: espande le notifiche di nuova attività sugli argomenti seguiti fino alle anteprime degli argomenti stessi).
Devo dire che la proposta originale, che fa un’analogia con Facebook, mi sfugge: non ho idea di cosa faccia Facebook e non capisco in che modo si relazioni a Discourse.
La mia comprensione del supporto ActivityPub per Discourse è che potrebbe aiutare a federare gli argomenti o persino a condividere una categoria tra diverse istanze di Discourse. Ad esempio, un argomento di annunci su discourse.joinmastodon.org potrebbe essere federato a socialhub.activitypub.rocks nella relativa categoria #software:mastodon: lì, gli utenti locali potrebbero mettere like, rispondere, citare, ecc., come se fosse un argomento locale, tranne per il fatto che l’argomento originale risiederebbe sull’istanza di joinmastodon.
Un altro aspetto è che, se si dispone di un account su entrambe le istanze, dovrebbe esserci un modo per collegarli, ovvero utilizzare una specifica istanza di Discourse come principale provider di identità. So che questo non è l’obiettivo di una prima iterazione, ma è bene tenerlo a mente, poiché potremmo finire per avere “Accedi con [inserisci qui la tua implementazione ActivityPub preferita]”.
Da quanto ho capito dalle proposte sopra, si tratta di una replica dell’app Discourse per Android, dove si ha un elenco di istanze e si ricevono notifiche da tutte. Sembra un po’ pericoloso mescolare risposte non correlate provenienti da molte fonti, soprattutto quando perdono il contesto.
Ho capito correttamente? E la mia interpretazione potrebbe costituire un buon secondo passo per la vostra visione di integrazione di ActivityPub con Discourse?
Tutte le implementazioni attuali di ActivityPub si aspettano che i post siano pubblicati da Attori stabili, quindi potrebbe essere necessario uno dei seguenti:
Un account di sistema che pubblica tutti i post
Un account per ogni feed seguibile
Un account per ogni feed seguibile, che genera Announce di post presumibilmente scritti da un account per ogni utente Discourse
Il primo è probabilmente il più semplice da implementare; il terzo fa il lavoro migliore nel far convergere i modelli di dati.
C’è anche la scelta se pubblicare l’intero contenuto del topic, solo i primi post del topic, o qualcosa di simile ai feed Twitter di StackExchange in cui vengono creati post distinti per promuovere i post dalla pagina /top. Oppure potrebbe essere semplicemente il modo in cui funziona il feed “post in evidenza”, mentre gli altri feed pubblicano tutto…
A livello tecnico, l’URL non dovrebbe dover cambiare: tutti i server invieranno Accept: application/activity+json o le sue varianti.
Un’applicazione lettore che mescola feed da fonti diverse in momenti diversi in ActivityPub - ricreando la “linea temporale algoritmica” come opzione opt-in - è qualcosa che desidero da tempo e che sembra non esistere ancora oggi.
@hellekin: Penso che l’autore incrociato tra domini abbia un’alta probabilità di aggirare fatalmente molte delle protezioni anti-spam di Discourse. La lettura è più importante da implementare: dopotutto, La lettura è fondamentale!
Non credo: gli utenti remoti potrebbero comunque essere inseriti in coda, a meno che non colleghino il loro account remoto a uno locale, nel qual caso l’antispam si applicherebbe a quell’account.
Devo ammettere di aver dato solo un’occhiata rapida ai commenti. Suggerirei che ogni categoria sia un attore autonomo (con il tipo “Group”). In questo modo, gli utenti esterni potrebbero semplicemente iscriversi a categorie specifiche. I post in queste categorie potrebbero essere implementati facendo sì che l’account “Group” annunci i post degli utenti. In questo modo avremmo sia la categoria che l’autore. È esattamente così che procediamo con il nostro software. Utilizzando le firme JSON-LD, questo sarebbe sicuro anche per le categorie non pubbliche.
La domanda è cosa fare con i commenti provenienti dall’esterno. Suggerirei che gli account di gruppo siano impostati come “approvazione manuale”. Si potrebbe quindi aggiungere un processo di validazione per evitare spam casuale. Questi account validati potrebbero poi commentare tali post.
Ciò permetterebbe immediatamente alle persone di (quasi) tutto il fediverse di connettersi e interagire con i sistemi Discourse.
Ogni gruppo di categorie potesse avere un proprietario con il potere di gestire la categoria: controllare i permessi di pubblicazione, bannare o rimuovere utenti, impostare la visibilità (pubblica o privata)…
Gli utenti locali potessero creare categorie sulla propria istanza, a condizione che lo staff dell’istanza approvi la creazione delle categorie.
Se un proprietario di categoria non è all’altezza del suo ruolo, lo staff del sito possa sostituirlo.
È così che funzionano molti forum e community centralizzati. Ciò che va migliorato è rendere il tutto federato.
Tuttavia, ci sono ancora dei problemi:
Gli id degli attori dovrebbero essere mutabili? I nomi utente di Discourse possono essere impostati come modificabili nelle impostazioni del sito. Tuttavia, dubito che altri software AP possano gestire questa funzionalità. Is Object's `id` immutable? - ActivityPub - SocialHub
(Altro da aggiungere)
C’è qualcuno del team di Discourse che parteciperà al SocialHub all’OFFDEM la prossima settimana? Sarebbe un’ottima occasione per incontrarsi e confrontarsi con altri implementatori di AP.
Alcuni punti di riferimento rapidi:
Friendica e Hubzilla possonoconvertire i feed RSS in account federati compatibili con ActivityPub/Diaspora*/OStatus.
Inoltre, consulta questo plugin per WordPress che trasforma i post in post ActivityPub.
@heluecht e @misaka4e21 hanno fatto riferimento al supporto per l’attore Group. È in corso una discussione su SocialHub sui modi per implementare questo in modo più o meno standardizzato.
5 Mi Piace
sl007
(Sebastian Lasse | @sl007@mastodon.social)
14
Congratulazioni per i fondi dell’UE!
Esiste una roadmap?
Qualcuno del team di Discourse parteciperà alla conferenza ActivityPub?
Sarebbe un’ottima occasione per incontrarsi e confrontarsi con altri implementatori di AP. https://conf.activitypub.rocks
Speriamo di discutere l’implementazione di ActivityPub in Discourse durante la sessione Birds of a Feather la prossima domenica, in occasione di APConf2020. Consulta il topic dedicato su SocialHub:
@rishabh, sarebbe fantastico averti qui, almeno nel topic se non riesci a essere presente domenica. Non sappiamo ancora l’orario esatto, ma sarà la domenica mattina. Aggiornerò questo post non appena avrò le informazioni.
Scusa se non ci sono riuscito. Devo informarti che non abbiamo fatto domanda per il finanziamento NGI0 e al momento nessuno sta lavorando su questo progetto. Non sono nemmeno la persona più adatta a guidare questa iniziativa perché non conosco bene il protocollo, ma taggerò @Falco qui per vedere se ha qualche idea o interesse a portarla avanti.
Beh, in quel momento, uno dei membri del tuo team lo ha fatto, anche se non fa più parte del team, e siete stati selezionati, quindi qualcuno ha dovuto approvarlo, quindi non so a quale “noi” ti stia riferendo. Comunque, non vedo l’ora di discutere con @Falco. Un certo tipo di supporto AP sarebbe davvero utile per la comunità ActivityPub, specialmente perché faciliterebbe il lavoro tra le istanze di Discourse e migliorerebbe l’integrazione con il Fediverse.
Sono consapevole del problema dello spam, ma penso che possa essere mitigato trattando gli utenti del Fediverse come staging simili agli utenti email non registrati, fino a quando non registrano effettivamente un account locale.
Sì, abbiamo presentato una richiesta di finanziamento in passato, ma abbiamo parlato con il team di NLnet all’inizio di quest’anno per chiudere il progetto e liberare i fondi che erano stati riservati per noi. Anche se eravamo stati selezionati allora, la collaborazione con NGI0 è annullata per ora. Naturalmente, siamo liberi di presentare nuove proposte in futuro.
Mi sono appena ricordato che anche @riking potrebbe essere interessato
1 Mi Piace
sl007
(Sebastian Lasse | @sl007@mastodon.social)
20
Interessante.
Questo progetto è stato finanziato tramite il NGI0 Discovery Fund, un fondo istituito da NLnet con il supporto finanziario del programma Next Generation Internet della Commissione europea, sotto l’egida della DG Reti di comunicazione, contenuti e tecnologie, nell’ambito dell’accordo di sovvenzione n. 825322.
Quindi: stanno parlando di un’altra “Discourse”?
Chiedo solo perché c’è “Sito web del progetto: https://discourse.org”…
Oh, non sapevo che quella pagina esistesse. Scriverò un’email al nostro referente presso NLnet per ricordargli di rimuoverla, nel caso l’avesse dimenticato, e pubblicherò un aggiornamento qui.
Comunque, non vedo l’ora di discutere con