Federation support for Discourse

特徴
84

Discourse からの連携サポートのアイデア：Brid.gy による Webmention を利用する。

https://www.yusuf.fyi/posts/receiving-blog-replies-from-anywhere

フロー概要：

  • 最初の投稿にリンクが含まれるトピックが作成される。まずは、最初の投稿に単一のリンクがあるか、またはタイトルに URL が貼り付けられているかを検出する。
  • オプション：些細なスパムを避けるため、最初の返信を待つか、サイトの設定を有効にする。
  • Webmention がサポートされているかを確認するためにページをプローブする。
  • Webmention コメントが「This page is being discussed on =SITE\ _DOMAIN=: "=TITLE=" =TOPIC\ _LINK= =CATEGORY_AND_TAGS="」（サイトの default_locale を使用）というテキストとともに送信される。
  • サイトは Webmention を受信し（fed.brid.gy に委任し、スパム対策を適用するなど）、最終的にコメントとして表示する。

アクター（コメントの「作成者」）は、高品質なサイトロゴまたは @system アバター、およびフォーラムの短い名前を使用する。

「いいね！」 6
85

投稿者です

ちなみに、投稿では触れませんでしたが、このプロトコルは返信と同様に、いいねや再投稿をファーストクラスの市民として送信することをサポートしています。Discourseでも同様の実装がされると良いですね。

86

Pavilionは、Discourseにフェデレーションサポートを追加するために、NLnetに40,000ユーロを申請しました（下記参照）。しかし、それは却下され、最終的にDAPSIに申請し（そして承認され）ました。

「いいね！」 12
87

アップデートのお知らせです。PavilionとCDCK (Discourse.org) は、Discourse用のActivityPubプラグインの構築について議論しています。いくつかの議論を経て、以下の仕様に落ち着きました。最終決定の前に、コメントや提案を歓迎します。なお、

  • 受信コンテンツ（Mastodonなどでの投稿をDiscourseにインポートするなど）のサポートは、意図的に除外されています。これは後バージョンで追加可能です。

  • ユーザーのフォロー（カテゴリではなく）のサポートも、意図的に除外されています。これも後バージョンで追加可能です。

  • 仕様の大部分は、Lemmyが採用したアプローチに従っています。

  • MVPプラグインはPavilionが構築します（私が担当します）。CDCKがそれを所有・ホストします（つまり、Pavilionプラグインではなく、CDCKプラグインになります）。

概要

Discourse用ActivityPub (AP) プラグイン。

このプラグインの目標は、ActivityPub、ActivityVocab、ActivityStreamsの仕様のMVP実装をDiscourseで行い、AP準拠プラットフォームであるMastodonとの統合を実証することです。可能な限り、実装はプロトコルのさらなるサポートや拡張をサポートするように構築されます。

この仕様は、AP対応カテゴリごとに、AP対応カテゴリ内のトピックの最初の投稿のみがフェデレーションされる（「最初の投稿のみ」）ようにAPサポートを有効にすることに関するものです。

ユーザー

プラグインの使用方法は、プラグイントピックのmetaで包括的に文書化されます。

通常ユーザー

  1. Mastodon（または他のFediverseサービス）で、カテゴリのハンドル（例: @announcements@meta.discourse.org）を使用して、フェデレーション対応Discourseカテゴリ（FDC）を購読（「フォロー」）します。

  2. FDCトピックの最初の投稿の抜粋（購読後に投稿されたもの）をMastodonフィードで表示し、各投稿には関連トピックへのリンク（例: 「フォーラムで議論する」）が含まれます。

  3. Mastodonでの投稿に関連するアクションはDiscourseには表示されません。

  4. Discourseでの投稿に関連するアクションはMastodonには表示されません。

  5. フェデレーションされた投稿の抜粋は、投稿者がトピックの抜粋を制御するために使用されるものと同様のマークアップを使用して制御できます。例: <div>{text}</div>

