コミュニティに境界はない：Discourse-as-a-Fabric - アイデア出し＆ブレインストーミング

コミュニティ
1

ActivityPub サポート：フェーズ 1 RFC では、Discourse における ActivityPub サポートのビジネスケースを評価し、MVP を超えて「フェデレーションを念頭に最初から構築された Discourse」を想定したアイデア出しの演習について概説しました。

そこでここでは、現在のコードベースの技術的な実用性を考慮せず、いくつかのブレインストーミングを通じてアイデア出しを開始します。これには多くの細部やエッジケースが存在することは承知しています。これは、ネイティブなフェデレーションサポートがどのように見えるかというビジョンです。では始めましょう。

コミュニティに境界はない

pexels-pixabay-262488
pexels-pixabay-2624883648×2736 924 KB

(写真提供：Pixabay from Pexels)

私たちは皆、一つの惑星を共有し、複雑な社会構造の中で混ざり合っています。なぜ Discourse コミュニティは単一のフォーラムに制限されるのでしょうか？

私は Humane Tech Community（HTC）の管理者を務めており、ここでは「Freedom > Privacy（自由 > プライバシー）」「Alignment > Ethics（整合性 > 倫理）」「Alignment > Standards（整合性 > 基準）」といった幅広い技術関連のトピックをカバーする（サブ）カテゴリを設けています。範囲が広すぎるかもしれませんし、これらのカテゴリに特化し、私達よりも優れた成果を出している他の Discourse フォーラムも多数存在します。しかし、「人間中心の技術」という分野全体を俯瞰したい人々にとって、この広いポジショニングは理にかなっています。

カテゴリのフェデレーション

もし、私たちの「Privacy（プライバシー）」サブカテゴリを、例えば PrivacyTools フォーラムの「Blog Posts（ブログ投稿）」サブカテゴリとフェデレーションできたらどうでしょうか？おそらく一方向の同期のみを行うかもしれません。HTC のプライバシーサブカテゴリの範囲が広いため、PrivacyTools で作成されたトピックが HTC フォーラムに表示され、私たちのメンバーがそれらと対話できるようにします。HTC フォーラムでのトピック投稿は、PrivacyTools のトピックへ、そしてその逆もまた同様に戻されます。両フォーラムのトピックは同期され続けます。もしかすると、複数の PrivacyTools サブカテゴリを HTC の「Privacy」に一方向で同期することも望めるかもしれません。そして、なぜ同様の方法で他のプライバシー関連コミュニティとも同期しないのでしょうか。

別の例として、Feneas と SocialHub の両方に、トップレベルの「ActivityPub」カテゴリが存在します。これらには重複があり、あるコミュニティのメンバーが別のコミュニティで何が起きているか unaware（無知）であるケースがあります。これは「ActivityPub」が双方向同期の候補となる機会であり、各フォーラムが同じトピックリストを含むようにする可能性があります。

タグと個別のトピックのフェデレーション

同じことがタグにも適用できます。特定のタグがフェデレーションされるように設定するのです。例えば、SocialHub の #specification タグを持つトピックが、HTC の「Alignment > Standards」サブカテゴリにフェデレーションされるように設定する場合があります。

トピックは、ケースバイケースでフェデレーションされることもあります。これはツールバーのコマンドによってトリガーされ、フェデレーション先のターゲットフォーラムを指定し、トピックが表示されるリモートカテゴリを選択することもできます（つまり、フォーラムのカテゴリリストもリモート閲覧のためにフェデレーションされます）。

メンバーのメンションとプロフィール閲覧

トピックが別のフォーラムにフェデレーションされる場合、その中のメンションはメンバーが所在する場所を反映するように適応する必要があります。HTC での私の @aschrijver ハンドルは、同期後に SocialHub フォーラムでは @aschrijver@humanetech として表示されるかもしれません。

私は SocialHub 上のユーザーでもあるため、プロフィール設定でアカウントを接続し、検証を行えば、同期されたトピックにおいて私のローカルアカウントのハンドルを表示させることができます。

リモートハンドルまたはメンバーのアバターをクリックすると、リモートフォーラムのプロフィールカードが表示されます。もう一度クリックしてプロフィールサマリーを表示すると、同期されたトピックの相互作用から生じたローカルフォーラム上のアクティビティ指標のみが表示されるかもしれません。あるいは、より興味深いことに、フェデレーション設定の一部である既知のすべてのフォーラムからのサマリーを表示することも可能です。例えば、応答が非常に活発で専門的なメンバーのものであることが、相手側のフォーラムで判明するようになります。

直接メッセージと通知

DM は、ローカルだけでなく、すべてのフェデレーションされたフォーラム間で可能になります。これは、DM 内でリモートメンバーをタグ付けまたはメンションすることで実現されます。それ以外については、DM コミュニケーションの仕組みに違いはありません。現在のローカル限定の DM と同じように機能します。

