ああ、それはよかった！ええ、フォーラムに投稿する人をフォローすることについてはおっしゃる通りだと思いますが、フォーラムではなく、フェディバースに投稿する機能があるかもしれません。例えば、NodeBBはコミュニティ外のすべてのフェディコンテンツを「未分類」カテゴリに入れるので、そこに投稿するのはマストドンに投稿するのとほぼ同じです。Mbinも同様の機能があり、リンクアグリゲーターとして始まり、「マイクロブログ」タブを追加しました。現時点ではDiscourseのスコープ外であることは理解しました。明確にしていただきありがとうございます！
「いいね！」 2
私のような（私のような）狂信者がいて、DiscourseをFediverseでの主要なホームとして使いたいと考えています。Discourse経由でのみFediverseに公開したいのです。
Discourseを「オープンでの作業」や「ブログよりも優れたもの」のソリューションとして使う人々をサポートすべきではないでしょうか？
ユーザーの要望を実装しても収益にならないため、金銭による機能投票をオプションとして検討しましたか？
「いいね！」 4
資金による投票はサポートされています。新しい機能が#pr-welcomeであることを確認した後、開発に資金を提供することができます。
「いいね！」 1
一方で、Facebookがグループや連絡先に対して行っているのはまさにそれで、Facebookが非常に定着している理由の一つでもあります。なぜなら、ユーザーはいずれにせよ連絡先とつながるつもりであり、この機能がグループ/コミュニティの投稿をそのスペースに「連れてくる」からです。
私のコミュニティにとって、そのようなものが非常に貴重になることを容易に想像できます。コミュニティは人々を結びつけ、彼らはコミュニティの「外」でもそのつながりを維持したいと考えるでしょう。コミュニティツールが、この追加のつながりを同じスペース/アプリにもたらすことを可能にすれば、コミュニティ内で強い関係を築いた人々が他のソーシャルスペースへ流出するのを防ぐことができます。
ここで「Facebookを複製」しようとしているわけではないことは承知していますが、それが特定の事柄に対してなぜこれほどうまく機能するのかを熟考する価値はあります。
Facebookから移行してくるメンバーに、「ほら、Fediverseアカウントを作成して、トピック外で好きな人とつながることができるよ」と言えるようになりたいです。
おそらく、これはコミュニティメンバーに、より「オープンな」トピック外のスペースを提供する方法として考えるべきかもしれません。
私の視点からすれば、これは完全に理にかなっています。MastodonやDiscourse、WordpressのようなオープンなツールがFacebookの有効な代替手段になるのを妨げているのは、「ソーシャル」（Fediverseアカウント）、ブログ（ただし、それらとFediverseとの連携は進行中）、そしてコミュニティとの間の統合の欠如です。
「いいね！」 1
そうですね、MastodonとWordPressはすでにそれらすべてを行っています。Discourseは部分的にしか行っておらず、その方向性は主にアウトバウンドですが、ソーシャルメディアプラットフォームではありません。
「いいね！」 1
@announcements@meta.discourse.org をフォローしようとすると、次のエラーメッセージが表示されます。
ログには 2 つの警告があります。
https://meta.discourse.org/ap/actor/68efb2d756abf76171ed302b7ffd3c58 の処理に失敗しました: アクターを解決できませんでした
https://meta.discourse.org/ap/actor/68efb2d756abf76171ed302b7ffd3c58 への GET リクエストが失敗しました:
ただし、Mastodon ではアクターをフォローできます。
何か見落としていますか、それともさらに調査するにはどうすればよいでしょうか？
同一の動作を確認しました。ログは以下の通りです。
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
2026.1.2(808b2ac23d)にいて、プラグインバージョンは(d99071e0)です。
追記します。2026.5.0-latestで、正常に動作するカテゴリアクターを使用しているにもかかわらず、同じ現象が発生しています。Mastodon のアクターはフォローできますが、Discourse のアクターはフォローできません。
「いいね！」 3
ご報告ありがとうございます。すぐに確認いたします。
「いいね！」 3
一言お知らせがあります。メタ上で ActivityPub プラグインを無効にしたことをご報告します。このプラグインはメンテナンスモードで運用されていましたが、セキュリティ、パフォーマンス、バグ修正のサポートは継続します。なお、本日はプラグインリポジトリに複数のセキュリティ修正をマージしましたので、プラグインをご利用の方は最新版への更新を推奨します。
メタ上では、ActivityPub 対応カテゴリはごく一部のユーザーによってのみ使用されており、ActivityPub を使用していないユーザーから用語について混乱をきたすというフィードバックもいただいていました。そのため、簡素化を図るため、メタでの ActivityPub 統合を廃止することにしました。
「いいね！」 4
フォロワーが少ない理由の一つは、ディスコースユーザーが誰をフォローすべきかを知っている必要があることです。このシステムは、簡単なソーシャルメディア型のフォローではなく、フォーラムからフェディバースへコンテンツを共有し、そこで誰かが共有することを期待するものです（それでもマストドンやその他のユーザーは、ディスコースのアクターをフォローできません）。
フォロワーの数はわかりますが、そこで投稿を見ている人の数はわかりません。しかし、確かにメタは一種のエッジケースです。管理者はおそらくここにいて、一般ユーザーはディスコースの技術的な側面には興味がないからです。その観点から、その決定を理解できます。
「いいね！」 2
こんにちは、APプラグインに関する問題を報告しようとしています。手動で「すべての投稿を公開」ボタンを通じて「公開」された投稿において、published 日付が正しくないという問題です。
例
https://browser.pub/https://socialhub.activitypub.rocks/ap/object/a8d6c23e6c428313efb9bf20efeb020c
期待される動作
published は、投稿が最初に公開された日時、つまりDiscourse上でローカルに表示される日時（2018年）を示すべきです。
実際の動作
published は、APリソースが作成された日付、つまりDiscourse上でローカルに「公開」ボタンがクリックされた日時（2026年）を示しています。
「いいね！」 1
最近、私の Discourse サイトから発信された連合投稿（フェデレーテッド投稿）の画像が、Mastodon で重複して表示されるようになりました。これは ActivityPub の仕様によるものなのか、Mastodon 側の問題なのか、それとも私の設定ミスなのか。どう対処すればよいのか分かりません。以下に2つの例を示します。Mastodon は、元の投稿がグリッド表示になっていないにもかかわらず、グリッド表示を作成しようとしているようです。
「いいね！」 1
ask.discourse.com とのやり取りでバグレポートを作成しました ( bfa925d )
discourse-activity-pub が有効な状態で ./launcher rebuild を実行すると、NameError: uninitialized constant PrettyText::PrecompiledBundle が発生し、ビルドが失敗する
環境
- セルフホスト型 Discourse、
discourse_dockerランチャーによる Docker インストール、マルチコンテナ構成 (Web + Sidekiq) - Ruby 3.4.0、Rails 8.0.5.1
- ブランチ:
latest(現在のコードでも根本原因を再現)
エラー
ブートストラップ中、rake db:migrate ステップで発生:
rake aborted!
NameError: uninitialized constant PrettyText::PrecompiledBundle (NameError)
PrecompiledBundle.new(
^^^^^^^^^^^^^^^^^
/var/www/discourse/lib/pretty_text.rb:56:in '<module:PrettyText>'
根本原因 (エージェントによる分析)
lib/pretty_text.rb:56 の module PrettyText 内で、定数 PrecompiledBundle がトップレベルのスコープである :: を付けずに参照されています。そのため、Ruby はこれを PrettyText::PrecompiledBundle (ファイル lib/pretty_text/precompiled_bundle.rb) として解決しようとしますが、これは存在しません。実際のクラスは /var/www/discourse/lib/precompiled_bundle.rb (トップレベル) にあります。プラグインがない場合、ロード順序の都合上、タイムリーに定義されますが、discourse-activity-pub が有効な場合、ロード順序が変わり、pretty_text.rb がロードされる時点で定数が利用可能になりません。
証拠
- すべてのプラグインを無効にすると、エラーなしでビルドが成功します。
- プラグインリストのバイナリ検索: discourse-activity-pub が有効な状態でビルドが失敗し、それを削除/無効にすると成功します。
- 他のプラグインではトリガーされません。
期待される動作
どのプラグインが有効かに関係なく、クリーンにビルドできること、または少なくとも lib/pretty_text.rb 内で定数/require が定義されていること (例: ::PrecompiledBundle または明示的な require)。
質問
これは既知の相互作用ですか? ロード順序を修正する計画はありますか、それとも当面、推奨されるピン留め/ワークアラウンドはありますか?
「いいね！」 1
これはActivityPubプラグインとは関係ないと思います。
報告されたエラーについて詳しく教えていただけますか？マイグレーションが始まってからこの問題に遭遇するのか、それとも特定のマイグレーションが失敗しているのですか？
この部分は after_initialize の外にあるため、ロード順序を崩す原因になっていると思います。
「いいね！」 2
ああ、訂正してくれてありがとう。これが修正になるかもしれない：https://github.com/discourse/discourse-activity-pull/338 @thoka 試してみて、結果を教えてくれる？
「いいね！」 1