- フェディバース(Fediverse)の概念と背景
- 中央集権型ソーシャルメディア(X(旧Twitter)、Instagram など)に疲れたユーザーのための代替手段。
- データプライバシー、アルゴリズム推薦、絶え間ない広告の問題を解消するために登場した分散型ネットワーク。
- フェディバースの構造と動作原理
- 構成: 1つの巨大なプラットフォームではなく、相互に会話できる独立したサーバー(インスタンス)のネットワーク。
- プロトコル: すべてのインスタンスが ActivityPub という共通プロトコルを使って情報を交換する。
- メールに似たたとえ: Gmail ユーザーが Naverメールのユーザーとやり取りできるように、Mastodon ユーザーは Misskey や PeerTube のユーザーと通信できる。
- ユーザーIDと主要プラットフォーム
- ユーザーID形式: @ユーザー名@インスタンス.ドメイン(例: @honggildong@mastodon.social)
- 主要プラットフォームとインスタンス:
- Mastodon: X(旧Twitter)に似たマイクロブログプラットフォーム
- 例: mastodon.social, uri.life(韓国中心)
- 特徴: 500文字制限、ハッシュタグ、コンテンツ警告機能
- Misskey: 日本で開発された高度にカスタマイズ可能なマイクロブログプラットフォーム
- 例: misskey.io, Stella(韓国中心)
- 特徴: リアクション、ゲーム、チャットなど多様な機能
- Pixelfed: Instagram に似た画像共有プラットフォーム
- 例: pixelfed.social, Chueok:写真(韓国中心)
- 特徴: ストーリー、フィルター、コンテンツ発見機能
- PeerTube: YouTube に似た動画ホスティングプラットフォーム(P2Pストリーミング)
- WriteFreely: ミニマルなブログプラットフォーム(Markdown 対応)
- Lemmy: Reddit に似たリンクアグリゲーターおよびディスカッションプラットフォーム
- プラットフォーム vs. インスタンス
- プラットフォーム: Mastodon、Misskey、Pixelfed などソフトウェアそのものを意味し、オープンソースとして誰でもインストール可能。
- インスタンス: そのソフトウェアを実行する個別サーバー。たとえば、mastodon.social と uri.life はどちらも Mastodon プラットフォームを使う別個のインスタンス。
- 一部のサービス(例: Meta の Threads)はプラットフォームとインスタンスが同一だが、多くのフェディバースは複数のインスタンスで構成される。
- フェディバースの魅力ポイント
- 分散性: 特定企業がすべてのデータを統制しない。
- データ主権: ユーザーが自分のデータに対してより多くのコントロールを持てる。
- 検閲耐性: 1つのインスタンスが遮断されても、他のインスタンスへ容易に移動できる。
- コミュニティ中心: 各インスタンスが特定の関心分野や地域コミュニティを基盤に形成される。
- 多様性: 多くのプラットフォームやインスタンスから選べる幅が広い。
- フェディバースへの参加方法
- 自分の関心分野や地域に合うインスタンスを選んでアカウントを作成する。
- 韓国のユーザーなら、韓国語環境をサポートする uri.life(Mastodon)や Stella(Misskey)のようなインスタンスがおすすめ。
- ソフトウェアエンジニア向けの Hackers' Pub など、特定コミュニティへの参加も可能。
- ActivityPub と開発者ガイド
- ActivityPub プロトコル:
- W3C 勧告標準であり、ActivityStreams 2.0 データ形式を基盤とする。
- 異なるサーバー間で情報を交換する「共通言語」の役割を果たす。
- 中核概念:
- アクター(actor): ユーザーやグループなどの行為主体(固有URL、inbox、outbox を含む)
- アクティビティ(activity): 投稿作成、いいね、フォローなどの行為
- オブジェクト(object): テキスト、画像、動画などの共有コンテンツ
- 実際の動作例: 投稿を作成すると、たとえば 2025-02-21T14:30:00Z に投稿が生成され、Create(Note) アクティビティに変換されてフォロワーへ配信される。Follow アクティビティなどによって相互作用が行われる。
- 開発のヒント:
- アクター実装、HTTP エンドポイント(受信箱/送信箱)の設定、HTTP 署名と認証、データベース保存、連合ポリシー設定などが必要。
- 既存実装(Mastodon、Misskey)や Fedify のようなフレームワークの活用を推奨。
- WebFinger プロトコル: @ユーザー名@インスタンス 形式の ID を実際の ActivityPub アクターURLへ変換する方法を提供する。
- フェディバースの課題と今後の展望
- 課題:
- スケーラビリティ: 膨大な数のサーバー間で効率的な通信処理が必要。
- モデレーション: 各インスタンスの独自ルールにより、一貫性が欠ける可能性。
- コンテンツ発見: 中央集権型プラットフォームより新しいユーザーやコンテンツを見つけにくい場合がある。
- ユーザー体験: 一部プラットフォームでは UI/UX の改善が必要。
- 今後の展望:
- Threads のような主要サービスによる ActivityPub 採用で、フェディバースの未来は明るく見える。
- 開発者とユーザーの参加増加により、健全で多様なインターネット文化の形成に寄与する可能性。
- 結論
- フェディバースは中央集権型ソーシャルメディアの限界を克服し、ユーザーにデータ主権と多様性を提供する新しいオンライン生態系である。
- 開発者とユーザーの双方がこの分散型ネットワークに参加することで、より豊かで健全なインターネット文化を築いていける。
7件のコメント
意外と多くの人が知らない事実ですが、そこで言及されている「思い出:写真」インスタンスの運営者は私です。よろしくお願いします。 :)
ActivityPubプロトコルを実装すれば、誰でもインスタンスを作って参加し、情報をほかのインスタンスに送れるということですか?
そうだとすると、広告のばらまきにはかなり向いていそうに見えますね!
メールサーバーを自前で運用するなら、スパム対策も自分でやらなければならないのと同じ話です。
広告/スパムアカウントがサーバーを1つだけ立ててスパムをばらまくなら、サーバー管理者の立場ではそのサーバーだけ遮断すれば済みます。
とはいえ、連合は新しいものではないので放置されたサーバー(インスタンス)もかなりあり、こうしたサーバーを経由して複数のサーバーの複数ユーザーにスパムを送りつける
ctkpaarrという名前のスパムが乱立したことがあります。もちろん、対処は各サーバーがそれぞれ行うしかありませんでした。https://qiita.com/gnh1201/items/09f4081f84610db3a9d3
https://github.com/warpKaiba/kuroAntiSpam
https://github.com/Interstellar-Relay-Community/budae-jjigae
望まない広告はモデレーションで除外できます。
連合宇宙の各インスタンスにはそれぞれ行動規範があり、その行動規範に合わない不適切なインスタンス(スパムや広告、あるいは不適切な投稿)はモデレーションで除外できます。
Blueskyでは、ユーザーが自分でミュートリストを作成して共有したりもします。
なるほど、インスタンスごとにルールを定めて、受け入れるデータをフィルタリングする形で動作するんですね。
ご理解のとおりで間違いないと思います。実際、一部のインスタンスには暴力的またはサディスティックな内容、あるいはNSFW中心の投稿が流れるものもありますが、誰が見ても安全なSNS利用を妨げるようなインスタンスについては、タイムラインに流れないようモデレーションできます。
あわせて読むとよい記事
https://ja.news.hada.io/topic?id=1528
https://ja.news.hada.io/topic?id=10114
https://ja.news.hada.io/topic?id=9651