上記のフェデレーション機能から、通知もフェデレーションする必要性が生じます。リモートメンバーの投稿に返信したり、その投稿に「いいね」をつけたり、同期されたトピックスレッドでメンションしたりした場合、リモートフォーラムに UI 通知が表示され、メンバーに知らせることができます。メール通知もリモートフォーラムが処理します。ただし、メンバーが両方のフォーラムでアカウントをリンクしている場合、通知は相互作用が最初に発生したローカルフォーラムから届く可能性があります。

シングルサインオン

これまで説明したすべての機能において、SSO（シングルサインオン）の必要性はありません。リモートメンバーが別のフェデレーションされたフォーラムに自動的に特権アクセスを得るわけではありません。では、一方向に同期されたトピックスレッドで彼らがメンションされた場合どうなるでしょうか？その場合、彼らは自身のフォーラムインスタンスから届く UI 通知とメールを受け取り、それをクリックすると別のフォーラム（新しいブラウザタブかもしれません）に誘導され、そこでトピックを閲覧できます。返信したい場合は、まずサインアップしてアカウントをリンクし、返信できるようにする必要があります。

SSO は Fediverse において厄介な問題であり、まだ良い解決策は見つかっていません。しかし、Discourse 間のフェデレーションにおいては、SSO 機能の実装ははるかに容易になる可能性があります。SSO 統合があれば、通知をクリックすることで、トピックを現在のフォーラム内で「リモートビュー」として文脈的に開き、メンバーがシームレスにそれと対話できるようになります。

フェデレーション管理と複雑さ

このユースケース全体は、Discourse がフェデレーションサポートを組み込んで最初から構築されたかのように記述されています。これらすべてが実装されれば、製品のほぼすべての機能に影響を及ぼします。このスレッドを開始させたユースケース（FB 風の パーソナライズされたフィード）とは異なり、ここでのフェデレーションは個々のメンバーの気まぐれではなく、フォーラムスタッフによって慎重に管理されます。

フェデレーション設定の多くは管理者専用のものです。コミュニティの組織化とコンテンツを直感的かつ論理的に保つため、戦略的かつ十分な計画のもとに行われるべきです。フェデレーションのセットアップは、コミュニティ構築ワークフローの一部として時間とともに徐々に構築されるものであり、気軽に追加するものではありません。

相互運用性

もちろん、この ActivityPub サポートのビジョンは Discourse に限定される必要はありません。互換性のあるソフトウェアプロジェクトであれば、分散型コミュニティの構造の一部になることができます。例えば、forem のオープンソースコミュニティ構築ソフトウェアや、loomio の協働意思決定プラットフォームなど、これら両方に私がこの投稿の方向性を示したばかりです。しかし、Discourse はこれらすべてにおいて主導権を握る機会を持っています。

Fediverse 統合

ここまでのフェデレーションサポートは、フォーラム/コミュニティのビジネスドメインに限定されていましたが、ActivityPub 統合により相互運用性は拡大し、より広範な Fediverse を包含できるようになり、数多くのエキサイティングなビジネスケースが可能になります。思いつくものをいくつか挙げてみます。

  • Mastodon や Pleroma のマイクロブログプラットフォームで toots を投稿し、フォーラム投稿を Fediverse 全体に発表する。
  • 埋め込まれた画像が自動的に PixelFed にアップロードされ、そこから提供される（例えば Blender コミュニティにとって便利です）。
  • 日時ツールバーを使って、Fediverse 向けの完全な Mobilizon イベントを設定し、RSVP 機能を備える。
    • 双方向統合が可能で、イベント上の Mobilizon ディスカッションが実際に Discourse トピックとなります。
  • 特別なビデオ機能を備えた PeerTube トピックを作成し、投稿を PeerTube のコメントスレッドとする。
    • Owncast が AP サポートを追加した場合も同様です（この issue を参照）。
  • 公開されたトピックが自動的に Writefreely のブログ投稿とコメントスレッドになる。
  • ActivityPub サポートを介して、フォーラムの一部を Nextcloud のアプリとして埋め込む。
  • Funkwhale を通じてポッドキャスト機能を統合する（ポッドキャストサポートに関する最近の video を参照）。
  • 開発中のプロフェッショナルソーシャルネットワーク（LinkedIn 風のロールデックス）である Flockingbird からプロフィール情報を取得する。

ActivityPub Watchlist 上で常に増加しているアプリの数を見つめ、あなたの想像力に任せてください :smiley:

結果

技術的な障壁や障害を一時忘れ、これが Discourse という製品、あるいは「単なる製品」でなくなった Discourse にとって何を意味するかを考えてみましょう。つまり：Discourse は分散型コミュニティの構造そのものとなったのです。

フォーラムスタッフはもはや単なるスタッフではありません。彼らはコミュニティ構築に対してはるかに広い視点を持つようになります。コミュニティもコミュニティコンテンツも、Discourse の構造全体に存在します。スタッフは他の Discourse インスタンスを積極的に監視し、他のスタッフにアプローチしてパートナーシップを結び、コミュニティの組織化とコンテンツを最も興味深くするために、それらを切り貼りする興味深いフェデレーションデザインを作成します。

