Ah, lieto di sentirlo! Sì, immagino tu abbia ragione riguardo al seguire qualcuno che pubblica su un forum, ma potrebbe esserci la funzionalità di pubblicare sul fediverso e non in una community. NodeBB, ad esempio, mette tutti i contenuti del fediverso al di fuori delle community in una categoria “Non categorizzato”, quindi se pubblichi lì è più o meno come pubblicare su Mastodon. Anche Mbin fa qualcosa di simile, hanno iniziato come aggregatore di link e hanno aggiunto una scheda “Microblogging”. Capisco che per il momento sia fuori dallo scopo di Discourse, grazie per averlo chiarito!
Ci sono persone matte (come me) che vogliono usare Discourse come loro casa principale nel Fediverso. Voglio pubblicare sul Fediverso solo tramite Discourse.
Non dovremmo supportare le persone che vogliono usare Discourse come soluzione per il loro “lavorare allo scoperto” o “qualcosa di meglio di un blog”?
Dato che implementare i desideri degli utenti non paga, avete considerato di votare per le funzionalità tramite denaro come opzione?
Il voto a pagamento è supportato. Puoi finanziare lo sviluppo dopo esserti assicurato che le nuove funzionalità siano pr-welcome
D’altra parte, è esattamente quello che fa Facebook con i gruppi e i contatti ed è uno dei motivi per cui è così “appiccicoso” lì. Perché ti connetterai comunque con i tuoi contatti, e questo “porta” i post del gruppo/comunità in quello spazio.
Potrei benissimo immaginare qualcosa del genere come super prezioso per la mia comunità. Le comunità riuniscono le persone e vorranno mantenere questa connessione “al di fuori” della comunità. Se lo strumento della comunità permette loro di portare questa connessione aggiuntiva nello stesso spazio/app, questo evita un esodo verso altri spazi sociali delle persone che hanno costruito forti relazioni all’interno della comunità.
So che non stiamo cercando di “replicare Facebook” qui, ma vale la pena riflettere sul perché funzioni così bene per certe cose.
Mi piacerebbe poter dire ai miei membri che emigrano da Facebook: “vedi, puoi creare un account fediverso e connetterti con persone che ti piacciono fuori tema”.
Forse dovrebbe essere pensato come un modo per fornire ai membri della comunità uno spazio fuori tema che sia più “aperto”.
Dal mio punto di vista avrebbe senso. La mancanza di integrazione tra “i social” (account fediverso), i blog (ma la connessione di questi con il fediverso è in corso) e le comunità è ciò che impedisce a strumenti aperti come Mastodon o Discourse o Wordpress di essere un’alternativa efficace a Facebook.
Beh, Mastodon e WordPress fanno già tutto questo. Discourse solo in parte e la direzione è per lo più in uscita, ma non è una piattaforma di social media.
Quando tentiamo di seguire @announcements@meta.discourse.org riceviamo il seguente messaggio di errore:
I log presentano due avvisi:
Impossibile elaborare https://meta.discourse.org/ap/actor/68efb2d756abf76171ed302b7ffd3c58: Impossibile risolvere l’attore
Richiesta GET a https://meta.discourse.org/ap/actor/68efb2d756abf76171ed302b7ffd3c58 fallita:
Tuttavia, possiamo seguire gli attori su Mastodon.
Mi sto perdendo qualcosa, o come posso indagare ulteriormente?
Posso confermare lo stesso comportamento; ecco i log:
Started POST "/webfinger/handle/validate" for 172.17.0.1 at 2026-03-15 16:10:39 +0000
Processing by DiscourseActivityPub::Webfinger::HandleController#validate as JSON
Parameters: {"handle"=>"@announcements@meta.discourse.org"}
Completed 200 OK in 36ms (Views: 0.2ms | ActiveRecord: 0.0ms (0 queries, 0 cached) | GC: 11.8ms)
Started GET "/ap/local/actor/57934/find-by-handle?handle=%40announcements%40meta.discourse.org" for 172.17.0.1 at 2026-03-15 16:10:40 +0000
Processing by DiscourseActivityPub::ActorController#find_by_handle as JSON
Parameters: {"handle"=>"@announcements@meta.discourse.org", "actor_id"=>"57934"}
Started POST "/webfinger/handle/validate" for 172.17.0.1 at 2026-03-15 16:10:43 +0000
Processing by DiscourseActivityPub::Webfinger::HandleController#validate as JSON
Parameters: {"handle"=>"@announcements@meta.discourse.org"}
Completed 200 OK in 32ms (Views: 0.2ms | ActiveRecord: 0.0ms (0 queries, 0 cached) | GC: 0.8ms)
Started GET "/ap/local/actor/57934/find-by-handle?handle=%40announcements%40meta.discourse.org" for 172.17.0.1 at 2026-03-15 16:10:43 +0000
Processing by DiscourseActivityPub::ActorController#find_by_handle as JSON
Parameters: {"handle"=>"@announcements@meta.discourse.org", "actor_id"=>"57934"}
Started POST "/webfinger/handle/validate" for 172.17.0.1 at 2026-03-15 16:10:43 +0000
Processing by DiscourseActivityPub::Webfinger::HandleController#validate as JSON
Parameters: {"handle"=>"@announcements@meta.discourse.org"}
Completed 200 OK in 30ms (Views: 0.2ms | ActiveRecord: 0.0ms (0 queries, 0 cached) | GC: 0.0ms)
Started GET "/ap/local/actor/57934/find-by-handle?handle=%40announcements%40meta.discourse.org" for 172.17.0.1 at 2026-03-15 16:10:43 +0000
Processing by DiscourseActivityPub::ActorController#find_by_handle as JSON
Parameters: {"handle"=>"@announcements@meta.discourse.org", "actor_id"=>"57934"}
Started POST "/webfinger/handle/validate" for 172.17.0.1 at 2026-03-15 16:10:44 +0000
Processing by DiscourseActivityPub::Webfinger::HandleController#validate as JSON
Parameters: {"handle"=>"@announcements@meta.discourse.org"}
Completed 200 OK in 26ms (Views: 0.2ms | ActiveRecord: 0.0ms (0 queries, 0 cached) | GC: 0.3ms)
Started GET "/ap/local/actor/57934/find-by-handle?handle=%40announcements%40meta.discourse.org" for 172.17.0.1 at 2026-03-15 16:10:44 +0000
Processing by DiscourseActivityPub::ActorController#find_by_handle as JSON
Parameters: {"handle"=>"@announcements@meta.discourse.org", "actor_id"=>"57934"}
Started POST "/webfinger/handle/validate" for 172.17.0.1 at 2026-03-15 16:10:44 +0000
Processing by DiscourseActivityPub::Webfinger::HandleController#validate as JSON
Parameters: {"handle"=>"@announcements@meta.discourse.org"}
Completed 200 OK in 24ms (Views: 0.2ms | ActiveRecord: 0.0ms (0 queries, 0 cached) | GC: 0.3ms)
Started GET "/ap/local/actor/57934/find-by-handle?handle=%40announcements%40meta.discourse.org" for 172.17.0.1 at 2026-03-15 16:10:44 +0000
Processing by DiscourseActivityPub::ActorController#find_by_handle as JSON
Parameters: {"handle"=>"@announcements@meta.discourse.org", "actor_id"=>"57934"}
Su quale versione di Discourse ti trovi? Riesco a trovare quell’attore in un’altra istanza di Discourse:
Siamo su 2026.1.2(808b2ac23d) con Pluginversion (d99071e0)
Aggiungo qui. Con la versione 2026.5.0-latest, con un attore di categoria altrimenti funzionante, sto riscontrando lo stesso problema. Posso seguire gli attori di Mastodon, ma non quelli di Discourse.
Grazie per la segnalazione, ci occuperemo di ciò a breve.
Un rapido avviso per informarvi che abbiamo disabilitato il plugin ActivityPub qui su Meta. Il plugin era rimasto in modalità di manutenzione; continueremo comunque a supportarlo con aggiornamenti di sicurezza, ottimizzazioni delle prestazioni e correzioni di bug. A tal proposito, oggi abbiamo unito al repository diversi fix di sicurezza; raccomandiamo a tutti gli utenti del plugin di aggiornare all’ultima versione.
Su Meta, purtroppo, le categorie abilitate ad ActivityPub erano utilizzate da pochi utenti e abbiamo ricevuto alcuni feedback da utenti non interessati ad ActivityPub, che si erano confusi a causa della terminologia. Abbiamo quindi deciso di semplificare le cose e interrompere l’integrazione con ActivityPub su Meta.
Un motivo per cui ci sono così pochi follower è che un utente di Discourse deve sapere cosa seguire. Il sistema non è pensato per un tipo di follow facile come quello dei social media, ma per la condivisione di contenuti da un forum al Fediverso, sperando che qualcuno lì li condivida (e anche in quel caso, un utente di Mastodon o altro non può seguire un attore di Discourse).
Conosci il numero di follower, ma non hai idea di quanti vedano i tuoi post. Tuttavia, Meta è un caso particolare, perché probabilmente gli amministratori sono qui e gli utenti comuni non sono interessati agli aspetti tecnici di Discourse. Da questo punto di vista, capisco la decisione.
Ciao, sto cercando di segnalare un problema con il plugin AP relativo al fatto che il campo published (data di pubblicazione) non è corretto per i post che vengono pubblicati manualmente tramite il pulsante “Pubblica tutti i post”.
Esempio
https://browser.pub/https://socialhub.activitypub.rocks/ap/object/a8d6c23e6c428313efb9bf20efeb020c
Comportamento atteso
published indica la data e l’ora in cui il post è stato pubblicato originariamente, ovvero la data visibile localmente in Discourse (2018).
Comportamento effettivo
published indica la data e l’ora in cui la risorsa AP è stata creata, ovvero il momento in cui è stato cliccato il pulsante “Pubblica” localmente in Discourse (2026).
Ultimamente, le immagini nei miei post federati provenienti dal mio sito Discourse appaiono più volte su Mastodon. È una questione di ActivityPub o di Mastodon? O forse una configurazione errata da parte mia? Non sono sicuro di come risolvere il problema. Ecco due esempi. Mastodon sembra cercare di creare una visualizzazione a griglia quando l’originale non aveva una visualizzazione a griglia.
bug-report creato in exchange con ask.discourse.com ( bfa925d )
La build fallisce durante ./launcher rebuild con NameError: uninitialized constant PrettyText::PrecompiledBundle quando discourse-activity-pub è abilitato
Ambiente
- Discourse self-hosted, installazione Docker tramite launcher
discourse_docker, configurazione multi-container (Web + Sidekiq) - Ruby 3.4.0, Rails 8.0.5.1
- Branch:
latest(la causa principale è stata riprodotta anche sul codice attuale)
Errore
Durante il bootstrap, al passaggio rake db:migrate:
rake aborted!
NameError: uninitialized constant PrettyText::PrecompiledBundle (NameError)
PrecompiledBundle.new(
^^^^^^^^^^^^^^^^^
/var/www/discourse/lib/pretty_text.rb:56:in '<module:PrettyText>'
Causa principale (analisi degli agenti)
In lib/pretty_text.rb:56, all’interno di module PrettyText, la costante PrecompiledBundle viene riferita senza lo scope di livello superiore ::. Ruby la risolve quindi come PrettyText::PrecompiledBundle (file lib/pretty_text/precompiled_bundle.rb), che non esiste. La classe effettiva si trova in /var/www/discourse/lib/precompiled_bundle.rb (livello superiore). Senza un plugin, l’ordine di caricamento avviene in modo tale da definirla in tempo; con discourse-activity-pub abilitato, l’ordine di caricamento cambia e la costante non è disponibile quando viene caricato pretty_text.rb.
Prova
- La build passa senza errori con tutti i plugin disabilitati.
- Ricerca binaria nell’elenco dei plugin: la build fallisce con discourse-activity-pub abilitato, passa con questo rimosso/disabilitato.
- Nessun altro plugin lo provoca.
Comportamento atteso
Build pulita indipendentemente dai plugin abilitati, oppure almeno una costante/require definita in lib/pretty_text.rb (ad esempio ::PrecompiledBundle o un require esplicito).
Domanda
Questa è un’interazione nota? Ci sono piani per correggere l’ordine di caricamento, o c’è un pin/una soluzione alternativa raccomandata nel frattempo?
Non credo che questo abbia a che fare con il plugin Activity Pub…
Puoi espandere l’errore riportato qui? Le migrazioni iniziano e poi si imbattono in questo problema, o c’è una migrazione specifica che fallisce?
Penso che questa parte interferisca con l’ordine di caricamento perché si trova all’esterno di after_initialize
Oh, grazie per avermi corretto. Questa potrebbe essere una soluzione: FIX: Do not modify global plugin loading behaviour - Pull Request #338 - discourse/discourse-activity-pub - GitHub per favore provala @thoka e fammi sapere com’è andata.






