Ciao a tutti @rishabh, @riking, @codinghorror,
(Sì, c’è un TL;DR qui sotto)
Qualche tempo fa ho capito da @sl007 e @hellekin che non perseguirete questa Fase 1 nel breve termine, anche con il finanziamento NGI0. Come promotore della interoperabilità basata su ActivityPub, trovo anche io, naturalmente, che sia un peccato. Ma dal punto di vista di Discourse, il software per forum leader e più popolare, ci sono molte forze e altre priorità da considerare, e questa decisione aziendale, alla luce di ciò, probabilmente ha molto senso:
Decisione: Questa RFC, così com’è proposta, non era semplicemente abbastanza attraente per ottenere priorità e essere inserita nella Roadmap.
La RFC ha adottato un approccio MVP con “Iniziamo creando un feed di contenuti aggregati simile a Facebook tra i forum”, come proposto da @Falco. È solo una delle tante, moltissime funzionalità che potrebbero derivare dal supporto nativo di ActivityPub in una forma o nell’altra. Si può dire che avere una tale timeline sia una sorta di deviazione da ciò che normalmente si trova in un forum, e a me non sembra una vera funzionalità principale. Piuttosto un’estensione aggiuntiva e quindi un “nice-to-have”.
Un approccio diverso
Con la necessità di arrivare rapidamente a un MVP del supporto ActivityPub fuori dai giochi, forse potremmo seguire il processo opposto:
Ideazione: Brainstorming sui casi d’uso di interoperabilità e valutarne la fattibilità in termini di vantaggio commerciale e USP.
Cioè: quali funzionalità sarebbero davvero attraenti da avere in Discourse? O anche: Dove potrebbe Discourse perdere l’occasione se non fosse al corrente di ciò che è possibile?
Nel suo ultimo post sopra, @Falco menziona Lemmy, che è costruito da zero su un vocabolario di Dati Collegati dedicato che corrisponde al loro dominio aziendale. Hanno il loro MVP pronto e in produzione, e ora stanno valutando l’espansione del loro set di funzionalità sul loro stesso dominio. Questo potrebbe includere la federazione con un altro dominio del microblogging dove Mastodon, Pleroma e altri hanno molto successo.
L’approccio all’ideazione potrebbe seguire questo esercizio:
Esercizio: Immaginiamo come Discourse potrebbe essere apparso se fosse stato basato fin dall’inizio sul proprio dominio aziendale basato su ActivityPub (definito come un vocabolario di Dati Collegati).
Lasciamoci andare in questa sessione di brainstorming e lasciamo correre libera la nostra creatività.
L’elenco dei casi d’uso che ne risultano potrebbe essere abbastanza interessante dal punto di vista commerciale da entrare a far parte della Roadmap, ma se non lo fosse, potrebbe comunque ispirare la comunità a creare plugin e componenti, e porre le basi su cui costruire in una fase successiva.
ActivityPub contro Fediverse
Noto che c’è un diffuso malinteso su cosa significhi avere il supporto ActivityPub in un’applicazione. Molti pensano che il motivo per farlo sia diventare “parte del Fediverse”. E qui il pensiero va immediatamente alla federazione con le istanze di Mastodon, ovvero implementare l’interoperabilità con (cioè unirsi al) dominio federato del microblogging.
Sì, questa è un’opportunità molto attraente una volta ottenuto il supporto ActivityPub, e molte altre applicazioni come PixelFed (alternativa a Instagram), PeerTube (alternativa a YouTube) e anche Lemmy (alternativa a Reddit) mirano a farlo. Rendono il Fediverse un luogo più attraente in cui partecipare, e stanno prendendo forma molte innovazioni che rendono il futuro del fediverse davvero entusiasmante.
MA…
Si può obiettare che organizzazioni che mirano a grandi basi di utenti come Discourse potrebbero porsi domande come: “Perché dovrei voler integrare il Fediverse con solo circa 4 milioni di utenti?” o “Perché dovrei integrare il microblogging nel mio software che opera in un dominio completamente diverso?”. E avrebbero ragione a affermarlo, e a rinunciare all’implementazione di ActivityPub su quella premessa.
TUTTAVIA…
Le implementazioni di ActivityPub riguardano molto di più che diventare parte del (parte del microblogging del) Fediverse. Ha perfettamente senso implementare un vocabolario di Dati Collegati progettato in modo univoco per il proprio dominio aziendale e far federare insieme le proprie istanze di prodotto. O tutte le istanze del proprio prodotto e quelle dei concorrenti nel proprio settore che adottano lo stesso vocabolario, per l’appunto.
Un esempio qui è il progetto ForgeFed che mira a definire standard di interoperabilità per le forge di codice (github, gitlab, gitea, sourcehut, ecc.) da implementare. Fare questo ha un enorme senso, specialmente per i progetti di forge di codice più piccoli per offrire un’alternativa attraente a Github (che è diventato troppo dominante come piattaforma centralizzata e sempre più chiusa). Se adottato ampiamente, gli sviluppatori non dovranno più gestire una moltitudine di account forge su server sparsi per internet per partecipare a interessanti progetti di codice, aprire issue, commentare e inviare PR.
(Si noti che - come indicato sopra - lo stesso problema che le persone hanno con l’esistenza ovunque di forge di codice standalone è ciò che io e altri sperimentiamo anche nella nostra partecipazione a un mucchio di comunità Discourse.)
Opportunità: Discourse è in una posizione unica per prendere l’iniziativa nel definire gli standard di interoperabilità per il software di forum e plasmare lo standard in modo che si allinei perfettamente con l’attuale set di funzionalità di Discourse.
Ci sono alcuni concorrenti emergenti nel vostro settore, che sono innovativi, adottano approcci freschi e iterano rapidamente aggiungendo nuove funzionalità (voi di Discourse sapete meglio di chi si tratta 
). A mio parere, Discourse per completezza delle funzionalità è ancora ben al di sopra di ciò che i loro prodotti offrono. E avete una comunità come nessun’altra per aiutarvi a evolvere il prodotto.
Ma l’opportunità di interoperabilità che esiste ora potrebbe anche diventare una minaccia. O i concorrenti potrebbero cogliere per primi l’opportunità, o - forse spinti dall’EU Digital Markets Act - le piattaforme Big Tech creeranno qualcosa con sovrapposizioni nel dominio del software di forum. In entrambi i casi sarebbe più difficile per Discourse allinearsi a questo standard e avere la voce più autorevole nella progettazione della sua specifica.
TL;DR
Questo è diventato un post più lungo di quanto intendessi. Mi scuso per questo 
In sintesi, sostengo che, data l’attuale posizione sul supporto ActivityPub, potrebbe essere prudente passare da un focus di breve termine simile a un MVP, a una valutazione più ampia di ciò che l’interoperabilità di ActivityPub potrebbe portare a Discourse in termini di USP e posizionamento nel lungo termine. Cioè, elaborare il caso d’affari dell’adozione di ActivityPub, iniziando con una fase di ideazione.
(Come impostare al meglio questo processo - nel caso foste interessati - lo lascio in sospeso, ma potrebbe iniziare semplicemente con un nuovo argomento AP che abbia in alto un wiki riassuntivo dei casi d’uso raccolti e persone che discutono idee di casi d’uso nel thread)