コミュニティメンバー自身も、はるかに良いサービスを受けることになります。より興味深いコンテンツが彼らのフォーラム「ポータル」に流れ込み、フォーラムはローカルなものだけだった場合よりも活発になります。コミュニティメンバーは、構造全体に広がる他のフォーラムインスタンスのメンバーを発見し、対話できるようになります。実際、コミュニティの境界は取り除かれました：コミュニティに境界はないのです。

「いいね！」 17
Humanetech category layout
Forum owners, how do you "fight" Facebook groups?
ActivityPub Support: Phase 1 RFC
Using Discourse as a social media platform
Federation support for Discourse
ActivityPub Support: Phase 1 RFC
ActivityPub Support: Phase 1 RFC
2

正直なところ、私は軽く目を通しただけですが、このファブリックのアイデアでどのような問題を解決しようとしているのでしょうか？

「いいね！」 2
3

まず、ブレインストーミングの入力として、制限なしにあらゆる可能性を描き出しました。しかし、個人的には改善を望む点が二つあります。一つはコミュニティメンバーとしての視点、もう一つはコミュニティファシリテーター（現在5つのフォーラムでスタッフとして活動し、時折クロス投稿も行っています）としての視点です。

  • コミュニティメンバーとして、現在15〜20のDiscourseフォーラムにアカウントを持っています。アカウント（いくつかは忘れ去られているものも含む）とパスワードを管理し、人気のあるサイトを carousel のように巡回して、サイトごとに確認しています。私の関心分野に基づいて、これらすべてのフォーラムには多くの重複するコンテンツ領域が存在します。そのため、もし私が最も好きな分野に関するあなたの素晴らしいフォーラムに参加するように頼まれても、まだ非常にためらうでしょう。さらに別のアカウントを作成することに抵抗があります。

  • コミュニティファシリテーターとして、同様の関連する問題を抱えています。私のコミュニティが小さくても、類似または部分的に重複する主題に関するコンテンツを持つ他のコミュニティに参加すると判断するかもしれません。あるいはその逆もあり得ます。あるいは、その素晴らしい他のコミュニティの存在さえ知らないかもしれません（私のようなコミュニティファシリテーターは存在を知っていても、メンバーに知らせるためにピン留めされたトピックを設けるかどうかは別問題です）。

フェデレーションのサポートが整えば、コミュニティファシリテーター同士のパートナーシップを通じて協力し、連続する視聴者層に向けたフォーラムの編成を設計することで、互いの強みを活かすというwin-winが実現します。具体的には以下のような利点があります。

  • フェデレーション対象の最も適切なソースを選択することで、より高品質なコンテンツを提供できる。
  • フェデレーション全体の集合体であるより大きなメンバーベースにより、有意義な議論ができる人が増える。
  • フェデレーションに参加するすべてのフォーラムインスタンスでの活動レベルが向上し、リピーターを維持しやすくなる。

これらは、あらゆる成功するコミュニティにとって不可欠な三つの要素です。品質、規模、活動性 :slight_smile:

「いいね！」 8
ActivityPub Support: Phase 1 RFC
5

同意します。これは本当に厄介な問題です。私はこの問題を、DiscourseコミュニティのRSSフィードを追加し、内蔵の週次ダイジェストメールを有効にすることで解決しています。

「いいね！」 5
6

最近、ニール・ファーガソンの『The Square and the Tower』を読み終えました。この書は、世界史におけるソーシャル・ネットワーク（個人間の隠れた非公式な社会的つながり）の影響について論じたものです。完璧な本ではありませんが、「コミュニティには境界がない」というあなたの見解を一貫して裏付けています。分散型ネットワークは、階層構造よりも回復力に優れ、イノベーションを促進し、平等主義的です。Discourse は自身を「ゼロからの再構築、現代のインターネットディスカッションフォーラムが、スマートフォン、タブレット、Facebook、Twitter が无处不在の今日の世界でどうあるべきかを再考しようとする試み」と定義しています。Discourse の野心が、一時的に最新かつ最高のフォーラムソフトウェアに留まることではないならば、ActivityPub の統合が、Facebook、Google、Twitter などを真剣に挑战し、オンライン・コミュニティの可能性に関する期待を覆す明確な道です。

「いいね！」 8
7

@aschrijver もちろんです、個人的にはアイデアや思考の方向性が大好きです。

これはかなり「容易に」実現可能に見えます。アカウント部分については、メインの Discourse を SSO プロバイダーとして機能させることができます。他の Discourse フォーラムは、このシステムに参加するだけで中央集権的なユーザーベースを構築できます。つまり、ユーザー名は、そのシステムを利用しているすべての Discourse で予約されることになります。理想的には、フォーラムの管理者や所有者はフォーラム作成時に参加することになりますが、後から参加することも可能です。その場合、「単に」その時点で重複して表示されるユーザー名を解決する必要があります。管理者は、システム上で既に使用されているユーザー名の場合、利用者にユーザー名の変更を促す必要があります。

パートナーシップ部分については、Matterbridge および/または Discourse API を使用するプラグインであれば、すべてを実装できるはずです。ここではいくつかのプラグイン開発と改善が必要になります。