管理者

  1. カテゴリ設定を使用して、カテゴリごとにフェデレーションを有効にします。フェデレーションは、パブリックインスタンスで「全員」に表示されるカテゴリでのみ有効にできます。

  2. カテゴリのフェデレーションユーザー名を、カテゴリ設定UIで設定します（変更不可）。

  3. アクティビティが自動的に受け入れられるか拒否されるドメインの許可リストと拒否リストをサイト設定から設定します。

  4. サーバーのアウトボックスにあるBlock object(s)の一部となるフェデレーションユーザー名の「ブロックリスト」を設定します。

  5. サイト設定（例: activitypub_note_excerpt_maxlength）を使用して、フェデレーションされたノートの最大文字長を設定します。

  6. 「カスタマイズ > テキスト」で、フェデレーションされたDiscourseトピックの最初の投稿に含まれるリンクに関連付けられたテキストを設定します。

  7. フェデレーションされた投稿にフォーラムへのリンク（およびテキスト）が含まれるかどうかを、カテゴリごとに設定します。

  8. フェデレーションされたコンテンツに署名するためのキーペアをサイト設定に追加します。

技術

  1. プラグインには包括的なテスト（単体/統合およびJSテスト）が含まれます。

  2. カテゴリは、Discourse内の自動化されたActivityPub Actorです（Group ActorTypeとして）。フェデレーションされたpreferredUsernameは、管理者がフェデレーションを有効にする際に設定し、カテゴリカスタムフィールドに保存されます。フェデレーション名（表示名）は、カテゴリのfull_nameです。

  3. ユーザーは、カテゴリActorによってフェデレーションされるコンテンツ内のActorです。フェデレーションされたpreferredUsernameは、フェデレーション時のユーザーのDiscourseユーザー名です。ユーザーがDiscourseユーザー名を変更した場合に備えて、ユーザーのpreferredUsernameはユーザーカスタムフィールドに保存されます。フェデレーション名（表示名）は、ユーザーのDiscourse名です。

  4. 一般的に、ActivityPubオブジェクトは、適切なカスタムフィールド（例: オブジェクトまたはアクターID）を使用して同等のDiscourseオブジェクトに関連付けられ、適切な場合は新しいテーブル（例: 受信トレイと送信トレイ）が使用されます。

  5. 実装する主要なActivityPub ActivityはFollowと、それを実装するために必要な関連アクティビティおよびモデル（つまり、受信トレイ、送信トレイ、および必要な関連アクションとコレクション）です。

  6. Discourseの投稿は、ActivityStreamのNotesとしてフェデレーションされ、コンテンツはHTML形式になります。

  7. 認証はHTTP署名を使用して処理されます。詳細はこちらとこちらを参照してください。ActivityPub仕様の他のすべてのセキュリティに関する考慮事項は、適切に対処されます。

  8. フェデレーションエンドポイントは、仕様に応じて適切に保護されます。つまり、コントローラーでredirect_to_login_if_requiredが使用されていることを確認し、カテゴリの「全員が見れる」権限に対するGuardianを追加します。

「いいね！」 34
88

このような意欲的なプロジェクトに取り組んでいただき、ありがとうございます。大変興味深く見守らせていただきます :slight_smile:

「いいね！」 7
89

このニュースを見ることができてとても嬉しいです！ありがとうございます！また、象（マストドンへの間接的な言及ではありません）を食べようとするのではなく、シンプルな初期実装から始めることに満足しています。何かを追加することを提案するのはためらいますが、提案を求めているので、それほど手間がかからないと思われるものを一つ提案します。

inReplyTo を使用してスレッド化し、オプションで返信の抜粋も投稿することについてどう思いますか？これにより、Discourse で行われている対話が強調され、より魅力的なものになると思います。「フォーラムで話し合う」と合わせて、会話を見ることでより多くの人が参加してくれる可能性が高まると思います。

「いいね！」 4
90

フィードバックとサポートをありがとうございます！

この段階で返信をフェデレーションする問題は、それに対する適切なサポートが得られるまで満たされないエンゲージメントの期待を生み出す可能性があることです。ここでユーザーの期待を明確に保つことが重要です。一部のユーザーはフェデレーションされた返信の制限を理解するかもしれませんが、他のユーザーは理解しないかもしれません。もう1つの問題は、一度に対処する技術的な課題の数を減らそうとすることです。

とはいえ、すでに上記の「最初の投稿のみ」の仕様に対する「トピック全体」の拡張を検討しています。この方向性がどのようなものになるかを示すために、その技術的なメモの一部を以下に共有しました。強調しておきたいのは、「トピック全体」の拡張は最初の仕様の一部ではなく、現時点では可能性にすぎないということです。

