はい、しかしそれは大規模で高価なプラグインになるでしょう。
「いいね！」 1
SSO または LDAP を使用すると、全員を 1 つのドメイン ログインに移行することなく、相互にログインできますか？
たとえば、フォーラム A、B、C があります。フォーラム A のメンバーが、フォーラム B および C にフォーラム A の資格情報でログインして投稿できるようにしたいと考えています。 B および C の登録済みメンバーにも同じことが起こるようにしたいと考えています。
この投稿とそれに続く投稿は、ここで議論されている機能のサブセットに関係しているため、独自のトピックに移動させるべきだと思います。
「いいね！」 1
Setup DiscourseConnect - Official Single-Sign-On for Discourse (sso) - Integrations - Discourse Meta がお役に立つかもしれません 
「いいね！」 1
理論上、ActivityPubフェデレーションプロトコルサーバーとして機能するDiscourseプラグインを作成する以外に、_クライアント_ソーシャルAPIプロトコルを尊重する別のActivityPubサーバーにアカウントを設定し、DiscourseプラグインがActivityPubサーバーではなく、そのサーバーとクライアントプロトコルで通信するという別の可能性も考えられます。これは、既存のActivityPubノードへの統合をより密接にすることに利点があるかもしれません。しかし、サーバープロトコルを実装するよりも簡単だとは思いませんし、フォーラムオペレーターにとっては、フェデレーションプロトコルサーバーになるよりも多くの手動設定作業が必要になります。
実装のアイデアとしては、ユーザーインタラクションの可能性を許容するために、DiscourseユーザーアクターとDiscourseシステムアクター（例：カテゴリ）を区別する方法が必要になります。@#slug@discourse.example.org はカテゴリのアクターであり、後で @username@discourse.example.org のようなユーザーアクターを追加する余地を残すことができます。しかし、ハッシュタグの普及を考えると、実際には機能しない可能性があります。
4〜5のポイントは、Discourseを汎用のActivityPubサーバーにしようとすることに近づきすぎているという理論に基づいて、1〜3のポイントに焦点を当てる方が簡単でしょう。それは間違いなく目的ではありません。
「いいね！」 2
Mastodon は検証に以下の正規表現を使用します。
USERNAME_RE = /[a-z0-9_]+([a-z0-9_\\.-]+[a-z0-9_]+)?/i
MENTION_RE = /(?<
私の理解では、その USERNAME_RE は リモート ユーザーに適用されるため、Discourse ユーザーとカテゴリをそのような別個の名前空間に配置する方法が不明瞭です。また、通常のサブカテゴリのスラッグも除外されます。@parentcategory:subcategory@discourse.example.org もその RE では機能しません。
オプションのサブドメイン @username@users.discourse.example.org が考えられますが、SSL と DNS の設定がさらに必要になり、おそらく多くの誤設定が発生するでしょう。そこまで行く価値はないかもしれません。
「いいね！」 1
他のプラットフォームとの連合を作成するのではなく、ディスコースのすべてのインスタンス間に連合を作成する方が理にかなっているかもしれません。ディスコースのインスタンスの数は非常に多いためです。
「いいね！」 2
確かに、ここに大きな可能性があります。可能性と実現可能性は、徹底的かつ冷静な検討に値します。
これはザナドゥの領域かもしれません…（上記のJeffの投稿を読み、その中のリンクをたどってください。）このような広範な統合は、おそらくほとんどのDiscourseインスタンスの管理者/オペレーターにとって望ましくないでしょう。管理者とオペレーターの正式な調査が必要です（ディスカッションフォーラムでの「トラフィックレベルによる調査」とは対照的に）。
これは、連邦化されたサイトのいずれかのユーザー認証情報の「王国の鍵」をハッキングできる人にとって、セキュリティハックへの招待のように見えます。少なくとも、これらの機能はデフォルトでオフにするか、プラグインとして明示的にロードする必要があります。ほとんどのセキュリティ機能が有効になり、ロックダウンされます。Zoomは、プラットフォームをオープンで使いやすく（急速にユーザーを獲得し、育成するために）したことでこの教訓を教えてくれましたが、ならず者が正面玄関が開いているのを見つけた後、すぐにロックダウンする必要がありました。
それにもかかわらず、サイトのマイクロ連邦化はDiscourseの実装にとって大きな後押しとなるでしょう。私の自治体のために、同じユーザープール（例えば、郡/市の市民）を統合するサイトのサークルを作成できれば、人々はコミュニケーションを取り、地方自治やコミュニティ生活において肯定的な結果をもたらす可能性があります。この同じ原則は、各部門が他の部門への簡単なナビゲーションを備えた独自のDiscourseコンテナを持つことができるように、複数のDiscourseインスタンスを管理するのに十分な規模のビジネスにも当てはまります。*それが meta.discourse の具現化となるでしょう。
Jeff、Sam、およびCo.（[@codinghorror @sam]）および/またはその運営委員会は、まずDiscourseがソーシャルプラットフォームなのか、それともエンタープライズプラットフォームなのかを決定する必要があります。私はエンタープライズに賛成です。なぜなら、この両方の側面で最大の可能性が見えるからです。エンタープライズは、企業の従業員をサポートする能力を向上させることで、最大の経済的報酬と即時の社会的利益を生み出すでしょう（ビジネスを大切にすれば、ビジネスもあなたを大切にしてくれます）。それらの商業資金の一部は、social.discourse.org財団をサポートするために使用できるかもしれません。エンタープライズに役立つ機能は、ソーシャルドメインにもうまく引き継がれる可能性が非常に高いです。これら2つの要因は、全体的なウィンウィンの状況を作り出します。
両ドメインは非常に異なるため、区別する必要があります。そして、あったら嬉しい機能は、必然的にプライマリユースケースである方に有利になる必要があります。
幸いなことに、利益は両方に流れます。social.discourse.orgに関心のある人は誰でも、コミュニティ構築のソーシャル側面から報酬を得て、コミュニティ関連の活動を追求できるようになるため、これらの非金銭的報酬のために（しばしば一生懸命）働くでしょう。このsocial.discourse.orgでの作業は、必然的にエンタープライズコンテキストで役立つ開発と機能につながり、それによってEnterprise Discourse Incorporatedに価値を還元し、Social Discourse Foundationの非営利サポートを交換します。さらにウィンウィンです。
上記の文に感嘆符が一つもないことに注意してください。これらは単なる事実と、起こりうる結果の声明です。非常に実用的です。
私は数年間、私のビジネスに適したグループウェアプラットフォームを探してきました。Slackは一時的に大きな希望を与えてくれました。なぜなら、それは社内ビジネス用途で開発されたからです（そして非常に興味深い起源の物語があります）が、最初のスクリーニングを通過しませんでした。私はDiscourseに非常に感銘を受け、楽観的です。
「いいね！」 1
それがこのトピックの全体的なポイントです。つまり、Discourseインスタンス間です。
OPに記載されています：
「いいね！」 2
はい、そして
そして
マイクロ連邦的なサイト群は後押しになるでしょう
すべてトピックに沿っていますよね？ 
必ずしも前提条件ではありません。プラグインエコシステムを考慮する必要があります。
かなり大規模な機能は、プラグインやテーマコンポーネント（可能な場合）として開発されることが多く、そのような管理オーバーヘッドや中央集権的な計画を伴いません。
それがDiscourseエコシステムの美しさの一部です。
たとえば、Pavilionは、CDCKとの協議なしに、Locations、Topic List Previews、Multilingual、Follow、Layouts、Custom Wizard（いくつか例を挙げると）などをすべて作成しました。したがって、この議論への関与の一部はそれによるものです。
「いいね！」 7
プラグイン開発者の皆様、神のご加護がありますように！彼らは、実地テストを経てコア製品への組み込みが検討できる概念実証の例を惜しみなく提供してくれます。皆様の多言語プラグインは、その素晴らしい例です！
python.org では、ライブラリ開発者がこの役割を担っており、時には「ぜひ欲しい」と思わせるような関数を作成し、それが Python コアパッケージや標準配布ライブラリへの組み込みとして受け入れられることがあります。
「いいね！」 2
このフォーラムのいくつかのトピックで、Discourseにフェデレーションサポートを追加するよう提唱してきました。例えば、こちらです。Fediverseが主流になり、TumblrやFlickrなどもフェデレーションサポートを追加している今、Discourseも同様のサポートを追加する意欲があるかどうかが問題です。
Flarumのコア開発者からAP実装に関するアドバイスを求められ、上記で言及したリンクなどいくつか送りました。
追伸：Fediverseの開発者コミュニティであるSocialHubのDiscourseフォーラムでは、個別のフォーラムではほとんどの人が参加するのが難しすぎるという障壁が示されているため、どのようにFediverseの一部になれるかを長い間探しています。
「いいね！」 7
最近、Mastodonに少し興味を持ちました（ドメイン名を購入するほどですが、実際にMastodonをインストールするほどではありません）。そのため、DiscourseとMastodonの認証について少し読みました。
認証は思ったよりも難しいという意見がいくつかありました。記憶が正しければ、プラグインを開発するための助成金が提供されたようですが、それは実現しなかったようです。私の推測では、これは10,000ドルの問題です。もし私が正しければ、それはあなたが必要とする種類の提唱です。
編集：しかし、私は認証とフェデレーションを混同していました。
「いいね！」 1
ここでの私の一般的な懸念は、アイデアが全体的に巨大すぎて、小さな部分に分解するのが非常に難しいということです。
フェデレーションのアイデアは興味深いと思います。具体的な実装の可能性としては、次のようになります。
- Discourse管理者がカテゴリをフェデレーションできるようにする。
- Mastodonのユーザーはそれをフォローできるようになる。例：
announcements@meta.discourse.orgをフォローする。 - 新しいアナウンスメントトピックが作成されると、抜粋と元のリンクが付いた新しい投稿がフェデレーションされる。
- Discourseでユーザーが返信すると、新しい返信がフェデレーションされ、帰属表示される（元のトピックへの返信として）。
- Fediverseの誰かが返信すると、Mastodonの投稿者に帰属表示された「シャドウ」投稿がトピックに作成される。
少なくとも、このようなものは私の頭で適切に収まるほど小さいです。
「いいね！」 13
ActivityPub の問題点は、読みやすいオープンスタンダードであるにもかかわらず、それを実装しただけではまだ「Fediverse の一部」にはなれないということです。他にも多くの実装が必要であり、特にディスカッションフォーラムのドメインでは、メッセージ交換のためのカスタム ActivityPub ボキャブラリーが必要です。参考にできる他のプロジェクトや採用できるライブラリもいくつかありますが、実際にかなりの開発が必要になるでしょう。
アドボカシーの観点からは、個人的には、うまく実装されれば AP サポートは製品に独自のセールスポイント（USP）を追加できると感じています。すべてのフォーラムにサインアップする必要がないというのは、私にとっても障壁です。この投稿のためだけに、さらに別の Discourse にサインアップする必要があるでしょうか？
しかし、フェデレーションはさらに多くの価値をもたらす可能性があります。私の夢のシナリオでは、Mastodon のように、最初は何もない状態の個人用 Discourse をインストールするか、インスタンスにサインアップします。そして、自分のニーズや興味に基づいて、自分でコミュニティ構造を構築します。このテーマのグループを選択し、このカテゴリの下に追加し、別のグループを追加します。
「いいね！」 5
はい、それが良い出発点になるでしょう。Lemmyのリンクアグリゲーターは、コミュニティの連合を提供するといった点で、ある程度それに似ています。 federation は、最初は Discourse インスタンス/テナント間だけで実装できることに注意してください（より広範囲にやり取りできるのは非常に望ましいことですが）。
すべてが Mastodon に適合するわけではありません。それはマイクロブログアプリであり、Markdown をサポートしていません（ただし、他の fedi アプリはサポートしています）。
現在、さらに federated Groups のサポートが開発中です。Lemmy がその例です。Bonfire は Google+ のようなサークルなどを追加します。
「いいね！」 3
はい！これが私が望むワークフローであり、宣伝したいものです。
抜粋の長さは、0の場合は抜粋ではなく記事全体を意味するように、便利に設定可能になります。Mastodonの500文字制限は任意であり、Fediverse、ActivityPub、またはActivityStreamとは関係がないことに注意してください。私が現在実行しているMastodonノードには2000文字の制限があり、social.kernel.orgの制限は31337文字です。500文字の投稿作成制限があるデフォルトのMastodonでさえ、長い投稿は問題なく表示されます。
私が認識する小さな困難は、Discourseではユーザーとカテゴリの名前空間が別々ですが、ActivityPubでは同じ「アクター」であり、少なくともMastodonはアクターを認識するためのかなり制限的な正規表現を持っていることです。カテゴリ#announcementsの@announcements@meta.discourse.orgの場合、このコメントは@mcdanlj@meta.discourse.orgによって作成されたものとしてフェデレーションされます。
デフォルトでは、Discourse管理者として、カテゴリのスラッグをアクター名として使用したいと考えています。管理者がカテゴリのフェデレーションを設定するときに、アクター名（デフォルトはスラッグ）を選択すると、Discourseユーザー名に関して一意（グループ名のように）になると推測します。
（ちなみに、以前はMastodonのアクター名を認識するための正規表現を心配していましたが、それは実際にはここでは価値のない@メンションにのみ使用されると思います。したがって、たとえば、#documentation:adminsを@documentation:admins@meta.discourse.orgとして表現することも可能かもしれませんが、これは間違いなく、いくつかの主要なマイクロブログシステム、特にMastodonとPleromaでテストしたいです。）
「いいね！」 3
Mastodon や Pleroma ユーザーの視点から見ると、実際には @announcements@meta.discourse.org が @sam@meta.discourse.org によるトピック投稿をブースト / リブログし、さらに @mcdanlj@meta.discourse.org によるコメント投稿を OP へのコメントとしてブースト/リブログすることになるでしょう。OP もコメントも実際にはカテゴリによって作成されるのではなく、カテゴリ内の個人によって作成されます。
プラグインは当初、カテゴリのアクターに対してのみ webfinger を実装する（フォローできるようにするため）かもしれませんが、最終的には個々のユーザーに対しても実装することが理にかなっているかもしれません。Mastodon で @sam@meta.discourse.org をフォローして、彼の投稿やコメントを見たいと思うのはもっともなことです。
「いいね！」 2
質問：この議論の現在の状況と、可能な実装の計画はどうなっていますか？例えば、テストサポートは必要ですか？それとも、その質問は「時期尚早」すぎますか？ 