あるいは、新しいフォーラムに対して「マルチサイト」アプローチの解決策もあるかもしれません。1 つのメイン Discourse（上記のアイデアと同じ SSO プロバイダーでも構いません）にカテゴリを作成し、1 カテゴリ＝1 つの「フォーラム」とします。いくつかの設定を調整することで、特定のユーザーをそのカテゴリ内に「ロック」し、メインの「カテゴリ」への言及を削除して、異なる「フォーラム」として再定義することが可能です。サブカテゴリを有効にすることで、各フォーラムには依然として 2 段階のカテゴリ階層が維持されます。調整すべき点はありますが、これにより共通のユーザーベースとフォーラム間でのプライベートメッセージング（同じ Discourse 上にいるため！）が即座に可能になります。

この 2 つのアプローチを組み合わせることもできます。メインの Discourse にホストされたフォーラムと、外部のフォーラムをリンクさせる方法です。ビジョンを現実のものにすることは、比較的容易に可能だと考えます。もし関心があれば、私も協力する用意があります（ただし、何らかのサポートは必要ですが）。このプロジェクトに使用できるよう、ドメイン webforum.link を登録しました。

補足（以前の投稿を確認した後）：ActivityPub は「オープン」なものです。上記のアイデアは、Discourse フォーラムに限定される「クローズド」で制限の多いアプローチになります。参加の容易さという点でも、ActivityPub ほど簡単にはならないでしょう。

「いいね！」 3
8

@aschrijver さん、ActivityPub Support: Phase 1 RFC - #50 by Mevo でのやり取りに続き、またこちら（より適切なトピック）でも話を進めたいと思います。

最近、非常に興味深い事例を見つけました。いくつかのグループが「Openbazaar」という無料かつ分散型のマーケットプレイスを作成しました。そのコンセプトは、完全にオープンで、誰でも制限や検閲の恐れなく商品を出品できる仕組みを作ろうというものです。決済には暗号通貨を使用し、売り手のレビュー機能や、問題が生じた取引を仲裁するモデレーター制度も備えています。取引手数料は完全無料です（もしモデレーターが介入する必要がある場合のみ、ごく少額の手数料が発生します）。

理論上、これは素晴らしいアイデアだと言えます。しかし、実際にはあまり普及しませんでした。一方、Ebay や Amazon は、取引のたびに相当な手数料を徴収していますが、非常に成功しています。

つまり、誰かが管理し、金銭的な利益を得る動機を持っており、その目標に向けて投資を行う仕組みの方が、無料でオープンで高尚なアイデアよりもうまく機能する傾向があるということです。悲しいことですが、現実世界ではこれが起こっているようです。

Mastodon は Facebook や Twitter を追い抜くでしょうか？それとも、いつか追い抜くでしょうか？ユーザーは Facebook の広告の数に飽き飽きしているようには見えません。

いずれにせよ、あなたのフェデレーションに関する見解では、この側面が考慮されていないように思われます。ですので、参考までにお伝えします（少なくとも知っておいてほしいです）。フェデレーション機能を提供したり、パートナーシップを組んだりすることが悪いアイデアだということではありません。しかし、「完全なフェデレーション」に走ると、ソフトウェアを運営する魅力が失われる可能性があります。それは単なる「ノード」になり、もはや自分がコントロールできないものになってしまうからです。少なくとも、これはかなり異なるアプローチです。

「いいね！」 1
9

プラットフォームの利用の進展は直線的ではありません。Signal の例を挙げると、スノーデンが「Silent か Signal を使え」と述べたことでアプリは発展しましたが、それでもニッチな存在にとどまりました。一方、GAFAM が不適切なコミュニケーションを行い、イーロン・マスクが「Signal を使え」と発言すると、ユーザーは同期して同じ基準をベンチマークし、その結果、利用者のニーズに応えるランディングアプリが選ばれ、数十万人のユーザーが流入しました。

最近、メディアの注目度がそれほど高くないまま、一部のユーザーがTwitterやFacebookを離れるケースもあります。彼らのフィードで反応の主な発信源だったアカウントが削除されたことが理由です。

ソーシャルメディア上のシステムが混沌とするほど、ユーザーが同期して大規模に「アプリ1をアンインストールし、アプリ2をインストールする」という行動を取る確率は高まります。

「いいね！」 1
10

シグナルの例が本当に比較対象として適切かどうかは疑問です。ここでは明確な新機能があり、利用する理由も示されています。「暗号化された通信を使って、あなたの発言を私密に保ち、誰にも聞かれないようにしましょう」というものです。暗号化されていない状態から暗号化された状態への移行です。

しかし、「閉鎖的」かつ「孤立した」プラットフォームから「オープンな」プラットフォームへ移行する場合、「完全なフェデレーション」を考えると、それは本当にユーザーに何かをもたらすのでしょうか？本当に彼らにとって機能の追加になるのでしょうか？いくつかのコミュニティに参加している様子を見て、それらを集約できる点を挙げて「そうだ」と言う人もいるかもしれません（私も、複数のコミュニティにログインする負担がどれほど大きいか理解しています）。一方で、もしすべてのユーザーが一つの「閉鎖的」で支配的なコミュニティに移行した場合、彼らにとって状況はほとんど同じになるでしょう。彼らがその違いに気づくか、「オープンさ」を望むかどうかはわかりません。