トピック全体拡張

5.受信したメモは、新しいトピックまたは返信として公開されます（inReplyTo または Replies を使用）。

  1. Discourseのセキュリティおよびスパムフィルターは、Accept / Reject objects を使用して、受信したオブジェクトに可能な限り適用されます。

  2. メモの投稿は、カスタムフィールドを介してアクターIDに関連付けられたステージングユーザーに帰属します。これには、ユーザーが実際のメールを持たないため、ステージングユーザーの概念の非メールベースのバリエーションが必要になります（プレースホルダーは、フェデレーションされたアクターのIDと preferredUsername を使用して生成できます）。

  3. ステージングされたActivityPubユーザーを標準のDiscourseユーザーに関連付けることは可能ですが、現在のところこの仕様のどの部分にも含まれていません。これは「フェデレーテッドID」の問題とその解決策です。

  4. フェデレーションされた投稿は、コアActivityPub/Stream仕様以外のフェデレーションされた@メンションなどをサポートしません。そのような機能のサポートは、後で追加される可能性があります。たとえば、Webfinger や Mastodonのフォロー を使用します。

最初のバージョンの鍵は、最小限の実行可能な実装に焦点を当てることです。その基盤が築かれれば、これらの「トピック全体」のメモに沿った、より完全なフェデレーションサポートがより実現可能になります。ただし、プラグインの方向性はCDCKが決定することになる点を強調しておきます。ここで言及することはすべて、基盤となる仕様を構築できる可能性のある方法にすぎません。

「いいね！」 6
91

Fediverse の投稿や進行中のディスカッションの一部です。

追伸。昨年11月に、Flarum のコア開発者である Daniël Klabbers から、ActivityPub 拡張機能を開発していると連絡を受けたことも言及しておきたいと思います。現在の状況はわかりませんが、フォーラム分野のすべてのプロジェクトが協力して、この分野で可能な限り多くの相互運用性を実現できれば良いかもしれません。

その相互運用性に関して、Codeberg の Fediverse Enhancement Proposal プロセス、ActivityPub に関する FEP についても指摘しておきたいと思います。

例えば、Lemmy は最近 ActivityPub グループの FEP を最終決定しました。ディスカッションは SocialHub で行われています。

(FEP プロセスは Fediverse の成長とともに勢いを増しており、現在プロトコルメカニズムを標準化するのに最適な場所です)

「いいね！」 4
92

@aschrijverさん、ありがとうございます。大変参考になりました。私は上記で仕様化されたMVPの実装に個人的に注力し、CDCKと緊密に連携していきます。@mcdanlj氏の簡潔な言葉を借りれば、その取り組みが「象を丸ごと飲み込もう」としないことが極めて重要です。仕様、特に技術的な側面に関する建設的なフィードバックをいただければ幸いです。

ただし、Pavilionの他のメンバーである@nmeyne氏（SSIコミュニティ、特に検証可能なクレデンシャルのベテラン）と@merefield氏もこの分野で活動しており、あなたが提起したより広範な問題に関心を持っていることも付け加えておきます。

「いいね！」 6
93

素晴らしい、ありがとうございます。上記のアナウンスを指し示すDMでDaniël Klabbersに事前に連絡しておきました。

「いいね！」 3
94

それは私にとって完全に理にかなっています！

忠実さの幻想による実際の誤解の例として、Google+がなくなったときにGoogle+コミュニティの多くをインポートしたMaker Forumsで発生した問題の1つは、インポートが十分に忠実であったため、サイトの新規ユーザーは、まだサイトにGoogle+から到着していない他のユーザーと対話しようとしていることに気づかず、そのため、対話しようとしている人が応答するためにそこにいないことを知らせるための定型応答があります。

「トピック全体の拡張」のアイデアに関する詳細を提供していただきありがとうございます。

「いいね！」 5
95

将来的にこれが追加される場合…参考までに、WordPressのPterotypeが提供していたアプローチが非常に気に入っています。それは、フェデレーションされたコメントはすべて、元のフォーラムトピックへの返信として投稿される前に、モデレーション/グループ承認に直接中継されるというものです。

フォーラムの場合、これはスタッフではなく、TL4 / TL3タイプに適したタスクかもしれません。

