はい、Discourse はコメント埋め込みウィジェットで同様のことを行うことができます。とりわけ、アクティブユーザーが数人しかいないフォーラムを開始する際に一部の人が経験する気まずさを軽減するのに役立つかもしれません。https://meta.discourse.org/t/ai-sockpuppet-accounts-to-jumpstart-my-community/292396。新しい Discourse サイトは、ブログ投稿を使用してフォーラムを宣伝およびシードすることができます。これは現在ある程度可能ですが、ユーザーが埋め込みウィジェットから直接コメントできるようになると、プロセスがよりシームレスになります。
「いいね！」 3
Wordpress側でDiscourseに接続されたシンプルなコメントフォームがあれば、訪問者はコメントを投稿する前にDiscourseに移動してアカウントを作成する必要がなくなり、摩擦が軽減され、エンゲージメントが高まるでしょう。少なくとも私のようなパブリッシャーにとってはそうです。
私のユースケースでは、コメント投稿者が名前とメールアドレスだけでコメントを残せるのが理想的です。これにより、Discourseにステージングユーザーを作成し、会話を続けるために完全に参加するように招待できます。コメントを残すことを妨げることなく。
公開された記事にコメントを残すためにアカウントを作成するという追加の摩擦が、エンゲージメントを構築し、最終的にフォーラムのコミュニティを成長させることを困難にしていることがわかりました。たとえば、コメントセクション（現在のDiscourse-Wordpress統合を使用）について尋ねられたとき、ある著者は次のようにフィードバックしました。
会話エリアについて：今あなたが言及したことで…それを思い出しました。そして当時、Discourseに移動してアカウントを作成する必要があるため、時間がかかりそうだと感じ、とりあえず忘れるだろうと思いました。これは、ほとんどの人がそのプロセスを経験することについてどう感じるかについての強力な証拠です。私は通常、自分の文章へのコメントを見ることに執着しています。私は自分自身に笑いかけ、「今すぐこれに対処するには、それほど執着していないようだ」と言ったのを覚えています。理想的には、サインアッププロセスなしで誰にでもコメントを公開するでしょう。しかし、どのような単純化/容易さでもエンゲージメントは向上します。そのようなコメントは通常、衝動的な行動です。人々が少しでも妨げられると、先に進み、時間をかけない傾向があります。
「いいね！」 3
先日、まさにこのことを考えていました。奇妙なことに、WordPressのコメントがブログ記事にあった頃が懐かしいです。なぜなら、人々がすぐに始められる、参入障壁が非常に低い、とても速いように思えたからです。
非常にシンプルなサインアッププロセスがあるにもかかわらず、現在、誰かが投稿にコメントしたい場合、新しいページにアクセスする必要があります。その敷居を越えるのは、あまりにも負担に感じるかもしれません。まるで、Aにコメントしたいのですが、AにコメントするためにBにアクセスし、それからAに戻ってコメントを見る必要があるようなものです。Aのすぐ下でAにコメントする方が自然に感じるでしょう。
ステージングユーザーのアイデアは気に入っています。WordPressのコメントフォームがDiscourseフォーラムにメールを送信し、その方法でユーザーをステージングすることで、これをハッキングできるかもしれないと考えられますが、この方法で完全に統合するには、より複雑になるだろうと想像しています。
「いいね！」 3
これは以前は可能だったと思いますが、Discourseは現在、メールの「Fromヘッダー」とReturn Pathを比較していると確信しています。それらが一致しない場合、メールは拒否されます。（DiscourseがReturn Pathをチェックしていない場合、コメントシステムは簡単に悪用される可能性があります。任意のメールアドレスをフォームに入力できます。）
Discourseをコメントシステムとして使用する場合の問題には、いくつかの方法でアプローチできます。最善のアプローチは、Discourseがコメント埋め込みiframeを改善し、ユーザーが認証されたDiscourseユーザーとして対話できるようにすることだと思います。それが不可能であれば、埋め込みDiscourseコメントWebアプリを開発できます。それは興味深いプロジェクトになるでしょうが、それほど進める前にDiscourseが同様の機能を提供しないことを確認したいです。
WordPress固有のソリューションもいくつか考えられます。最も簡単なのは、WordPressコメントとWP Discourseプラグインの両方を有効にすることです。リスクは、Discourseフォーラムでのアクティビティが減少することです。ただし、WordPress UIでそれを支援する方法があると思います。たとえば、Discourseで発生している関連する会話へのリンクなどです。
Discourse SSOプロバイダーとして機能するWordPressサイトに特化したものを開発することも可能です。このトピックの以前の投稿でそれについて書きました。うまくやるには、WP Discourseプラグインに大幅な変更が必要になるかもしれません。ただし、（独り言ですが）：
上記のスクリーンショットで示そうとしているのは、WordPressサイトがDiscourse SSOプロバイダーである場合、コメントはDiscourseコメントiframeで表示できるということです。コメントは、Discourse APIに投稿するフォームを通じて作成できます。これにより、新しいコメントが追加されたときにiframeが更新されるようにDiscourseコメントiframeに変更が必要になるかもしれませんが、ユーザーが認証されたDiscourseユーザーとして対話できる必要はありません。
「いいね！」 4
つまり、私の理解が正しければ、コメント投稿者はWordPress側で登録し、次に埋め込まれたDiscourse iframe経由でコメントを残し、それがDiscourseのトピックに投稿され、WordPress側の表示が更新されてすぐに表示されるようになる、というアイデアになるのでしょうか。
WordPressの登録プロセスでメールアドレスが検証されるのですよね。しかし、これはDiscourseのSSOプロバイダーとしてWordPressに切り替えることも必要になります。これは可能ですが、フォーラムへのサインアップだけをしたい人々にとっては、逆に手間が増えることになるため、残念な側面もあります。
ここでおっしゃったことには私も同意します。
iframe内で直接登録できたり、少なくともステージングできたりすれば、コメントを続行できる（メール検証後にのみ投稿されるかもしれない）のであれば、それは使いやすさとセキュリティのバランスが取れた解決策になると思います。
「いいね！」 2
はい、その通りです。WordPressがSSOプロバイダーである場合、ユーザーがDiscourseトピックにコメントできるようにすることは、それほど難しい問題ではありません。WP Discourseプラグインの現在の状態での作業という点で難しいのは、WordPressにコメントを表示する方法を理解することです。現在、WP DiscourseのコメントセクションはDiscourseトピックの返信をミラーリングしていません。代わりに、「ベスト」なコメントの選択が表示されます。
このユースケースを処理するためにWP Discourseプラグインを更新することは可能ですが、適切に行うには、Discourseコメントの処理方法を完全に書き直す必要があります。私の決定ではありませんが、Discourseコメントのiframeを改善することに労力を費やす方が時間の有効活用になると思います。
「いいね！」 5
この機能が欲しいという声を上げたいだけです。
WPのユーザーが、フォーラムに移動することなく、WPの投稿に直接登録/サインインしてコメントできるようになると、コメントシステムのように感じられるので、非常に良いでしょう。コメントは投稿の下と作成されたディスコーススレッドの両方に表示されます。そして、ディスコース、WordPress、またはその両方にシームレスに投稿するオプションを常に持っています。これがどのように達成されるかはわかりませんが、WPのコメントとDiscourseを統合する非常にシームレスな方法であり、より洗練された感じになり、既存のプラグインで現在得られているコメント数を大幅に改善することは間違いありません。
「いいね！」 3
おそらくこれです：
しかし、私の知る限り、これはDiscourseのログインを完全にハイジャックします。
これにより、ユーザーはWordPressの投稿の直下にコメントを投稿し、対応するDiscourseスレッドにその投稿を自動的に入力できますか？
現在、これに取り組んでいます。最初のバージョンは、フロントエンドにRemixフレームワークを使用するヘッドレスWordPressサイト向けです。それが完了したら、通常のWordPressサイト向けのバージョンを作成します。おそらく、WP Discourseプラグインを拡張するプラグインになるでしょう。ヘッドレスWordPressサイトで行っていることの多くは、通常のWordPressサイトに転用できると期待していますが、いくつかの妥協が必要になるかもしれません。
外部サイトから直接コメントできるようにすることは、実装が簡単です。主な要件は、外部サイトがユーザーのDiscourse認証情報にアクセスできることです。これは、外部サイトをDiscourseのDiscourseConnectプロバイダーとして使用するか、Discourseを外部サイトのDiscourseConnectプロバイダーとして構成することによって実現できます。
2番目のシナリオ（外部サイトがDiscourseのDiscourseConnectプロバイダーではない場合）では、ユーザーが外部サイトからコメントしたい場合、外部サイトのアカウントをDiscourseアカウントに接続するためのリンクをクリックする必要があります（または、まだ登録していない場合はDiscourseに登録する必要があります）。ユーザーの視点からは、かなりシームレスに行うことができます。
ただし、上記の変更だけでは、全体が通常のコメントシステムのように感じるようにはなりません。コメントシステムに対する通常の期待は、すべてのコメントを読み取り、操作できることです。WP Discourseプラグインは、Discourseが提供する特別なルートから取得されたコメントの選択のみを表示します。コメントを操作するための機能は提供していません。
問題の難しい点は次のとおりです。
- WordPressでトピックのすべてのコメントをページネーションすること。数千になる可能性があることを考慮に入れる必要があります。
- 長いコメントリストの中でユーザーがどこにいるかについてのフィードバックを提供するUIを提供すること。
- 他のコメントに直接返信されたコメントを表示する方法を見つけること。（Discourseのこのための規約は、ほとんどのコメントシステムが返信を処理する方法とは一致しません。）
- ユーザーがコメントに直接返信したり、コメントに「いいね！」を付けたり、自分のコメントを編集したりできるようにすること。
- Discourse上で作成されたコメントを処理すること。これは、外部サイトで簡単にレンダリングまたは操作できないコンテンツやマークアップを含んでいる可能性があります。たとえば、onebox、投票など。
- コメントを最近、古い順、ベスト順などでフィルタリングする方法を提供すること。
これらすべては、外部サイトのサーバーに過度の負荷をかけたり、Discourseに過剰なAPIリクエストを送信したり、ユーザーのデバイスのメモリを過剰に消費したりすることなく（軽量なコメントシステムにすることが目標です）、達成する必要があります。これは達成可能ですが、既存のWP Discourseコードに大幅な変更を加えることなく、そのまま組み込むことができるものではありません。
「いいね！」 4
素晴らしい、着手してくれて嬉しいです！
ちょっとした考えですが、そもそもコメントしやすくするというアイデアの一部なので、最初のコメントのスムーズさに焦点を当てるのは良い考えかもしれません。上記で述べたように、多くの人は単にメールアドレスでコメントしたいと考えているようです。問題は、その後の検証とログイン、またはアカウント作成（DiscourseConnectの設定方法にもよると思いますが）です。
ユーザーが参加すれば、Discourseベースのディスカッション機能すべてを利用するために、対応するフォーラムトピックを訪問する可能性が高まると予想されます。「最初のコメント」の問題を解決するのを、これらの難しい部分が妨げないことを願っています。ページネーションを解決しなければならない何千ものコメントがあるというのは、その時は「良い問題」になるでしょう。
「いいね！」 4
ええ、それは本当の懸念事項です。最初のステップは、デモサイトをオンラインにすることです。実際にテストできるライブサイトがあれば、問題点がどこにあるかが明らかになるはずです。
匿名ユーザーが投稿にコメントできるようにすることは技術的に可能かもしれません。私が考えられる唯一のハックではない方法は、実際のユーザーが匿名ユーザーの代わりにコメントを投稿することです。しかし、それは少し奇妙に感じます。
WordPressには、「ゲスト」ユーザーがコメントを作成できるようにする設定があることを知っています。ただし、「ゲスト」コメントは、コメントを作成した後にサイトに登録したユーザーとは関連付けられないという制限があります。ユーザーの代わりに投稿することは、同様の方法で機能する必要があります。コメントを作成したユーザーが、コメントとともに提供されたメールアドレスの所有者であることを知る方法はありません。
理想的には、ユーザーはコメントを作成する前に、外部サイトまたはDiscourseで認証される必要があります。
ユーザーの観点からは、外部サイトがDiscourseのSSOプロバイダーである場合が、最も摩擦が少ないでしょう。これにより、ユーザーはDiscourseサイトにアクセスすることなく、Discourseのトピックにコメントできるようになります。
サイトオーナーの観点からは、ユーザーを認証する技術的に最も簡単な方法は、Discourseを外部サイトの認証プロバイダーとして機能させることです。これは、私が現在ローカルテストサイトで使用している構成です。外部（Remix）サイトにはユーザーテーブルさえありません。Discourseの/session/sso_providerルートからの応答に基づいてユーザーセッションを作成するだけです。
Discourseを外部サイトの認証プロバイダーとして使用する欠点は、ユーザーがDiscourseの登録/ログインプロセスを経由することを強制することです。そのプロセス自体に問題はありませんが、コメントを残したいだけなのに、すべてのDiscourseアセットをダウンロードするようにユーザーを強制するように見えます。そのため、やや遅くなります。さらに調査します…
そうですね 現実的なシナリオのために、それを数百に減らすかもしれません。私が言いたいのは、投稿が1ページ（20投稿）を超えると問題が複雑になるということです。
編集：Discourseの招待を利用してプロセスを合理化できるかもしれません。匿名ユーザーが投稿にコメントしたい場合、コメントフォームとともにメールフィールドが表示されます。コメントを送信すると、Discourseはそのメールアドレスに招待状を送信します。招待が承認されるまで、コメントはキューに保持されます。これにより、ユーザーはインスピレーションを感じたときにコメントを作成でき、コメントのステータスに関する即時のフィードバックを得ることができます。
「いいね！」 4
@simon のソリューションを見るのが楽しみです。
この件に関して別の方向で開発が進んでいるソリューションとして、ActivityPub を使用できることを指摘しておきたいと思います。最新リリースでは、公式の WordPress ActivityPub プラグインが Discourse ActivityPub プラグインのサポートを追加しました。
これは、WordPress ActivityPub プラグインと Discourse ActivityPub プラグインがインストールされていれば、投稿を行う WordPress アクター（または WordPress サイト全体）を「フォロー」するようにカテゴリを設定するだけで、WordPress の投稿が Discourse のカテゴリに新しいトピックとして表示されることを意味します。
（ビデオでは、WordPress プラグインに公開遅延があるため、Discourse に表示されるまでに少し時間がかかります。表示される様子を見るには 1:40 にスキップしてください。）
WordPress ActivityPub プラグインはアクティビティの取り込みもサポートしており、投稿への返信としてアクティビティを受信すると、その投稿への「コメント」として処理するように既に設定されています。ただし、現時点では Discourse プラグインから送信されるアクティビティではその部分はまだ機能していません（WordPress プラグインはまだアナウンスされたノートをサポートしていないと思います）。しかし、それもすぐに機能するはずです。
さらに詳しくはこちらをご覧ください。
「いいね！」 6
Wordpress プラグインのメンテナーである Matthias がこれを機能させたことに注意してください。これにより、Discourse と Wordpress 間でのパブリケーション共有とネイティブな双方向コメント（ActivityPub 経由）がまもなくサポートされるはずです。
https://socialhub.activitypub.rocks/t/this-is-a-test-federation/4164/2
https://pfefferle.org/this-is-a-test-federation/#comment-148
「いいね！」 3
このトピックは、Discourse を利用したコメントシステムが Coral と同様の機能を提供できるというアイデアから始まりました。さらに、ウェブサイトのコメントを通常の Discourse トピックに分岐させることもできます。Discourse は、ウェブサイトのコメントをモデレートする機能と、コメントに関連するディスカッションをフォーラムで行うことを可能にします。
モデレーションの必要性については、議論の余地はないと思います。
コメントを実際の Discourse トピックに分岐させる必要性については、あまり明白ではないかもしれません。オンラインでの会話はどのようなものであれ難しいという前提で作業しています。対面での会話には、オンラインには存在しない様々な微妙な手がかりがあります。意味のあるオンライン会話を（数人以上の）大勢で行うことは、ほぼ不可能です。そこで Discourse の出番です。Discourse のグループ機能は、トピックに参加できる人を制限する機能を提供します。コメント投稿者のグループは、隔離された Discourse トピックに参加できるようにすることができます。これは、fediverse の仕組みとは逆のようなものです。
とはいえ、Discourse/WordPress の fediverse 統合がどのように機能するか興味があります。例えば、サリーがボブの WordPress の投稿にコメントした場合、彼女が Discourse アカウントを持っていたら、サリーのコメントに何が起こることが期待されますか？彼女が Discourse アカウントを 持っていなかった 場合、サリーのコメントに何が起こることが期待されますか？サリーが自分のコメントが fediverse に公開されることをオプトアウトする方法はありますか？
話がそれましたが、西洋諸国で実施または提案されている様々なオンラインハーム関連法案について、サリーのコメントが攻撃的だと判断された場合、誰がそれを公開した責任を負うのでしょうか？現時点では答えられない質問だと思います。
「いいね！」 3
興味深いですね！
ActivityPub がモデレーションやグルーピング（およびその他のオンラインコミュニケーションのルーブリック）の両方でどのように機能するかについて、私が提案したい考え方は、それが主にコミュニケーション標準であるということです。それらの質問に対処するためのいくつかのメカニズムを提供しますが、大部分はシステム内のさまざまなクライアントに任されています。
電子メールをコミュニケーション標準として捉えるのは、不完全ではありますが、おそらく有用なアナロジーです。「電子メール」は、インターネット上の誰とでもメッセージを交換できる一連のコミュニケーション標準です。さまざまな「品質管理」の問題、たとえばスパムがあります。私たちが「電子メール」と呼ぶ標準のコレクションには、それらの問題に対処するのに役立つ側面がいくつかあります（たとえば、DMARC、DKIM、SPF など）。しかし、品質管理が対処される主な方法は、電子メールクライアント自体にあるのかもしれません。Gmail は、スパム（および同様の品質管理の問題）を非常にうまく処理したため、人気の電子メールクライアントになりました。
このアナロジーを続けると、Discourse は ActivityPub の「Gmail」になります。Discourse を優れたディスカッションプラットフォームにしているモデレーションツール、ユーザーグルーピング、その他の機能は、ActivityPub のコンテキスト内でも（ほぼ）すべて利用可能です。質問に答え始めることで、これを具体的に説明します。
まず、何が起こるかを説明し、その後、よりニュアンスのある質問に進むことができるかもしれません。基本的なことを説明するために、多くのことを省略します。
-
サリーのコメントは、WordPress から ActivityPub オブジェクトとして公開されます。
-
オブジェクトは Discourse に取り込まれ、投稿に変換されます。
-
サリーの「アクター」が Discourse のユーザーアカウントに関連付けられている場合、投稿はそのユーザーアカウントに関連付けられます。彼女のアクターがまだユーザーアカウントに関連付けられていない場合、サリーのアクターからステージングユーザーが作成され、そのユーザーが投稿を所有します。
上記の動作は、このトピックで確認できます。
-
Discourse のカテゴリ WordPress - SocialHub は Matthias の WordPress をフォローしています。
-
Matthias は、通常の WordPress アカウントを使用してブログに新しい記事を投稿しました。
-
それは Discourse に新しいトピックとして表示され、投稿は Matthias のアクターに関連付けられたステージングユーザーに関連付けられました。
-
コメントの動作はまったく同じです。
おそらく最も明白な質問に答えるために：Matthias は、WordPress アクターから作成された「ステージング」ユーザーと、そのサーバー上の通常の Discourse ユーザーを統合できますか？
短期的な答えは、Discourse プラグインには「承認」機能セットがあり、現在、他の Discourse サーバーまたは Mastodon サーバーからのアクターの所有権を主張でき、これによりステージングされたユーザーがアカウントにマージされます（これにより、メインの Discourse アカウントで投稿を所有できます）。この機能セットは WordPress に拡張される可能性があります。これは少し冗長であることは承知していますが、このデモで私が何を意味するのかを理解する方が簡単なかもしれません。
長期的な答えは、ActivityPub アクティビティにアイデンティティ証明が組み込まれる可能性があり、ユーザー主導の承認の必要性がなくなる可能性があるということです。つまり、「統合」は（より）自動的に行うことができるということです。
Matthias がステージングされたユーザーのアイデンティティ属性を ActivityPub アクターを通じて引き続き制御していることを考えると、「統合」が必要かどうかという疑問もあるかもしれません（これは WordPress で編集可能であり、編集内容は Discourse のステージングユーザーに反映されます）。
私はこれらのほとんどを、よりニュアンスがあり、重要な質問に進むための「前置き」として述べています。これまでのところ、私が言っていることが理解できていることを願っています。
「いいね！」 2
理解できています。
モデレーションの問題についてですが、WordPressのコメントをDiscourseでモデレートすることについて話しています。これは、DiscourseをCoralと同様の方法で使用できる機能です。WordPressのコメントが実際にDiscourseのコメントであり、API経由でWordPressからDiscourseに公開される場合、これは簡単に実現できます。これはそのまま機能します。これにより、Discourseが提供するAI搭載のモデレーションツールなどを使用できるようになります。WordPress/Discourse ActivityPub統合で同様のことが達成できるか疑問に思っています。
ステージングユーザーの本人確認は何ですか？メールアドレスはオリジンサーバーから渡されますか？
（個人的な）懸念事項として、コンテンツ全体をFediverseに公開したくないという点について、DiscourseサイトとWordPressサイトの間で1対1のActivityPub関係を技術的に設定することは可能のようですが、これがActivityPubプロトコルの目的を損なうのではないかと思います。
編集：ウェブサイトと関連するDiscourseフォーラムとの間のWin-Winの関係を作成することが目標であることを付け加える価値があるかもしれません。Discourseのモデレーションツールは、ウェブサイトのコメントシステムが適切にモデレートされているという安心感を提供することを目的としています。ウェブサイトのコメントセクションは、Discourseサイトにトピックとユーザーをシードするために使用されることを目的としています。
「いいね！」 2
ActivityPub オブジェクトから変換された投稿は、API を介して作成された投稿と、ほぼ*同じ前処理および後処理関数が適用されます。エントリ ポイントは異なります (つまり、投稿コントローラーではなく ActivityPub コントローラーですが、投稿の作成方法はほぼ同じです。
*より技術的な言葉で言うと、API を介して投稿を作成する場合、実際の処理は NewPostManager を介して行われ、その後、ほとんどの作業が PostCreator に引き渡されます。NewPostManager が (ここでは私たちの目的にとって) 処理する主なことは、レビューキューです。その他すべては PostCreator で処理されます。
現在、ActivityPub プラグインは NewPostManager をスキップし、プラグイン自身の PostHandler で PostCreator に引き渡しています。これは主に、初期実装の複雑さを軽減するためです。プラグインの PostHandler が投稿を NewPostManager に引き渡し、レビューキューチェックの恩恵を受けることができないという本質的な理由はありません。
要するに、ActivityPub プラグインを介して作成された投稿と通常の API を介して作成された投稿の間には、実質的な違いはありません。
これにはいくつかの層があります。
-
まず、元のサーバーからあなたのサーバーへの POST は、HTTP シグネチャを使用して署名され、リクエストが実際に元のサーバーから発信されたものであることを保証します。
-
次に、その元のサーバー上の各アクター (つまりユーザー) には UUID、つまりドメインに紐付けられた ID があり、フェディバース内で一意です。次のようなものになります。
https://angus.ngrok.io/ap/actor/f4b517bf6f81dbddfad3e44a45c9619d
メールアドレスは ActivityPub では使用されません。
-
受信する各アクティビティ (たとえば、投稿のようなオブジェクトの作成) は、アクター ID に関連付けられています。そして、各アクター ID はアクター属性に解決できます。
-
そのため、サーバーで「アクティビティ」、たとえば新しい投稿のようなオブジェクトの作成を受信する時点までに、アクティビティを受信したドメインに応じて、アクティビティを実行しているアクターの属性を知ることができます。ここでは送信ドメインを信頼していますが、これは、たとえば Discourse が WP Discourse プラグインを使用して WordPress インスタンスを正しいユーザー属性の送信元として信頼する場合と同様に、常に当てはまります。
したがって、ステージングされたユーザー自体は、メールからのステージングされたユーザーが本人確認を必要としないのと同じように、本人確認をそれ自体で必要としません。
本人確認の必要性は、ActivityPub アクターに関連付けられた実際の人物が、Matthias の例のように別の Discourse アカウントを所有しており、それらを統合 (または「照合」) したい場合に生じます。彼らは、単一の Discourse 上に事実上 2 つの「ユーザー」がいることを好まないかもしれません。このような照合がない場合、彼らは以下を制御できることに注意してください。
- ソースドメインを介した ActivityPub アクター / ステージングされたユーザーの ID 属性 (たとえば、WordPress プロファイルを更新すると、それらの更新がフェデレーションされ、Discourse も同様に適用されます)。
- ソースドメインを介した ActivityPub アクター / ステージングされたユーザーに関連付けられたコンテンツ (たとえば、WordPress コメントを編集すると、更新アクティビティが送信され、Discourse によって処理されます)。
しかし、それでも、彼らは Discourse 上に事実上 2 つのユーザーがいることを「乱雑」と感じるかもしれません。そのため、プラグインには「承認」機能セットがあり、通常の Discourse ユーザーがステージングされたユーザーを持つ ActivityPub アクターに関連付けられていることを示すことができます。これは現在、プラットフォーム固有の承認メカニズムを介して行われます。
- Mastodon の場合、Mastodon の OAuth API を介して行われます。関連するアクターを制御していることを証明するために、Mastodon アカウントを認証する必要があります。
- Discourse の場合、ユーザー API を介して行われます。これは、前の投稿のビデオに示されているものです。
- WordPress についても、同様のことを行う方法はいくつかあります。たとえば、WP Discourse プラグインを介した DiscourseConnect です。これはまだ実装されていません。
ステージングされたユーザーに関連付けられたアクターを所有していることを証明すると、ステージングされたユーザーは通常のユーザーとマージされ、その投稿はあなたのものになり、そのアクターに関連付けられた新しいアクティビティはすべて自動的にあなたのものになります。しかし、この機能セットは実際には UX を改善するためのものであり、厳密には必要ありません。これらのさまざまなユーザーの背後にある実際の人物は、最初からユーザー属性とコンテンツの両方を制御しています。
はい、送信される公開のターゲットをチャネルし、受信される公開のソースを制限することは可能です。これが ActivityPub の目的を損なうかどうかは議論の余地があります。厳密に言えば、ActivityPub は単なる標準です。標準をこのように使用できない理由はないと主張します。歴史的に ActivityPub は、特に Mastodon のような分散型ソーシャルネットワークと関連付けられてきたため、この種のアプローチが ActivityPub の目的を損なうと感じるのかもしれません。しかし、ActivityPub 標準自体とその既存の実装との間には区別があると思います。
さらに、このコンテキストでは、電子メールと同様に、「ActivityPub」と呼んでいるものは実際には標準のコレクションであることを指摘したいと思います。「ActivityPub」というタイトルの標準ドキュメントは、「ActivityStreams」という別の標準ドキュメントと一緒に読む必要があります。これは、ここで関係する主なオブジェクトを説明しています。ActivityStreams 標準は、ActivityPub 自体よりも「サービスニュートラル」 (つまり、分散型ソーシャルネットワークへの依存度が低い) です。
(別の) 例えを使用すると、ブロックチェーンテクノロジーは単なる分散型台帳であり、最初に説明されたとき、19 世紀に発明された Torrens システムの土地登録 (オーストラリアで) を思い起こさせました。これは、ブロックチェーンが発明されたのと同じ理由 (つまり、不動産取引における詐欺を防ぐため) でした。しかし、ブロックチェーンの最も人気のある実装は Bitcoin であり、(異なる) 特定の用途と特定の文化的価値観を持っています。この例えは最良ではありませんが、考え方としては、Mastodon と分散型ソーシャルネットワークは、Bitcoin がブロックチェーンであるのと同じように、ActivityPub にとってのものです。
実際、NodeBB、Flarum などとともに新しい W3C ActivityPub for Forums 作業グループを設立するのを手伝った理由の 1 つは、ActivityPub 統合の焦点を既存の実装 (たとえば Mastodon) から、あなたが提起しているモデレーションに関する懸念など、フォーラムの懸念に移そうとすることです。実際、今日が次の会議です。時間があれば、仲間の「Discourser」(という用語ですか？) にもぜひ参加してほしいです
「いいね！」 4
Discourseのモデレーションツールを使用して、WordPressに表示されるコメントをモデレートすることについて話しています。技術的には、Discourse APIリクエストまたはWebhookを使用して行うことができます。Discourseでモデレーションアクションが発生した後、WordPressのコメントのステータスを変更するリクエストを行うことができます。
ActivityPub投稿がレビューキューで処理されるように変更されたと仮定しても、コメントがWordPressに最初に公開されたときとDiscourseに表示されるときの時間の遅延という問題が残ります。それは数分だと思いますか？
この特定のケースでは、主なセールスポイントの1つは「Discourseを使用してウェブサイトのコメントをモデレートする」ことです。さらに、Discourseのモデレーション機能、信頼レベルシステム、レビューキュー、AI搭載モデレーションツールなどがリストされています。これらは小規模なブログには便利なツールですが、主流のニュースサイトには必須です。これを達成するための最善の方法は、コメントが2つ（またはそれ以上）のデータベースに存在するのではなく、Discourseをコメントの単一の真実の情報源として使用することだと思います。
それは素晴らしいですね！もう少し考える時間がありませんでしたが、Discourseの優れた代表者にはなれないと思います。
トピック、投稿、ユーザーを単なるデータの断片として扱うという考えには、一般的な懸念があります。議論が行われているコンテキストが失われないようにする方法が必要です。
より実用的なレベルでは、ActivityPubプロトコルは、さまざまな国で導入されているオンラインハーム法案が導入される前に普及しました。データの発信元からデータを消費するサーバーが削除リクエストを尊重することを保証する必要があります。そうしないと、発信元サーバーでコンテンツを生成したユーザーは、コンテンツが自国で有害と見なされた場合、法的措置のリスクを負うことになります。
「いいね！」 3