Discourse のインスタンスは多数存在します。正確な数はわかりませんが、私は数十のインスタンスにアカウントを持っています。すべてを把握するのは不可能で、よく似たコミュニティで類似のトピックが議論されていることが多く、一部の参加者が複数の議論で同じ話を繰り返しているため、インスタンスをまたいで共有できる可能性があります。複数のインスタンスにログインしたり、トピックを相互参照したりする必要なく、関係者と円滑に議論できるようにすれば、本当に役立つでしょう。
ActivityPub ユーザーを、Discourse インスタンス外のメールユーザーと同様に、段階的に登録されたユーザーとして扱うことは、良い妥協案の始まりだと思われます。
RSS フィードを使えば、単一の場所で進行中のトピックを追跡できますが、Discourse Hub アプリとは異なる利点はなく、参加することもできません。
@hellekin これはどうでしょうか。もしかしたらあなたの言う通りかもしれませんし、そうではないかもしれません。
ナイトクラブ、レストラン、スーパーマーケット、ソフトウェアなど、たくさんあります。地理的にも、提供するものにおいても、かなり近いものさえあります。同じことを提供している異なる場所が「ばかげている」と見なされるべきでしょうか？それとも、これらを統合して一つにまとめるべきなのでしょうか？
さて、ここでは少し進んでいて、コミュニティはどちらかと言えば分離されたままですが、リンクで結ばれています。残る問題は、すべてのコミュニティが「同じ」かどうかです。同じルール、同じ雰囲気、同じ種類の人が集まっているでしょうか？これがコミュニティを「特別な場所」として、（積極的に）参加する価値があるものとしているのかもしれません。つまり、それが独自であるという事実です。独特な雰囲気、独特なユーモア、など。そして、ここには人々が大きな要素として関わっています。誰がどこに行くか、どのような人がいるか。
これは多様性に対する見方かもしれません。すべてを混ぜ合わせて、どこでも「同じ」ものになってしまう結果になることです。なぜなら、あまりにも混ざり合っているからです。
他方、リンクや引用があります。どこかで起こっていることにリンクしたり、引用したり、要約したりすることを妨げるものは何もありません。そしてここでは、それぞれの場所のアイデンティティを保ちながら、すべてを「同じ」にしてしまうことを避けられます。
とにかく、これは ActivityPub の原則そのもの、そしてそれを Discourse に実装したいという意欲の根底にある核心的な問いかもしれません。もちろん、それがオプションである場合、誰もが好きなように行動できます。そして、オプションがあることは一般的に良いことです。私見ですが（なぜ成功しているコミュニティが、そのコンテンツを外部と共有し、外部の人々がそれと相互作用できるようにしたいと思うのか、あまりよくわかりません）。
[それはいわば『デモリション・マン』のようなもので、タコベルのレストランしか残っていないようなものではないでしょうか？]
私の前の投稿とあなたの見解がどう関連しているのか、よくわかりません。コミュニティの統合については何も言っておらず、単に共通のトピックについて触れただけです。それも、ユーザーアカウントが代理となり得ると提案しただけの話です。
そして、これは異なるコミュニティの提供物を「統合」していることになりませんか？前のメッセージで述べたとおり、それでも一部のコンテンツは「統合」されます。
Discourse チームにはそれを行うための意欲がなさそうであり、その上での明確な利点やユースケースも不明確なようです。もし私の前の投稿が主題とどう関連するか見えないのであれば、それで結構です。お詫びします。この件は忘れましょう。
決してそうではありません。しかし、地元の新聞でそれらについて読みたいと思いますし、より専門的なケースでは、美食通向けのイタリア料理ガイドを読むかもしれません。すべてが同じでないことが、それらに購読する価値を生み出しているのです。ウェブとコミュニティに戻りましょう。リンクを貼ったり引用したりすることは確かに価値がありますが、それらは別のユースケースであり、フォーラム間でトピックを共有し、スレッドを文脈の中で閲覧する、あるいは直接参加することとは異なります。
あなたは、ある場合ではアイデンティティを混在させたくなく、ましてや分散したコミュニティを完全に統合したくはないと指摘しています。それは正しいです。しかし、意味がある部分だけを選択的に統合することは可能です。トピックごと、特定の（サブ）カテゴリ、タグ、またはコンテンツを共有する特定の人のグループなどです。
これは実際には ActivityPub に関するものではありません。このプロトコルは HTTP を基盤とした非常に低レベルのものです。これを使って何でも構築できます。ActivityPub に言及すると、人々は往々にしてマイクロブログ（Mastodon）を思い浮かべがちですが、それは現在最も人気のあるアプリケーションだからです。このドメインを考えると、誰もが「自分だけのユニークなコミュニティ」を、誰をフォローするかによって定義しながら作っています。これにより、個人のタイムラインが生まれます。それ以外に、例えば mastodon.technology でアカウントを作成し、サーバーのタイムラインが概ね「技術」をテーマにしているかもしれません。しかし、このドメインは Discourse には確かに合いません。マイクロブログであって、コミュニティフォーラムではないからです。
現在、いくつかのマイクロブログアプリケーションは、そのドメインに「グループ」という概念を追加しています。これはサーバーの境界を越えて拡張されるコミュニティ概念と見なすことができます。つまり、mastodon.technology にいる間でも、「スパゲッティ」グループや「気候変動」グループに加入できるかもしれません。しかし、それでもそれはマイクロブログに過ぎません。すべてが圧縮され、私のタイムラインに平坦化されます。
成功したコミュニティとは何でしょうか？その境界はどこで、内部と外部は何でしょうか？これらは非常に明確に定義されており、アイデンティティや多様性に関係するかもしれません。しかし、これらが本質的に関係するのは、特定のサーバーの境界ではありません！
私は コミュニティに境界はない という記事で非常に広い範囲を取り上げましたが、そこで扱った人工的なサーバーの境界なしに考えること（そしてそれがコミュニティの質、量、活動をどのように向上させるか）についてでした。アイデンティティについては触れませんでしたが、これも取り上げるべき良い点です。@Mevo さん、あのスレッドに返信してくださりありがとうございます。適切なタイミングで返信いたします。
@aschrijver さん、ありがとうございます。とても参考になりました。
最初の段落からは「賢く使う」という考え方を得ました。
2 段落目については、「ActivityPub」という言葉で指していたのは、プロトコルそのものというより、それが可能にするものや行うこと、つまり「コンテンツの共有・リンク」や「サーバーの境界からコンテンツを解放する」といった点についてでした。
コントロール権や権力の移行という考え方は興味深いですね。これにより、コミュニティの所有者がもはや「自らの」ユーザーやコンテンツ（少なくともホストしているもの）、訪問者がアクセスできる情報、情報の整理やグループ化などを支配するわけではなくなります。ユーザー側がよりコントロールを持ち、どこからでも好きなものを選んで「自分だけのメニュー」を作成できるようになるのです。
これはユーザーの視点からは魅力的に映る一方、コミュニティ所有者の視点からは少し恐ろしく、不安に思える部分もあるかもしれません。
レストランのたとえ話で言えば、複数の店舗を統合するという私の主張は少し行き過ぎだったかもしれません。しかし、あなたの使ったたとえは甘すぎるように思います。私個人の見解では、それ以上のことが起こるのです。あるレストランに行って、別の店のシェフが作った料理を注文できるような状態です。これには疑問が生じます（これが私の主張の大きな部分でした）。なぜ、そのシェフに高給を払い、採用や定着に苦労したレストランのオーナーが、顧客に自らの店に来る明確な理由を与えなくなることを望むのか、という点です。あなたの回答は「顧客の視点からは素晴らしい」というものでした。はい、確かにその通りです。
しかし、いずれにせよ、あなたの言うことが正しいかもしれません。私が指摘している点は、過去のオープンソースに対する企業の懸念と非常に似ているように思えます。
NGIグラントからこの機能開発を支援するニュースがありましたが、オファーは却下されました。来年は別のグラントに応募する予定です。
それは素晴らしいでしょう。
ActivityPubの実装に関する現在の状況（11月22日現在）を誰か要約してもらえませんか？関連するスレッドをいくつか確認しましたが、現在の私の理解は以下の通りです。
この理解は正しいでしょうか？私はドイツの大規模な政党で働いており、インスタンス間でアクティビティ通知が共有されるような、分散型のDiscourseを本当に必要としています。そのため、これらのアイデアの現在の状況に関心があります…
はい。
私たちは、Discourse で作業するために複数の Discourse インスタンスを使用しており、ユーザーは次のような方法で一元化された通知を受け取ります。
Web プッシュ通知 (Android、Windows、Linux、MacOS で利用可能)
DiscourseHub (ホスティング中のサイトの iOS および Android で利用可能)
Eメール (どこでも利用可能)
RSS フィードを購読したり、.ics エンドポイント経由でブックマークをカレンダーに同期したりできることは言うまでもありません。
なぜそれのために ActivityPub が必要なのでしょうか？
OPによると、RSSフィードはインターネットの普遍的に集約されたフィードを持つための最良のソリューションである可能性が高いです。また、rss.appのようなサイトやopenrss.orgのような動きにより、今日ではフォローしたいほとんどのサイトのRSSフィードを取得できます。
ここで議論の途中であり、おそらくこれまでの議論のすべての側面をまだ理解できていない可能性があります。
中央集権的なセットアップから、複数のDiscourseインスタンス（オンプレミスでヨーロッパにホストする必要があり、AWSは選択肢ではありません）への分散型セットアップに切り替える場合、「サーバー間」のアクティビティメッセージングにより、ユーザーは1つのシステムにのみログインし、別のシステムからの興味深いアクティビティに関する情報を取得できます。
Eメールは「混雑しすぎ」ており、「標準的なニュースレター」を通じて流れる情報のカバレッジが低下しています。ActivityPub（サーバー間APIを使用）を使用すると、さまざまなソースからの情報を1つの「優先サーバー」に収集できます。
RSSフィードは確かに可能なソリューションですが、これにはさまざまなサーバーへの登録/認証が必要です。また、さまざまなテクノロジーでの手動作業であり、ほとんどの「非技術」ユーザーはそれに慣れていません。
Fediverse の人々に、手動のワンボックスよりもリッチな方法で Discourse サーバーに参加してもらいたいと考えています。
RSS フィードを使用しており（実際、複数の Discourse インスタンスの新しいコンテンツを追跡するために使用しています）が、ActivityPub / ActivityStream の送信専用プラグインがあれば、人々が熱狂的に参加している場所に到達し、Discourse フォーラムの情報へのアクセス性を高めるのに役立ちます。
Discourse チームが根本的にこれに反対していることは認識しており、それは彼らの自由です。Discourse の大きな強みの 1 つは、実際に公開で構築され、壁を越えて投げ捨てられるのではなく、真のオープンソースであるため、全員が同意する必要はないということです。
Discourse における ActivityPub に関する考えは、技術的にも戦略的にも、もう少し成熟させる必要があるかもしれません。
現在の「Twitter の大惨事」が、より多くの人々（特に政治レベルの人々）に、自身の「デジタル主権」の何が問題なのかを再考させることを願っています。そして、おそらく、これは公共およびコミュニティベースのデジタルディスカッションの分野における、真のオープンソースソリューションの新たなチャンスも含まれるでしょう…
これまでのところ、Discourse で ActivityPub を推進してきましたが、なぜ ActivityPub が必要なのかを説明しようとする多くの声を聞いてきました…しかし、@Discourse チームがなぜそれを実装したくないのかについては聞いていません。提示されたすべての議論について、もっともらしいアプローチで対応しようとしましたが、最終的には、リモート アカウントはローカルで ステージング済み と見なされ、現在のステージング済みユーザーと同様に制限される可能性があることを考えると、リモート識別子が信頼レベルにどのように影響するのかについての明確な説明はありませんでした。
複数の関連スレッドがあります。ここで「ディスコースチームは基本的にこれに反対している」という私の見方が間違っているか、時代遅れであることを @sam が明確にしたことを強調したかったのです。
CDCK がこの作業にリソースを投入していない理由は、有料顧客のほとんどがこれを気にしていない、あるいは少なくとも他の機能開発よりも優先度が低いからだと予想されます。現時点および予見可能な将来において、この作業に対するコミュニティの関心は、企業の関心よりもはるかに大きいと推測します。CDCK がこの作業を引き受けた場合、顧客が求めている他の機能を構築しない機会費用は相当なものになる可能性があります。（私は内部情報を持っていません。）
上記の Sam のコメントを踏まえると、Discourse コミュニティの開発者グループがプラグインを開発するのに十分な関心を持っている場合、CDCK はそのプラグインを効果的に機能させるために必要なコアの変更をレビューおよびマージする開発者と協力することに投資すると予想されます。私が Discourse に行った小さな貢献の経験から、彼らは自分たちでは優先しないであろう作業のレビューと支援に労力を優先してきました。
私は単にディスコースユーザー（マイナーなインスタンスをホストしている）であり、最近始めたばかりなので、技術的にどのようにアプローチするかについて具体的な提案はありません。しかし、WordPressがプラグインを通じてFediverseで大きな存在感を示していることに気づきました。2023年2月現在、750以上のウェブサイトがフェデレーションしており、これは多くの専用フェデレーションプラットフォームよりもすでに多い数字です。したがって、すべてのディスコースコミュニティ（希望するコミュニティ）を、より統合されたものの一部に「魔法のように」することができる可能性があります。主な注意点は、（おそらく）フェデレーションプロトコルは、より多くの採用とともに進化していくため、関連する機能もそれに合わせて進化させるためのコミットメントが必要になるということです。
@SeriousFun01 は、こちらでの最新情報については、Federation support for Discourse - #87 by angus およびそれに続く投稿をお読みください。 