人々はコンテンツややり取りなどを気にしますが、技術的な仕組みや誰がそれを制御していることは重要でしょうか？「フェデレーション」への移行は、コミュニティにとってある意味で「競争から共有」への転換です。彼らは互いに友人であり、ユーザーを一方から他方へ送ることに問題ないかもしれませんが、閉鎖的な状態では依然として競争関係にあります。

2 点目の指摘は興味深いですね。「フェデレーション」によってBAN、アカウント削除、検閲が防止されるでしょうか？これが人々にとっての追加の「機能」になり得るかもしれません。現在のActivityPubでは、個々のサイトからBANされることはあっても、フェデレーションの残りの部分への投稿は継続できるはずです（ただし、登録したサイト自体があなたをBANしていない限り）。@aschrijver さん、その仕組みについてご存知ですか？（私はActivityPubに詳しくありません）。あなたはフェデレーションレベルで登録しているのでしょうか、それともフェデレーションに属する特定のサイトに登録しているのでしょうか？フェデレーションレベルでBANされることはあるのでしょうか？それともそれは不可能なのでしょうか（不可能であるはずでしょうか）？

@jibe-b さん、質問の本質はアプリ1からアプリ2への移行ではなく、個別の閉鎖的なアプリとフェデレーションされたもの（つまりオープンなもの）との比較でした。強力な表現の自由ポリシーを持ち、人をBANしない閉鎖的な個別アプリも存在し得ます（ hindsight として言うのは簡単ですが、「リアクション提供者」はこれを予見できたはずです）。完全に分散化し、誰からもBAN機能を奪うことで、BANのない環境を保証することは可能です。@aschrijver さんの当初の目的が検閲防止だったとは思いませんが。

「いいね！」 1
11

（簡潔にするため抜粋を引用しました）。このレストランの比喩はここでは破綻しています。まるで同時に 2 つのテーブルに座っているようなもので、より多くの人々と祝うことができる大きな「集約型」レストランがあるようなものです。あなたの言うことは真実かもしれませんが、それは実装の仕方にも完全に依存します。

ActivityPub RFC トピック や @hellekin の ユースケース では個人が完全に制御権を持つとされていますが、上記の説明ではコミュニティの構造を完全にコミュニティスタッフの手に委ねています。彼らは他のコミュニティとパートナーシップを結び、相互の合意に基づいてコミュニティの一部のみを共有できる可能性があります。

そうすることで、Discourse（企業）にとっても、自らのアイデンティティとメンバー基盤を築くために多大な努力を払ってきたコミュニティマネージャーにとっても、より利益になると思ったのです。つまり、これはより「ビジネスケース」に近いものです。したがって、スタッフは依然として完全な制御権を持ち、また構成されるコミュニティ組織を包括的で直感的に保つ責任も負います。彼らは「コミュニティの織物の編集者」なのです。

もし Discourse ユーザーに空の「ポータル」を至る所のフォーラムコンテンツで埋める完全な自由を許せば、全く異なるコミュニティのダイナミクスが生まれるでしょう。このユースケースには特定の事例において価値がありますが、「スタッフが制御を維持する」ユースケースとは全く別のものです。もちろん、その間のあらゆるグレーゾーンも可能です。

はい、それらについては知っていますし、分散型マーケットプレイスとしての OpenBazaar のアイデアは大好きですが、それを試すのを阻んだのは暗号通貨です。それは信頼の問題です。多くの人々にとってそれが障壁になったかもしれません。それ以外に、確立された Big Tech の巨大なネットワーク効果が、新規参入者にとって参入を非常に難しくさせています。彼らは新しいサービスを立ち上げ、毎日数百万人の訪問者があるサイトで広告を出し、ついに普及するまで巨額の赤字を抱えて運営できるからです。

はい、それに同意します。そのため私は「完全な自由」ではなく、上記のように説明した「スタッフが制御を維持する」ユースケースに焦点を当てました。ActivityPub のサポートは、コミュニティマネージャー、つまり有料顧客である Discourse という製品にとっての USP（独自の売り）を追加するものです。まあ、クラウドホストされたサブスクリプションを選択した場合の話ですが。

その点で、Discourse（企業）は、異なるコミュニティのコミュニティマネージャーが自らの（そして暗黙的に互いの）コミュニティを豊かにするために積極的にパートナーシップや協力を模索する、発見やマッチングサービスなどの付加価値サービスを提供することで、サブスクリプションをより魅力的にできるかもしれません。このサービスは誰でもアクセス可能にするか、有料プランの顧客のみを対象とするかです。

彼らがそう望むべきでしょうか？それが目標であるべき理由は何ですか？ActivityPub というプロトコルは、多くの異なるドメインの 多くの異なるアプリケーション があらゆるレベルで相互運用することを可能にします。各プロジェクト/アプリ/製品は独自の目標を追求し、商用ソフトウェアの場合は独自の USP を追求します。

