これは実際には Discourse とは関係ありませんので、feed2toot プロジェクトに問い合わせてください。頑張ってください。
「いいね！」 1
ジェームズ、情報ありがとう。
キース
Matrix のコメント機能は、他のチャットシステムとフェデレーション（「ブリッジ」）できるため、興味深いかもしれません。ActivityPub ベースではありませんが、分散型であり、Chat Integration プラグインを通じて現在、Matrix へのクロスポストがサポートされています。
「いいね！」 1
「フェデレーテッドプロトコルが機能しない理由」
「いいね！」 5
「自由の価値」
「いいね！」 1
あまり説得力がないと感じます。要点は以下の通りです。
- XMPPはひどい
- フェデレーションはメタデータに関するプライバシーの問題を解決しない
- 「デバイスのアドレス帳がソーシャルネットワークになった」という主張
最初の点は、一般的でなくても真実である可能性があります。記事は、一般的な議論をしようとはしていません。「GitHubのissueテンプレートを見てみよう」という以上のことは、実装方法への不満であって、意味のある論点ではないように思えます。
2番目の点は、完全に真実のように思えますが、フェデレーションの唯一の理由ではなく、私にとっては「障害」ではないように思えます。「完璧は善の敵」など。
そして3番目のことですが…狭い意味では真実ではないと思いますし、その意味では私が本当に望んでいるものではありません。はい、携帯電話のフォルダに20以上のメッセージングアプリがあり、それらはほとんどアドレス帳を共有していますが、それは私にとって「問題解決！」ではありません！
「いいね！」 8
Matthew（Matrix）がMoxie（Signal）に応答した最後の部分から
あらゆる犠牲を払ってプライバシーを最適化したメッセージングアプリを書くのであれば、Moxieのアプローチがその一つの方法であることは事実です。しかし、これは非常に閉鎖的な世界、つまり非公式クライアントが禁止されている閉鎖的なネットワークであり、構築するためのプラットフォームも、オープンスタンダードもなく、結局はすべての卵を一つのカゴに詰め込み、Signalがその価値観を維持し、妥協や検閲を回避し続けることを過去、現在、そして未来にわたって信頼することになります…おそらくインターネット上で最も価値の高い攻撃対象であるにもかかわらず。
単純に言って、それは私が生きたい世界ではありません。
インターネット（ましてやWeb）の成功はすべて、オープンさ、相互運用性、分散化のおかげです。メッセージングソリューションを構築する際に、オープンさ、相互運用性、分散化は「難しすぎる」し、努力する価値はないと宣言することは、オープンネットワークから生まれる活力、創造性、革新性のすべての可能性を捨て去ることになります。確かに、超プライベートなメッセージングアプリを手に入れることができるかもしれませんが、それはFacebookのInternet.orgイニシアチブのような walled garden、AOLのキーワード、GoogleのAMPのように、驚くほど似たものになってしまうでしょう。
そのため、私たちはMoxieの挑戦を喜んで受け続け、彼が間違っていることを証明します。つまり、オープンで分散化されたメッセージングプラットフォームを作成することが可能であり、かつ不可欠であることを示します。このプラットフォームは（信頼できるアプリとサーバーを使用すれば）Signalと同じくらい安全でメタデータを保護でき、さらに、サーバーをオフグリッドで実行でき、電話番号の登録も不要で、将来的にはサーバーさえ不要になる可能性があることを示します。
「いいね！」 4
さらに、Moxie の投稿は 2016 年のもので、Matrix プロトコルが導入されてからわずか 2 年後、ActivityPub がリリースされる 2 年前です。
自分のメールを自分でホストできるのは良いことですが、それも私のメールがエンドツーエンドで暗号化されていない理由であり、おそらくこれからもそうなることはないでしょう。
それ以来、メール プロトコルと Autocrypt を基盤とした Delta.chat が登場し、この声明は間違いなく間違っています。メールは E2EE であり、以前は OpenPGP でしたが、確かに Autocrypt はエンドツーエンド暗号化をより簡単に利用できるようにします。
Discourse が Autocrypt を実装することは完全に可能であり、中央集権型とフェデレーション型の両方の利点を達成するのに役立つでしょう。しかしもちろん、Discourse がそもそも [Discourse インスタンス間のフェデレーションへのエントリ ポイントとしてステージングされたユーザーを採用する] ならば、フェデレーションについて議論する方がはるかに理にかなっています。Moxie の当時の関心は、なぜ人々が独自の Signal サーバーをデプロイすることを許可しないのかを正当化することでした。そして、クライアントのアップグレードを含む、あらゆる種類の問題に対処するための多くのプロトコルが開発中です。
「いいね！」 4
これは別の機能リクエストのように読めます 
これを詳述する別のトピックを作成していただけますか、それともこの件に関するトピックはすでにありますか？
「いいね！」 3
以前、同様の議論で提案したと思いますが、探してみます…
- ActivityPub Support: Phase 1 RFC - #7 by hellekin
- ActivityPub Support: Phase 1 RFC - #45 by hellekin
提案を新しい機能トピックに統合していただければ幸いです。
「いいね！」 5
USENETを再発明する必要があります…
「いいね！」 2
Mathew による、フェデレーション プラットフォームである Matrix に関する別の記事はこちらです: Here is another article by Mathew about Matrix, a federated platform. Money quote:
It’s like USENET had a baby with the Web!
「いいね！」 1
フェデレーションの議論でe2eについて話しても全く意味がありません。誰かこれらの返信を新しいトピックに移動してもらえませんか。
「いいね！」 1
おそらく、Lemmy Protocol が良い出発点になるでしょう。
すでにメーリングリストモードがあり、同様に機能します（Fediを介している点を除いて）。
Zoomイベントはこちらです 2022-04-28T20:00:00Z
今日のソーシャルメディアの世界では、偽情報や荒らし行為に直面した際にプラットフォームが誤作動するのを見てきました。権威主義的な政権では、プラットフォーム全体が簡単にブロックされます。そして、そう、億万長者がプラットフォームを購入してルールを変更することもできます。
分散型（またはP-2-P）ソーシャルメディア、つまり中央の管理主体が存在しないものは、より良いのでしょうか？中央のコマンドセンターがない場合、どのようにして有害な投稿を削除するのでしょうか？ Matrix、Manyverse、そして新しいBlueskyイニシアチブなど、いくつかのトップ分散型ソーシャルメディアネットワークの創設者が、可能性を探ります。Facebook、Slack、Twitterのこれらのピアツーピアの代替手段の使用方法の実演とともに。
スピーカーについて：
Jay Graberは、Jack DorseyとTwitterが資金提供するイニシアチブであるBlueskyのCEOです。「オープンで分散化された公開対話のためのテクノロジーの大規模な採用を開発し、推進する」ことを目的としています。
Matthew Hodgsonは、https://matrix.org/の共同創設者です。Matrixは、4000万人以上のユーザーを持つ、安全で分散化されたコミュニケーションのためのオープンネットワークです。
Andre Staltzは、ピアツーピアSSBプロトコル上に構築された、無料のオープンソースの「悪質なものなしのソーシャルネットワーク」であるManyverseのクリエイターです。
このイベントは、Metropolitan New York Library Council、Internet Archive、DWeb、Library Futuresが提供する一連のワークショップの一部です。詳細はこちらをご覧ください：https://metro.org/decentralizedweb
コード・オブ・コンダクト、見解に関する声明、および通訳サービスの詳細については、こちらをご覧ください：https://metro.org/code-of-conduct
「いいね！」 6
**これです。**おそらくリモートの「いいね」アクションの統合も。
イーロン・マスク氏がTwitterの買収提案を開始して以来、Fediverseが著しく活発になり、人口が増加したことに気づきました。
私が運営しているDiscourseインスタンス（現在3つ）では、Mastodon（私の場合は）を使用して、それらをフォローし、「ブースト」してより広いオーディエンスにリーチできるようにしたいと考えています。これにより、私のインスタンスの情報が、関心を持つ可能性のある他の多くの人々にアクセスしやすくなり、可視性が高まります。私のインスタンスはすべて、さまざまなトピックに関する公開知識の範囲を拡大するためのものであり、ActivityPub統合によるリッチな共有サポートは、その目標を達成するのに役立ちます。
RSSをActivityPubに変換してもあまり役に立ちません。
もしこれが私のプロジェクトであれば、段階的に単純なものから始めます。
- 公開のみ: カテゴリをアクターとして、トピックへの返信投稿を
inReplyToで適切にスレッド化して含めます。これらは、たとえばチャット統合に投稿が転送されるのと同時に、投稿ごとにフォロワーに送信されます。これには、少なくとも一部のカテゴリをアクターとして公開し、各アクターのフォロワーを保存する必要があります。これらのカテゴリのアクターはフォローしたり「いいね」したりしません。認証されたアクセスは使用されません。「いいね」、「ブロック」、「取り消し」アクティビティは尊重されます。おそらく、サーバー全体のアクターも、サーバー上のすべての活動を簡単にフォローできるようにします。 - 最小限の双方向: オプションで、リモートの「いいね」アクションを受け入れます。
- より双方向: 「アナウンス」アクション（つまり、共有、再投稿、ブースト）を操作し、それらを「いいね」として追加するか、個別に表示します。
- ユーザーインタラクション: オプションで、ユーザーのWebFingerサポートにより、ユーザーをアクターとしてフォローしてすべての投稿を表示できるようにします。さらにオプションで、グループによって制限されます（たとえば、TL2に制限したい場合があります）、プライベートメッセージを外部ActivityPubアクターとやり取りする機能。これは、ユーザーが「いいね」した投稿のコレクション（少なくとも公開されているもの）を
likedコレクションに実装する可能性があります。 - テキスト双方向: オプションで、ActivityPub経由の非メンバーからの応答をコメントとして受け入れますが、これはトリッキーです。なぜなら、それは単純に新しい投稿としてフィードバックされるため、フォロワーは2回見ることになります。おそらく、外部参照でマークされた投稿が必要になり、フォロワーの受信トレイに投稿されなくなります。
Discourse内からActivityPubアクターを「フォロー」することは、明示的に望みません。Discourseを（たとえば）Mastodonクローンにすることは、全体としてかなりの無駄のように思えます。ActivityPub仕様の言葉で言えば、「ActivityPub準拠のフェデレーテッドサーバー」ではなくなり、それは問題ありません。また、プロトコルのクライアント部分は、この計画にはまったく関係ありません。
「いいね！」 6
ActivityPubのRails実装に関するディスカッションが見つかりました。そこで議論を続ける価値があるかもしれません。 
「いいね！」 2
4つのフォーラムを連携させるための提案はありますか？それらはかなり大規模です（メンバー数10万人、2万人、5万人、2万人）。合計20万人です。
フェデレーションはできません。カスタムSSOまたはLDAP認証を設定すれば、すべてのユーザーが共通の認証情報で各フォーラムにアクセスできるようになります。
それらを統合するためにプラグインを作成することもできます。