個人的には、これにより、トピックから外れたソーシャルメディアスタイルの返信が元のディスカッショントピックを圧倒するのを防ぐのに特に役立つことがわかりました。

「いいね！」 4
96

はい、レビューキューの使用は、受信コンテンツについて議論してきたことです。ご指摘の通り、これは、そこ（最初のバージョンではない）に到達した場合に検討すべきことです。

この作業に関する管理上の問題は解決したので、来週から仕様の作業を開始します。仕様に関するさらなる技術的なフィードバックや注記があれば、歓迎します。

実現には数ヶ月かかるので、しばらくお待ちください。

「いいね！」 5
97

Discourseで投稿が削除された場合、フォロワーに「Delete」アクションを送信することはできますか？

Maker Forumsでは、「Googleポイント」が十分にあり、SEOスパマーが多数います。新規ユーザーの権限は比較的緩やかに設定しています。これは、新規ユーザーの一般的な利用形態が、サイト関連のヘルプを求める困惑したユーザーであるため、より迅速に支援するのに役立つからです。しかし、これはスパマーがスパム投稿を迅速に行い、比較的すぐにスパムとしてフラグが立てられ、リストから削除され、その後削除される傾向があることを意味します。

これらのフェデレーションされた投稿が削除され、その削除が「Delete」経由で公開され、フェデレーションキャッシュからスパムがクリーンアップされることを願っています。それはおそらく範囲内ですか？

「いいね！」 4
98

フェデレーションに数時間の遅延があれば、フェデレーション前にスパムに対処できるため、この場合に役立つ可能性があります。(比較的最近のユーザーの最初の投稿にのみ遅延を適用することもできるかもしれませんか？)

「いいね！」 3
99

どちらも役立つ提案をありがとうございます。

おっしゃるような理由から、MVPでこれを行うことを想定しています。適切な時期にDiscourseの担当者とさらに話し合います。

有用な提案です。フェデレーションは間違いなく非同期になります。遅延の設定と処理方法は、MVPで何らかの形で対処する必要があるでしょう。

MVPに対するこのような具体的な提案、特に過去のユースケースや技術ドメインの専門知識に基づいたものは、非常に歓迎されます。

「いいね！」 3
100

もし、初期段階でそれほど多くの作業が発生しないのであれば、投稿の編集もUpdateアクティビティとしてフェデレーションアウトすることも価値があるでしょう。MVP後の貢献で済むようなことであれば、後でそれに対応できるような合理的な設計にしておくと良いでしょう。

参考までに、私は自分のインスタンスで遅延を低く設定するでしょう。スパム投稿のフェデレーションを回避するためにそれを使用するつもりはありません。なぜなら、それはモデレーターがFediverseフィードからDiscourseにアクセスして対応するきっかけとなる可能性が十分に高いからです。私はchat_integration_delay_secondsを20に設定しており、これは簡単なタイポ編集のためですが、ここでも同様のことを期待しています。少なくとも、その設定はこのような遅延の前例となります。:smiling_face:

「いいね！」 2
101

簡単なアップデートです！開発から1ヶ月が経過し、大まかに言うと、以下のものが現在動作しています。

  • ActivityPubが有効なカテゴリをフォローできるようになりました。
  • ActivityPubが有効なカテゴリのトピックの最初の投稿が、フォロワーにフェデレーションされます。

他にも小さな部分がいくつかありますが、この段階で言及する価値はありません。内部テストを開始する前に、少なくともあと1ヶ月の開発期間が必要です。

要するに、開発は順調に進んでいます :slight_smile:

「いいね！」 14
102

それはすごいですね、共有ありがとうございます。

中央集権的なサービスの承認を得て、あるいは得ずに、私たちが構築できるあらゆる側面に自由が必要です。

それは止められず、あらゆるCEO、CTO、あるいはどんな奇妙な名前の意思決定者にとっても、処方箋なしで手に入るものです :slight_smile:

そして、関わったすべての開発者と彼らが成し遂げた進歩に、心から感謝します。公開されたらテストして、私の考えを共有します。

「いいね！」 1
103

すごい、その場合タグにも適用できるのでしょうか？現在、ユーザーはRSS経由でタグを購読しています。

とにかく、おめでとうございます！非常にエキサイティングです。