最初の部分が重要です。フェデレーションは慎重に選びましょう。製品としてのアイデンティティをすべて失うことになるのであれば、完全なフェデレーションは決して目標であってはなりません。

まず、「フェデレーション」と「フェディバース」には違いがあります。ActivityPub を使用してフェデレーションを構築する場合、どのように機能させるか自由に構築できます。フェディバースとの統合を目的として構築する場合、物事がどのように機能するかについての確立された事実上の標準がいくつかあります。ユーザーレベルでのフェディバース全体の BAN は不可能であり、特定のインスタンスへの BAN は、各インスタンスのモデレーターによる決定に基づいており、ブロックリストと許可リストで設定されます。これらのリストは（広告ブロッカーリストのように）共有されることが多く、特定のインスタンスがフェディバース全体で完全にブロックされる（「彼らはフェディバースの端へ追いやられる」）結果につながる可能性があります。

この概念を説明する良い動画があります：

フォーラムと同様に、フェディバース内の各フェデレーションされたインスタンスはモデレーションされています。そして、それは良いことだと思います。あなた自身でモデレーションのないフォーラム/サーバーインスタンスを立ち上げて、何でもありにできるという完全な自由は依然として残っています。他の人々は、それに基づいてあなたをブロックする自由を持っています。

「いいね！」 4
12

コミュニティ管理の委任

これは自由なブレインストーミングであり、ちょうどこのトピック ボランティア・コミュニティ・マネージャーを募集しています :mega: を見たので、ふと思いました：

—> もしコミュニティ管理がフェデレーション（連携）されていたらどうなるでしょう？

あなたが新しく設置された Discourse フォーラムのコミュニティ・マネージャーで、管理画面やコミュニティ構築の手法については完全な初心者だとしましょう。ある期間、経験豊富なコミュニティ・マネージャーを招いてアドバイスを受け、指導をしてもらうことができればどうでしょうか？

「そんなの、単にそのフォーラムにスタッフアカウントを作成すればいいだけじゃないか……フェデレーションなんて不要だ！」とおっしゃるかもしれません。その通りです。しかし、視点を転換して、もう少し面白く考えてみましょう。私が Discourse やコミュニティ管理のスキルを、ボランティアとして、あるいはプロフェッショナル（有償）として提供したいとしたらどうでしょうか？

私は「顧客ポートフォリオ」の中で、できるだけ多くのコミュニティを効率的に管理したいと考えます。これにより、三方良しの効果が生まれます：

  • 新しいコミュニティ・マネージャーは、オンボーディングサービスを通じて、より迅速にスタートダッシュを切ることができます。
  • コミュニティ・マネージャーは、自らのコミュニティを超えて、スキルをより広く活用できるようになります。
  • 上記 2 点により、Discourse の製品に新たな USP（独自の売り）が加わることになります。

では、これは具体的にどのような形になるでしょうか？私はわかりません……多くの可能性があります。いくつかの案を挙げます。いずれの案においても、委任された管理者 は、自身のフォーラムポータルからフェデレーションを通じて、複数のコミュニティを管理します：

  • 委任された管理者は、フォーラムの設定を変更したり、プラグイン・コンポーネント・CSS をインストールしたりできますが、これらは実際の管理者が承認してから有効になります。
  • 委任された管理者は、スタッフ専用カテゴリやグループにアクセスし、アドバイスを与えるためにディスカッションに参加できます。
  • 委任された管理者は、フォーラムで報告されたフラグ（通報）を処理します。この場合、フラグが付けられたトピックのみがポータルにフェデレーションされます。
  • 委任された管理者は、コミュニティの状況を理解しているため、他のコミュニティとのパートナーシップの調整やコンテンツの共有を支援します。

上記を踏まえて、以下も考慮してください：

これも付加価値サービスとなり、上記と組み合わせることも可能です。関係するすべての当事者は、委任された管理者が一定の水準で優れたコミュニティ・マネージャーとして審査されることに興味を持っています。Discourse（企業）は、（有料？）サブスクリプションに加入している場合に限り、人を委任された管理者として認めるようにするかもしれません。Discourse またはそのパートナーは、コミュニティ管理のコースを提供し、修了した際に @codinghorror の承認スタンプが押された認定証を授与するかもしれません。

さて……このアイデアが気に入ったかどうかは別として、私にとっては楽しいブレインストーミングのセッションでした、哈哈哈 :grinning_face_with_smiling_eyes:
もしかしたら、もっと良くできるかもしれませんね？

追記：

Discourse 自体もこのサービスを利用するでしょう。有料サブスクリプションを開始した当初、Discourse チームのメンバー 1 名が当フォーラムのスタッフの一員として、同様のサポートを提供していました。これにより、彼らは自身のリモート「コックピット」からその作業を行うか、あるいはそれを委任することができます。

コミュニティの一部を共有することに関連するもう一つの点として……私がメタフォーラムに特定のサポートを求めてトピックを投稿した際、そのトピックが非公開にされ（時には機密情報が含まれていたため）、Discourse チームによって「サポートチケット」として処理されたことが何度かあります。フェデレーションがあれば、メタのサポート部分を自らのフォーラムに統合できるかもしれません。

