ディスコースは実用的なコメントプラットフォームになるよう努力すべきか?

このスレッドを読み直しているのですが、答えは間違いなく「はい」だと思います :slight_smile:

エンタープライズコミュニティの成功(ユーザー側、および社内側双方)により、ドキュメントチームから documentation.sailpoint.com 全体にコメントシステムを構築できないかという依頼がありました。見たところ、最低限やりたいことの「ほとんどすべて」を実現できそうです。

そこから、ドキュメントチーム(および私のチーム)が望んでいた他のすべては、Discourse 内で実現可能でした。これにより、日常的なフォーラムの利用とは切り離された体験を提供しつつ、コメントしたり、返信の通知を受け取ったりする機能を提供できます。

  • コメントできるユーザーとできないユーザーを指定する機能
  • カテゴリモデレーターを関連トピックに割り当てる機能
  • ドキュメントの多数のカテゴリをメインサイトから非表示にする機能
    • カテゴリを検索不可にする
    • メインのカテゴリリストから非表示にするテーマコンポーネントを使用する
    • ダイジェストから非表示にする
    • デフォルトでミュートするカテゴリに追加する
  • n日後にコメントを削除する機能
  • その他いくつかの設定…

ここに挙げられている機能の多くが実装されることを強く望んでいます!

「いいね!」 3

https://documentation.sailpoint.com/ にユーザーがコメントを作成できるようにすることが目標ですか、それとも、ドキュメントサイトにコメントを埋め込み、ユーザーがDiscourseサイトにアクセスして記事にコメントするようにしても大丈夫ですか?

「いいね!」 3

前者については、ぜひとも実現してほしい機能です(CDCKさん、ぜひ開発してください!)。しかし、後者は少なくとも最低限の要件を満たしています。

将来的には、Discourse を使ってマークダウン形式のドキュメント(トピックではなく、従来のマークダウン形式のドキュメント)を提供することも検討しています。その場合、コメント機能やコメント投稿のためのサインアップはすべて含まれます。しかし、その検討はまだ始まっていません。

「いいね!」 3

現在取り組んでいるアプローチでは、DiscourseのコメントをMkDocsのページに直接生成することが技術的に可能になりますが、そのためにはサーバーサイドフレームワーク(Remix、Railsなど)を使用してMkDocsのページを提供する必要があります。これにより、ドキュメントサイトでユーザーを認証し(DiscourseConnectを使用)、以前に返されたコメントをキャッシュするためインメモリデータベースを使用することも可能になります。

(編集:明確にしておくと、DiscourseをウェブサイトのIDプロバイダーとして使用することについて話しているのであって、ウェブサイトをDiscourseのIDプロバイダーとして使用することではありません。後者のアプローチは機能しますが、ほとんどのユースケースには柔軟性が低すぎます。)

しかし、それはあなたのチームに大きな変更を依頼することになります。

あなたの視点からは、これが完全にDiscourse内で達成される方が簡単でしょうが、Discourseをコンテンツ管理システムとして使用することも可能です。その場合、マークダウンドキュメントは通常のDiscourseトピックとして生成されます。DiscourseのWebhookを使用して、外部サイトでドキュメントページの生成をトリガーします。これは、現在セットアップしているDiscourseコメントデモサイトの基盤でもあります。

「いいね!」 5

このプラットフォームの素晴らしいところは、まさにそれです。これらのどちらか(または両方!)を可能にするためのすべての基盤が整っていることです。

「いいね!」 5

このトピックは本日リンクされたため、このアイデアについていくつか作業を行った後の結論を更新する必要があると考えました。

OPで概説した理由から、Discourseは引き続き優れたコメントプラットフォームになると考えています。

その方法については、Discourse側で作業を行う必要があると考えています。理想的には、Discourseのコメント埋め込みスクリプトを改善することです。これは段階的に行うことができます。

Discourseクライアント(たとえば、WP Discourseプラグイン)で作業を行うことで、Discourseをコメントプラットフォームのサーバーとして使用することは技術的に可能ですが、クライアントとDiscourse間の状態を管理し、レート制限の問題を回避する必要があるため、複雑な問題になります。これは間違いなく、私が保守を担当したいものよりも複雑です。

このトピックのいくつかの投稿では、ユーザーがブログサイトでDiscourseコメントを作成できるようにすることに関心があることを示していました。私の見解ではそれは良い解決策ではありませんが、Discourse APIを使用して現在達成できます。複雑になるのは、ユーザーが典型的な主流のニュースサイトでコメントを操作するのと同様の方法で、ウェブサイト上のDiscourseコメントを操作できる完全なコメントシステムを作成しようとするときです。

