Ah, good to hear! Yeah, I guess you’re right about following someone who posts in a forum, but there could be the feature to post to the fediverse and not in a forum. NodeBB for example puts all fedi content outside communities in an “Uncategorized“ category, so if you post there it’s more or less like posting on Mastodon. Mbin also does something similar, they started as a link aggregator and added a “Microblogging“ tab. I understand it’s out of scope for Discourse for the time being, thanks for clarifying that!
2 likes
There are crazy people (like me) who want to use Discourse as their primary home in the Fediverse. I want to publish to the Fediverse only via Discourse.
Shouldn’t we support people to use Discourse as their “working in the open” or “something better than a blog” solution?
Since implementing users’ wishes does not pay, did you consider voting for features by money as an option?
4 likes
Voting by money is supported. You can fund development after making sure that the new features are pr-welcome
1 like
OTOH that is exactly what Facebook does with groups and contacts and one of the reasons it’s so sticky over there. Because you’re going to connect with your contacts anyway, and this « brings » group/community post into that space.
I could very well imagine something like that being super precious for my community. Communities bring people together and they will want to keep that connection « outside » of the community. If the community tool allows them to bring this additional connection into the same space/app, this avoids an exodus to other social spaces of people who have built strong relationships inside the community.
I know we’re not trying to « replicate Facebook » here but it is worth pondering on why it works so well for certain things.
I’d love to be able to tell my members emigrating from Facebook « see, you can create a fediverse account and connect to people you like off topic ».
Maybe it should be thought of as a way to provide community members with an off topic space which is more « open ».
From my point of view it would make complete sense. The lack of integration between « the socials » (fediverse accounts), blogs (but the connection of those with the fediverse is underway) and communities is what is stopping open tools like mastodon or discourse or Wordpress from being an effective alternative to Facebook.
1 like
Well — Mastodon and WordPress already does all of that. Discourse only partly and the direction is mostly outbound, but it isn’t social media platform.
1 like
When trying to follow @announcements@meta.discourse.org we receive the following error message:
The logs have two warnings:
Failed to process https://meta.discourse.org/ap/actor/68efb2d756abf76171ed302b7ffd3c58: Could not resolve actor
GET request to https://meta.discourse.org/ap/actor/68efb2d756abf76171ed302b7ffd3c58 failed:
We can follow actors on Mastodon, though.
Am I missing something, or how can I further investigate?
I can confirm the identical behavior; here are the logs:
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"}
2 likes
1 like
We are on 2026.1.2(808b2ac23d) with Pluginversion (d99071e0)
Just adding on here. On 2026.5.0-latest with an otherwise functioning Category Actor and experiencing the same thing. I can follow Mastodon actors, but not other Discourse ones.
3 likes
Thanks for the report, will will look into this shortly.
3 likes
A quick note here to let you all know that we have disabled the ActivityPub plugin here on meta. The plugin was a remains in maintenance mode, we will still support it with security, performance and bug fixes. On that note, we have merged several security fixes today in the plugin repo, we recommend any users of the plugin to update to latest.
On meta, unfortunately, the ActivityPub-enabled categories were only used by a few users and we had some feedback for non-ActivityPub users that were confused by the terminology, so we’ve decided to simplify things and discontinue ActivityPub integration for meta.
4 likes
One reason why out there is so few followers is a non-discourse user must know what to follow. The system isn’t now for easy social media type following, but sharing content from a forum to Fediverse and hoping that someone there is sharing (and even then a mastodon/what ever user can’t follow any discourse actor).
You know amount of followers but you don’t have any idea how many is seeing posts there. But sure, meta is kind of an edge case, because admins propably are here and ordinary users aren’t interested in technical sides of Discourse. So from that point of view I understand that decision.
2 likes
Hi, I’m trying to report an issue with the AP plugin regarding the published datetime being incorrect on posts that are manually “published” via the “Publish all posts” button.
Example
https://browser.pub/https://socialhub.activitypub.rocks/ap/object/a8d6c23e6c428313efb9bf20efeb020c
Expected behavior
published indicates the datetime the post was originally published, i.e. the datetime visible locally in Discourse (2018).
Actual behavior
published indicates the date the AP resource was created, i.e. the datetime when the “Publish” button was clicked locally in Discourse (2026).
1 like
Lately, images in my federated posts originating from my Discourse site are showing up multiple times in mastodon. Is this an ActivityPub thing or a mastodon thing? Or a misconfiguration on my end? I am not sure how to address it. Here are two examples. Mastodon seems to be trying to create a grid view when the original did not have a grid view.
1 like
bug-report created in exchange with ask.discourse.com ( bfa925d )
Build fails during ./launcher rebuild with NameError: uninitialized constant PrettyText::PrecompiledBundle when discourse-activity-pub is enabled
Environment
- Self-hosted Discourse, Docker install via
discourse_dockerlauncher, multi-container setup (Web + Sidekiq) - Ruby 3.4.0, Rails 8.0.5.1
- Branch:
latest(also reproduced the root cause on the current code)
Error
During bootstrap, at the rake db:migrate step:
rake aborted!
NameError: uninitialized constant PrettyText::PrecompiledBundle (NameError)
PrecompiledBundle.new(
^^^^^^^^^^^^^^^^^
/var/www/discourse/lib/pretty_text.rb:56:in '<module:PrettyText>'
Root cause (agents analysis)
In lib/pretty_text.rb:56, inside module PrettyText, the constant PrecompiledBundle is referenced without a :: top-level scope. Ruby therefore resolves it as PrettyText::PrecompiledBundle (file lib/pretty_text/precompiled_bundle.rb), which doesn’t exist. The actual class lives at /var/www/discourse/lib/precompiled_bundle.rb (top-level). Without a plugin, the load order happens to define it in time; with discourse-activity-pub enabled, the load order changes and the constant isn’t available when pretty_text.rb is loaded.
Proof
- Build passes error-free with all plugins disabled.
- Binary search through the plugin list: build fails with discourse-activity-pub enabled, passes with it removed/disabled.
- No other plugin triggers it.
Expected behavior
Clean build independent of which plugins are enabled, or at least a defined constant/require in lib/pretty_text.rb (e.g. ::PrecompiledBundle or an explicit require).
Question
Is this a known interaction? Any plan to fix the load order, or is there a recommended pin/workaround in the meantime?
I don’t think this has anything to do with the activity pub plugin…
Can you expand the reported error here? Do migrations start and then run into this issue or is there a specific migration that fails?
I think this part messes with the load order because it’s outside of after_initialize
2 likes
Oh, thank you for correcting me. This may be a fix then: FIX: Do not modify global plugin loading behaviour - Pull Request #338 - discourse/discourse-activity-pub - GitHub please try it @thoka and let me know how it goes.
1 like