GitHubでコードを公開しましたが、現時点ではアルファ版の品質と言えるでしょう。多くの機能は動作しますが、プラグインにはドキュメントが不足しており、Discourseで動作させるためにはさらにいくつかのパッチ（こちらのようなもの）が必要です。
これまでに実装された機能：
ベータ版の品質に達したら、プラグインを発表するより正式なトピックを立てる予定です。このプラグインにご興味をお持ちいただきありがとうございます！
http://matrix.org/Element.io はもう存在しません（http://element.io はもちろん存在しますが）。
素晴らしいですが、このメッセージはここで失われてしまいます。このプラグインには別のテーマを作成する必要があります。
テーマとはどういう意味ですか？（トピックのことですか？）
@volanar Danさんの言ったことの要点を理解していないと思います。
彼は、そのレベルの露出を望むときに、新しいスレッドを開始するのに十分な能力があります。
おそらく愚かな質問かもしれませんが、この統合により、Discourse での E2EE 暗号化は提供されますか？それとも、Discourse 上のものをコピーして Matrix にプッシュするだけなので、Discourse の管理者は依然としてチャットで送信されたすべての平文メッセージにアクセスできますか？
これは非常にエキサイティングです。リンクされたプルリクエストが完了したことに気づきましたが、間違いなくそれは巨大なプロジェクトです。Matrixチャットサポートの状況がどうなっているか気になっていますし、楽しみにしています。
これはもう終わってしまったようですが、スレッドに返信して、この件を定期的にチェックしている人が少なくとも一人いることを皆さんに知らせたいと思いました 
これを独自のプラグインセクションに分割していただけますでしょうか。そうすれば、他の人が見つけたり議論したりしやすくなります。ご検討ありがとうございます！
私の理解では、Discourseは主に公開フォーラムとして設計されています。E2E暗号化はこの点でむしろ逆効果です。Discourseインスタンスの管理者を信頼しないのであれば、それを使用する意味はないと思います。E2E暗号化は、管理者が暗号化を回避するためにブラウザに悪意のある機能をプッシュするのを阻止することはできません。一度対多数または多数対多数の通信に高い機密性が要求される場合は、専用のMatrixチャンネルが最善の選択肢だと私は思います。
同意します。インターネットを利用する大多数の人が、プラットフォーム上のプライベートチャットは管理者が閲覧できることを完全に理解していないと想像するだけです。私の場合、管理者として、Discourse のプライベートチャットを無効にするかもしれません。なぜなら、どれだけ伝えても 1 対 1 のメッセージをすべて読めることを人々が理解してくれるかどうかわからず、もし直接連絡を取りたいのであれば、Matrix や Signal を介して行うように促すかもしれません（まだユーザー名を取得中なので、誰もが電話番号を教える必要がなくなります）。
オープンソースの Discourse では、管理者が E2EE を無効にできるため、そもそも信頼できない可能性があるという指摘は理解できます。
返信ありがとうございます〜
非常にクールですが、実際のインストール手順が記載されていません。
このプラグインの詳細とインストール方法については、[Meta](https://meta.discourse.org/t/TODO) を参照してください。
混乱しています。これはMatrixにブリッジするため、いかなる種類のe2e暗号化も含まれていません。単にフォーラムのチャットをMatrixユーザーも利用できるようにするだけです。
これは機密性とは関係ありません。単にMatrixにいる人々とチャットするためだけです。
ここにはe2eはありません。e2eは、サーバーに到達する前にクライアント側で暗号化が行われることを意味します。Matrixサポートとe2eを混同するのはやめましょう。
Discourseでe2eを希望し、他の場所で議論したい場合は、Discourse Encrypt (deprecated) を使用できます。
これは、すべての管理者を各チャットグループの参加者リストに含めることで、非常に簡単に解決できます（もちろん、管理者が参加したり離脱したりするたびに動的に管理されます）。しかし、これはもちろん別のFR（機能リクエスト）になります。
車輪の再発明をしているのかどうかは分かりませんが、Discourse Chatと他のプラットフォームとのブリッジを作成しています。Telegramではかなりの成功を収めており、ブリッジは非常によく機能しています。次に、Discourse ChatとMatrixとのブリッジを検討しています。
素晴らしいですね。開発中の既存のブリッジを確認することもできます。それもまた、取り組む価値があるかもしれません。 GitHub - udan11/discourse-chat-matrix: A Matrix bridge for Discourse Chat
少しです。このスレッドは、DiscourseのチャットプロトコルをMatrixプロトコルに置き換えるというアイデアから始まりました。これは非常に合理的で、よく設計されており、採用も増えているように思えます。なぜここでブリッジについて話しているのかさえ分かりません。問題は、将来的にDiscourseプロトコルを非推奨にすべきかどうかということです。
プライベートチャット/メッセージ（IMHOでは同じはず）のE2EEは、Matrixプロトコルの採用によりデフォルトで可能になります。カスタムプロトコルは不要です。
Discourseコアチームの誰かに、「DiscourseチャットとMatrixベースのチャットとの相互運用性」に関する現在の議論の状況について、何か情報を提供していただけますか？ヨーロッパでは、Matrixを独自のメッセンジャーアプリの技術基盤としてすでに使用している大企業がいくつかあります。
Matrixの採用は世界中で拡大しています。DiscourseチャットとMatrixエコシステムとの「連携」が、近い将来Discourseプラットフォームを使用するための重要な論点になる可能性があると信じています（MastodonとのDiscourse連携におけるActivityPubとほぼ同様です）。
GitHub - udan11/discourse-chat-matrix: A Matrix bridge for Discourse Chat にはブリッジコードがありますが、最後の活動は2年前です。そのため、このコードを採用する計画や、「公式にサポートされている」新しいものを作成する計画はありますか？
ActivityPubはオープンなディスカッションを連携させるのに役立ちますが、Matrixプロトコルを実装することで、異なるDiscourseサーバー間で非公開カテゴリを連携させる安全な方法としても利用でき、ユーザーに通知を送信する追加の方法としても機能します。
現時点では具体的な計画はありません。
リポジトリにある初期の調査では、Matrixとのチャットの相互運用性を実現する可能性について、Danと協力していました。
当時は有望に見えましたが、完全に対処できなかった課題がいくつかありました。主なものは、各システムのユーザーの扱い方です。
また、チャットもそれ以来かなり進化しており、Matrixとの互換性を設計上の制約として扱ってこなかったため、両システム間にさらに乖離が生じ、対処が必要になる可能性があります。
この作業を進め、構築されたものを維持するためのより強力なインセンティブを確保するには、誰かがこの作業をスポンサーする必要があるでしょう。