「いいね！」 4
13

（私のフォーマット調整）。@JE-FF さん、その定義は本当に素晴らしいですね。「コミュニティに境界はない」「ディスコースをファブリックとして捉える」という革新的なアプローチに完璧に合致します。ただし、@Mevo さんにもお伝えした通り、Discourse が本当に Big Tech のソーシャルメディアに挑戦すべきかどうかは疑問です。彼らが望めば可能ですが、それは必須ではありません。Discourse はそれ自体で非常に成功しており、現在は異なるポジションにいます。つまり、マルチテナント型 SaaS、すなわち「独立したコミュニティフォーラムのクラウド」としてです。とはいえ、コミュニティの概念をテナントの境界を超えて拡張することで、フォーラム市場およびソーシャルメディア市場の競合他社に対して、より有利な立場に立てるかもしれません。

「いいね！」 2
14

@aschrijver さん、本当にありがとうございます。非常に明確で、正直なところ、あなたが述べたことにほぼ完全に同意します。私は、あなたが提案しているものが「完全かつ完全にオープンなフェデレーション」を究極の目標とする「足がかり」であるという考えをいくつか持ったままメッセージを書きました。しかし今では、それがどこから来たのかも定かではなく、あなた自身はそんなことを言ったこともないかもしれません。これは私自身の誤解（あるいは捏造された考え）か、他の人が言ったことを混同していたのかもしれません。

ActivityPub が可能にするすべてを、あなたが望む方法で選択できるという点において、これは私にとって素晴らしいことに聞こえます。 あなたがおっしゃる通り、ActivityPub とフェデバースの間には混乱があるのかもしれません（ActivityPub に関する別のトピックで すでに説明されています）。

個人的には、あなたが持ち込んだすべてのアイデアを気に入っています。フェデレーションされた「コミュニティ管理」の面では、そのようにしてモデレーターにアクセスできることも非常に有用でしょう。コミュニティが熱を帯びたときや、例えばより多くのモデレーターを必要とする特別なイベントがあるときに、一時的に利用可能なモデレーターです（これらすべては、あなたの頭の中では「コミュニティ管理」に含まれていたかもしれません。フラグについて話されましたが、「モデレーター」や「コミュニティマネージャー」と同様に、より多くの「管理者」タイプの人々にアクセスすることもできます。これらタスクを別物として定義する場合です）。

前述の通り、これらすべてはプラグインやサイドサイトを通じて「別側面」で実現可能です（コミュニティで直接働く人材を紹介・提案する「フリーランス」のサイドサイトが存在するかもしれません）。ActivityPub のおかげで、それぞれが独自のプラットフォームを持ち、リモートからすべてを管理・集約できるほど完璧ではありませんが、それでも素晴らしい第一歩となるでしょう。

これらアイデアの一部を Discourse チームが Discourse に直接実装するかどうかは、すべてそのチームの判断にかかっています。

「いいね！」 4
15

ここには同意できません。私は、マルチサイト設定を活用して、Discourse インスタンスのグループ所有を促進してきました。これにより、特定の密接なグループが独自のスタッフとなりつつ、より大きなコミュニティとの直接的なつながりを保つことが可能になります。私の見解では、コミュニティの境界を柔軟に扱うことは、補助性の原則（意思決定は可能な限り実践に近いレベルで行われるべきという考え方）を活用することで、コミュニティに力を与えるものです。

16

まず、彼が言ったことを「スタッフの管理がなければユーザーは乱れる」と解釈しているようですが、IMO 彼が言ったのはそのことではありません。第二に、彼は「全く異なるコミュニティのダイナミクス」について言及しただけで、それが良いことか悪いことかの判断はしていません。実際、あなたは「異なる」ものとしてそれを良いことだと述べているため、彼の意見に同意しているように見えます。

しかし、これが議論の中心ではありませんでした。この「管理」や、ユーザーに問題があることについての話ではありません。

17

はい、主に提供されるオプションの広範な範囲と、特定のシナリオに合わせて調整する完全な柔軟性について説明することでした。ActivityPub というボールにだけ目を向けると、フェデレーション機能の実装者に完全な「ボールコントロール」が与えられます。実装されたユースケースはすべて、製品開発の一部として意図的に設計されたものであると仮定すれば、同等に正当なものです。

@hellekin のケースは、確かに完全な自由の一端には属していないようですが、さらに詳しく掘り下げることは興味深いでしょう。@hellekin は私よりも多くのフォーラムを、創造的な方法で取り扱っています。これは、個々の ActivityPub ソフトウェアチームがフォーラム内の自らのセクションを管理している SocialHub フォーラムで確認できます。これらのチームは、しばしば独自に別の独立したフォーラムも持っています（例：Mastodon の場合）。彼らが自社のソフトウェアに組み込むカスタムフェデレーション拡張機能について、AP コミュニティを常に情報共有するためには、「二重の作業」を行うよう奨励される必要があります。加えて、SocialHub には、衛星フォーラムと見なせるフォーラムも存在します。