「いいね!」 8

Drupal側でDiscourseコメントをAPI経由で書き込めるDrupal統合モジュールが開発されています。
https://www.drupal.org/project/discourse_comments_plus

「いいね!」 4

ActivityPub と WP Discourse の経験から、埋め込み JavaScript を介した双方向コメントは実現可能だと考えます。埋め込みスクリプトには以下が含まれます。

  1. 現在の JavaScript 埋め込みと同様の機能を持つ認証不要の「読み取り」(いくつかの最適化を含む)。
  2. リモートクライアント(ユーザーのブラウザ)が、ユーザーのセッションに固有の ユーザー API キークライアントを登録します 。関連する詳細はブラウザのローカルストレージに保存されます。
  3. ユーザーには「コメントするにはログイン」と表示されます。
  4. ユーザーは認証(Discourse で)を行い、ブラウザのローカルストレージに保存されるセッションユーザー API キーを取得します。
  5. 各アクティビティ(コメント、いいねなど)は、適切な保護、処理、タスク管理とともに、専用のエンドポイントに直接投稿されます。

適切な予算があれば、v1 を本番環境に対応させ、discourse/discourse と統合するのに 6 ~ 8 か月かかると思います。初期リリース後、以下を行うことができます。

  1. WordPress、Ghost、その他の選択されたプラットフォームの明示的なサポートを追加します。
  2. ドキュメントを作成します。
  3. サポートします。

cc @pmusaraj @mcwumbly

「いいね!」 6

技術的な知識がないユーザーにも分かりやすいように実装してみてください。既存のプラットフォームであるDisqusやFacebookのコメントなどが良い例になるでしょう。

さらにいくつかの認証オプションを挙げます。

  • クライアントサイトをDiscourseConnectクライアントにする。これは実装が簡単ですが、クライアントサイトにサーバーサイドコードを追加する必要があります。
  • ユーザーがクライアントで認証を行い、その認証ステータスがpostMessage API経由でiframeに渡されます: Window: postMessage() method - Web APIs | MDN
  • ユーザーがiframe経由で直接Discourseにログインする。

クライアントサイドだけで開発することに抵抗があったのは、ある程度の規模でシステムが動作する場合の問題を考慮したためです。基本的に、APIリクエストをキューイングし、キューイングされたリクエストからの応答を処理する必要がありました。例えば、1000人の同時ユーザーを処理するには、十分な堅牢性があるとは感じられませんでした。JavaScript埋め込みアプローチでも、異なる理由で同様の懸念があります。しかし、クライアント側で全てを同期しようとするよりも、はるかに扱いやすいと思います。

「いいね!」 3

フィードバックありがとうございます :slight_smile:

昨日、このトピックが再度取り上げられた(だからここに投稿することになった)ので、さらに深く考えました。クライアントのみのソリューション(つまり、JavaScript埋め込み)だけが本当に理にかなっていると思います。そうでなければ、それぞれに独自の課題がある、プラットフォーム固有の実装の数について話していることになります。

同時実行性と負荷が問題であるというのは正しいです。ActivityPubは、単一のActivityPub投稿がFediverseとの間で多数の着信および発信リクエストを開く可能性があるため、同時実行性と負荷に重大な問題があります。その文脈では、リモートクライアントが制御されているため、実際には少し簡単かもしれません。さらに、この場合、同時実行性と負荷はサーバー側(つまりDiscourse側)でのみ問題となり、それらは問題ですが、バックグラウンドジョブ、キャッシュ、ミューテックスを通じて解決可能だと思います。しかし、はい、考慮すべき重要な問題です。

「いいね!」 3

正直なところ、最大の懸念はタイミングです。

Composer v2が間もなくリリースされます。この冒険に乗り出して新しいComposerを活用しないのは狂気の沙汰ですが、軽量アプリでそれを使用できるようにするには、かなりの作業が必要です。

ここでは、2〜3ヶ月ほどこの状況を注視し、それからこの問題を再検討するのが正しいことだと思います。

「いいね!」 7

並列で実行できると思います。ディスコースに2つの変更を加える必要があります。
「返信」ボタンは未登録ユーザーにも表示される必要があります。
reply

そして、未登録ユーザーがこのボタンをクリックしたときに、これが表示されるべきです。
login

次に、コメントの挿入方法を理解する必要があります。これは、かなりの作業というよりは、おそらく小さなコードの変更になるでしょう。

「いいね!」 2

Composer v2 がリリースされた今、この機能の開発への関心がまだあるかどうか疑問に思っています。これは私がまだ見て、使用したいと思うものだと投票します。