「いいね！」 3
18

Discourseフォーラムにまた一つ登録しました。他のフォーラムのトピックへの有益なヒント（コピー＆ペースト）を提供し、サポートするためです。管理すべきDiscourseユーザーアカウントがまた一つ増えました。

対象のフォーラムはFedeproxyです。これは新しいActivityPubプロジェクトで、コードフォージ（GitHub、GitLab、Giteaなどのリポジトリ）同士を同期させることを目指しています。Forgefedプロトコルの実装になる可能性もあり、ここで言及する理由は以下の2点です：

  1. これはActivityPubフェデレーションから大きく恩恵を受けられる、全く異なるビジネスドメインのさらなる例です。
  2. Discourseにフェデレーション対応があれば、このフォーラムの#developmentカテゴリを、SocialHubの#softwareサブカテゴリと双方向で同期でき、2つのフォーラムを別々に操作したり議論を重複させたりする必要がなくなります。

更新：

Fedeproxyフォーラムでは、あるユーザー（余計な投稿を残すためだけにここでサインアップしたくないと言っていた方ですが）が、コミュニティ向けの興味深いLinked Dataオントロジーを指摘してくれました。それはSIOC Core Ontology Specificationで、SIOCプロジェクトは「Semantically-Interlinked Online Communities（意味的にリンクされたオンラインコミュニティ）」の略です。このオントロジーは、Linked Dataにおいて以下の意味を定義しています：


semantically-interlinked-online-community-ontology
semantically-interlinked-online-community-ontology600×379 30.1 KB

ここで言及したのは、ビジネスドメインや語彙についての考え方を浮き彫りにしており、ブレインストーミングのインスピレーションになるかもしれないからです :slight_smile:

（追伸：SIOC仕様に「Semantic Web」という用語が出てきても惑わされないでください。これはそれとは関係ありません。あまりにも複雑すぎます。むしろ、特定のドメインを定義するための閉じたLinked Data語彙を探しているのです。）

更新2：

今日、Discourseと同様のドメインにある素晴らしいプロジェクトを見つけ、そこで「Community has no boundary（コミュニティに境界はない）」という議論を開始しました：

PubPubはKnowledge Futures Groupの一部で、彼らはOpen Distributed Knowledge GraphプロジェクトであるUnderlayも開発しています（これは私がDiscourseフォーラムからの知識集約について考えていたアイデアに近いものです）。

更新3：

コミュニティに関する議論はDiscourse単独よりもはるかに広範であることを実感しました。コミュニティの概念は私たちの社会全体で普遍的だからです。Fediverseについては、コミュニティドメインの標準化と、それに基づいたActivityPub拡張のモデル化について議論を開始しました：

「いいね！」 7
19

ActivityPubは良いアイデアですが、それを第一級の機能として実装したばかりのソフトウェアでも、仕様のいくつかの穴を修正する必要があります。そのため、私たちにとっては様子を見るのが妥当です。

また、特定のグループが非常に熱心に関心を持っているものであれば、プラグインとして完全に実現可能です。

「いいね！」 13
20

認証情報を追加するだけで、タグ/カテゴリ/メンションを通じてクロスポストできるよう、chat-integration アプリにそのような統合がプルリクエストとして取り込まれることを願っています。ありがとう！

「いいね！」 7
21

@codinghorror さん、ありがとうございます。確かに ActivityPub 仕様に抜けがあります。しかし、それらはほぼ意図的に残されたものです。仕様作成者たちは、包括的で巨大かつ複雑な技術標準を作りたくなかったためです。さらに、当時の時点では仕様がどのように進化するか予測できなかったためでもあります。そのため、参考実装を待つことにしました（これには Mastodon が仕様内のクライアントからサーバーへの部分ではなく、独自のカスタムクライアント API を使用したなど、いくつかの欠点もありましたが、Mastodon は実際に使用する 便利な名前空間拡張 を定義しました）。

現在、これらの抜けの多くは他のオープン標準によって埋められています（まだ埋めるべきものもいくつかあります）。サーバー間フェデレーションには HTTP シグネチャが、（あまり使われていませんが）JSON-LD シグネチャが、フェデレーションされたユーザーメンションには Webfinger が使用されています。クライアントからサーバーへの通信には OAuth2 クライアント資格情報が使用され、サーバーの機能を伝えるために事実上の標準である NodeInfo / NodeInfo2 があります。

このスレッドで議論されている多くのこと（おそらく大多数）は、プラグインと素晴らしい Discourse API を使用して実装可能だと私も同意します。@sunjam さんがおっしゃる通り、もし誰かがその分野に挑戦すれば、それは本当に素晴らしいことになるでしょう :slight_smile:

このブレインストーミングに由来し、私は SocialHub フォーラムでより一般的な議論を開始しましたので、参照してください：

更新 2021/03/07：SocialHub のコミュニティ語彙の AP 拡張を作成するトピックにおいて、Discourse がコミュニティモデルにどのように適合するかについてさらに詳しく説明しました。私の投稿をご覧ください：

「いいね！」 7