- オープンソースがソフトウェアインフラの標準になったように、ソーシャルアプリにも「オープンソーシャル」パラダイムが登場している
- AT Protocol は、ユーザーがソーシャルデータを直接所有・制御できるようにし、既存のソーシャルプラットフォームとは異なる概念を提示している
- ソーシャルデータはもはや特定のサービス内に閉じ込められず、ユーザー自身が管理する個人ストレージに保存される
- これにより、アプリ間でのデータ再利用やリミックスが可能になり、サービス終了時にもデータは消えずに存続する
- オープンソーシャルの普及によって、ユーザー主導のデータ所有権と柔軟な拡張性が中核的な価値として浮上すると見られる
序論: オープンソースの成功と新たな潮流
- オープンソースは過去に多くの抵抗があったにもかかわらず、今日では共通インフラの基盤として定着している
- 昔と違って、今ではオープンソースを選んでも問題視されず、重要なソフトウェア分野ではオープンソースがデフォルトとして根付いている
- 今、私たちはソーシャルアプリ分野で35年前のオープンソースに似た転換点に直面している
- 新しい流れである**「オープンソーシャル」**が登場し、Bluesky の AT Protocol は最も説得力のある実装だと評価されている
Web の基本構造と個人データ所有
- かつての Web では
alice.com、bob.com のような個人アドレスがあり、各ユーザーが自分だけの空間を所有し、その上に自由にコンテンツを載せていた
- ホスティングが気に入らなければ別の場所に移っても、アドレスはそのまま維持され、既存リンクも切れなかった
- そのためユーザーは特定のホスティング事業者に縛られず、事業者側は競争しなければならなかった
- つまり、Web の分散型設計のおかげでユーザーがデータを握り、事業者は単なる提供者という役割だった
現代のソーシャルネットワーク: データ所有権の喪失
- 今日では、人々は自分のサイトを運営するよりも、企業から与えられた
@alice、@bob のような ID を受け取り、ソーシャルメディアアプリに投稿するのが一般的になっている
- 投稿、コメント、いいねなどのデータは特定のソーシャル企業のデータベースに保存される
- こうした構造によって、検索、フィード、推薦、通知などの社会的な集約機能が生まれた
- しかしその反面、中核データが私たちの所有物ではなくなる副作用が生じている
- ユーザーは自分が作ったデータや関係性を自由に持ち出せない状況に置かれている
問題点: プラットフォームに閉じ込められたユーザー
- ユーザーが離れると、自分が築いたつながり全体を置いていかなければならない
- ホスティング事業者を簡単に変えられず、プラットフォームを離れるとつながりもデータも一緒に失う問題が発生する
- プラットフォームはそれを知っているため、ユーザーに**不利な変更（広告の乱発、アルゴリズムの歪み、機能削除など）**があっても耐えざるを得なくなる
- データをバックアップしたりエクスポートしたりしても、それは**社会的文脈を失った「死んだデータ」**にすぎず、他の場所で再び生かすのは難しい
オープンソーシャル: データ所有権とネットワークの回復
- オープンソーシャルでは、@alice.com のようなドメインベースのハンドルを通じて、ソーシャルデータの実質的な所有権をユーザーに与える
- 名前が
@alice.com のように自分が保有するドメインと結びつく
- ユーザーは**個人ストレージ（repository）**を通じて、自分が生成するあらゆるソーシャルデータを直接管理する
- 投稿、コメント、フォローのような活動は**個人ストレージ（repo）**に記録される
- ストレージは単純な Web サーバーで、JSON 形式の記録を保管する
- アドレスは
at://alice.com/... という形式で、相互にリンクできる
- AT Protocol ベースのストレージは DNS、HTTP、JSON の上で動作し、各データはハイパーリンクされた JSON 形式で保存される
- 技術を知らない人でもアプリ登録時に自動でストレージが作られ、データはアプリに関係なくユーザー所有のまま残る
- データはユーザーのストレージに所有されるため、サービス事業者が変わってもデータ所有権と接続性は維持される
オープンソーシャルアプリの構造と応用
- 各オープンソーシャルアプリはCMS のようにユーザーのソーシャルストレージの一部を管理し、アプリは今やユーザーのストレージに書き込み・読み出しを行うためのツールにすぎない
- たとえば Bluesky、Tangled、Leaflet など異なるアプリのデータが、1人のユーザーのストレージ内で共存することになる
- Bluesky に投稿すると自分のストレージに記録が残り、Tangled でプロジェクトにスターを付けると、それも自分のストレージに入る
- データ形式は衝突を防ぐため、名前空間（例: app.bsky.post、sh.tangled.star など）で区別される
- 時間が経つにつれて、自分のストレージは複数アプリから集まったデータの集合になる
データ開放がもたらすエコシステムの変化
- データがオープンに保存されるため、アプリ間統合、新サービス開発、相互データ参照、再利用、リミックスなどが容易になる
- アプリが終了してもデータはユーザーのストレージに残り、他のサービスで再活用可能だ
- 新しいアプリは既存ネットワークの関係性やデータを活用することで、「コールドスタート」（初期ネットワーク構築問題）を克服できる
- このデータは誰でも読めるため、他のアプリが取得してプロフィール画像を読み込んだり、既存のフォロー関係をそのまま活用したりできる
- アプリが閉鎖されてもデータはユーザーストレージに残り、他のアプリが再び取り出して利用できる
集約（aggregation）と技術的課題
- ユーザーのデータは各自のストレージに分散しているが、WebSocket サブスクリプションを通じてデータ変更イベントストリームを受け取り、ローカルデータベースに反映する
- 大規模リレー（中継サーバー）を通じてネットワーク全体のイベントを受信し、必要なイベントだけをフィルタリングする
- データレコードは暗号署名されており、信頼性と整合性を保証する
- たとえば Graze、Slices のようなインフラがオープンソーシャルの集約を支えている
集約機能はどう実現するのか?
- 各ユーザーのストレージは個別に存在するが、アプリはユーザーストレージから出てくるリアルタイムのイベントストリームを受け取り、自身のデータベースに記録する
- Bluesky のような中継サーバー（リレー）が全体ストリームを集めて配信し、アプリは関心のあるイベントだけを選んで保存する
- こうして蓄積したデータベースは、検索、フィード、推薦のような機能を高速に提供できる
- データレコードは暗号署名されており、信頼性と整合性を保証する: 中継を信頼しなくてもデータの真正性を検証できる
- Graze、Slices のようなインフラがオープンソーシャルの集約を支えている
大きな構図
- 過去の Web: ユーザーは自分のコンテンツとアドレスを握っていた
- 今日のソーシャルアプリ: 集約機能はあるが、データは企業所有のデータベース内に縛られている
- オープンソーシャル: 集約機能を維持しながらも、データはユーザーの手元に残る
- アプリは単なるユーザーデータを集めて見せるための窓へと変わる
- サービスがなくなってもデータは残り、別のアプリが新しい文脈で再表示できる
結論
- パーソナル Webの利点（データ所有、ホスティングの自由、リンク維持）と閉鎖型ソーシャルネットワークの強み（集約、拡張性）を組み合わせることが、オープンソーシャルの核心だ
- オープンソーシャルはユーザー主導のデータ所有権、アプリ間での自由なデータ移動性、サービス継続性を保証する
- オープンソースが「コードはユーザーのものであるべきだ」と主張したように、「データはユーザーのものであるべきだ」
- 閉鎖型プラットフォームでユーザーがデータと接続性を失う問題を解決する
- より多くのオープンソーシャル製品が登場すれば、アプリ間の境界が曖昧になり、データが自然に流通するエコシステムへと進化する
- 最終的には、ユーザーが実質的にデータとネットワークを制御できる未来が訪れる可能性がある
- 初期段階では少数の熱心な開発者とユーザーが牽引するだろうが、共有基盤が積み上がれば、いつかはオープンな方式が勝つ可能性が高い
- 技術的概念（分散化、連合化）を知らなくても、**実質的な利点（データ連携、容易な移行、継続性）**を体感できる
- オープンソーシャルは情熱的なコミュニティによる長期的な努力と累積効果によって徐々に拡大していくだろう
3件のコメント
Instagramも思い出を保存する場所であるのは確かですが、自由に抜け出すのは難しいようですね。
データを共有し、利用するという面では、ある程度は譲歩すべき部分もあるのではないかと思います。
カトク... ss
Hacker Newsの意見
AT ProtocolはBlueskyの仕組みなので、最初はActivityPubの企業版のようなものだと思っていたが、この記事を読んでみると、データが自分で選んだ「リポジトリ(repository)」に保存される方式がかなり気に入った。自分の一般的な原則にも合っていて、フィルタリングなどは書く側ではなく読む側で実行する方がよいと考えている。だから、自分が望むものをすべて自分のリポジトリに載せて、他の人がそれを読んで利用できる構造がよい。矢印がコメントが自分のリポジトリに入るようにも見えるが、これはアイデアを表現する中で生じた少しの不正確さのようだ。全体として非常にクールで分散化された構造だと感じる。とはいえ、実際にATで別のPDSを自前で運用しようとしてみると、かなりスムーズでよくパッケージ化されてはいるものの、いくつか前提条件があることが分かる:
矢印を2種類使ったせいで混乱させてしまったようだ。実線の矢印（@alice.comから下に伸びるもの）は所有権を表している。色分けのグルーピングと同じで、青はすべてAliceのものという意味だ。点線の矢印はレコード間のリンクで、<a href> と同じように、どのレコードでもどのリポジトリにあっても自由に接続できる。誰かが私の投稿にコメントすると、そのコメントはコメントした人のリポジトリに入り、元の投稿とのつながりが作られる。データモデルをこのように設計した理由は、インデックスする人が両方のレコードを持っていれば関係を簡単に復元できるようにするためだ。たとえばBobがAliceの投稿にコメントすると、BobのコメントはBobのリポジトリに、Aliceの投稿はAliceのリポジトリにある。私の投稿に誰かがコメントを書いた場合、そのコメントは常にその人のリポジトリに残る。他人のリポジトリにレコードを作成できない、というのが核心的な前提だ。
基本のPDSパッケージングはSSL処理の自動対応をサポートしているが、必須ではなく、開発者が簡単に適用できるようにしてあるだけだ。at:// URIは at://DID/... の形式で、人間が読めるハンドルはDNS TXTレコード（_atproto.roshangeorge.dev）を通じてDIDにマッピングされる。DIDはサーバーの場所を示す文書へリンクしているので、HTTPS/WSSルートもどこにでも置ける。また、自分の投稿へのいいねや返信なども、その行動をした人のリポジトリに入り、自分のリポジトリには入らない。この直感は正しかった。
ActivityPubの方が優れたプロトコルで、ATはただの安っぽい模倣だと思っていたが、この記事を見てATの方がずっと優れていると気づいた。核心は、複数のプログラムが同じアイデンティティを共有できる点だ。これは本当にすごい機能で、視野が一気に広がる体験だった。
ATProtoの説明はたいていデータ所有権に焦点を当てているが、実際にはデータ処理の面ではActivityPubの方が強力だ。ATProtoは世界全体を公開前提で見る構造なので、すべてのイベントが信頼されたグローバルなAppServerから見え、それを自分で判断しなければならない。そのためフィード生成やアクセス権限などをすべて信頼された仲介者に依存することになる。ActivityPubはむしろRSSやメールに近く、自分が購読したフィードだけを自分のサーバーが管理し、インボックスは自分がアクセス可能な投稿でそのまま構成される。BlueskyでTwitterのような「非公開いいね」が不可能なのもこのためだ。各AppViewがネットワーク内の全投稿のいいね数を直接追跡しなければならず、非常に面倒になる。長期的にはActivityPubの構造の方が有利だと思う。そして「複数のプログラムが同じアイデンティティを共有する」という部分は、実は初期のActivityPub設計にもあった。最も普及した初期実装が既存構造に合わせるため、その機能を削っただけだ。
AT対APの議論はあまりにも複雑だ。私たちのコミュニティでも何度も議論してきたので、参考になるスレッドを置いておく: https://github.com/bevyengine/bevy/discussions/18302
そういう点が刺さったのならうれしい。いつもAPと比較されるのはもどかしいが、そもそもスコープがまったく違う。
同じような視点を分散システムエンジニアの観点から扱った記事も面白いはずだ。 https://atproto.com/articles/atproto-for-distsys-engineers
ということは、中央集権的なアイデンティティサービスがあるという意味なのだろうか。
どの分散プロトコルが勝つかは気にしないが、ATProtocolは理論上はよさそうでも、実運用ではだんだんActivityPubの方が魅力的に感じられる。私はLemmyでよく活動しているが、かなり活発で面白い。
Mastodonとは違って、ATではインスタンスという概念自体が異なる。Blueskyのインフラ内にも複数のPDSがあり、構造的にも階層的に異なる動きをする（関連記事参照）。単一の支配的インスタンスと表現するのは適切ではない。もちろん企業がプロトコルを思い通りに左右する懸念は現実的だ。だが今のところはよい管理者として振る舞ってきたと評価できる。エコシステムが成長すれば徐々に解決される問題だと思う。そして、Blueskyがサービスを閉じて移行不能になるのではという懸念についても、Protocol自体にバックアップと移行が組み込まれている。CARファイルさえあればいつでも別ホストへ移せる。Mastodonはアカウント移行時の損失が大きいが、atprotoでは100%透過的に移行できる。
結局、BlueskyでもMastodonでも入ってみるとアメリカ政治の話ばかりだ。毎週の政治ドラマはあまり好きではないので、TumblrやPinterest、あるいはTikTokのような、もっと多様なプラットフォームの方が自分には合っている気がする。
MastodonがActivityPubと完全に同一ではないのは分かるが、返信が突然消える点のせいで信頼できない。ある投稿は残っていたのにまた消えたりして、この点はMastodonを離れた理由の一つだった。
各アプリが独自のコレクションタイプを使い、それらの間でコレクションを共有できるとしても、結局アプリ同士が相互運用できるかは明確ではない点が少し残念だ。ActivityPubの美しい点の一つは、MastodonユーザーがPixelfedユーザーを特に意識しなくてもフォローできることだ。まるでTwitter、Instagram、Reddit、YouTube、Substackが特別な設定なしに自動で全部つながるような感覚だ。
APは基本的にStatusとQuestionタイプでは複数サービスがうまく連携する。Mastodon、Pixelfed、Misskey、Pleromaなどはすべてこの体系を中心に動いている。だがそれ以外のタイプのサポートは非常に限定的で、他種のコンテンツはまともに扱われない。標準外拡張に関するコミュニティの組織が不足しているのが問題だ。ATprotoはデータコレクションのlexicon/schema定義に必ず従う必要があり、リファレンス実装やサードパーティ実装がスキーマ検証を提供する。そのため基本的な互換性はより明確に構造化されているが、一方で一部の追加フィールドなどについて任意サポートを可能にし、もう少し柔軟である必要もあると思う。Bridgy Fedのように、APubから来たデータに元URLやテキストなどのメタデータを付ける例もある。(https://fed.brid.gy/docs#bluesky-fields 参照)
共通lexicon改善のための取り組みが進んでいる: https://github.com/lexicon-community
「次世代Twitter」を掲げるプロジェクトは、問題の解決方法が少しずつずれているように感じ始めている。Twitterの機能を完全再現した後は、ユーザーとコンテンツ不足という鶏と卵の問題に突き当たるだけだ。結局、人は人が多い場所に集まり、それはまだTwitterだ。 むしろ最近のOpenAIがローンチしたタイムラインのように、まずバックグラウンドでデータを集めてからユーザーに届ける方向の方がよさそうに見える。具体的な実装は違っても、方向性は正しいと感じる。 大半の利用者はツイート作成機能そのものには大きな価値を見出しておらず、本当の価値はデータ消費（コンテンツソーシング）にある。この観点では、マルチソーシャルRSSリーダー + P2Pオプションの方がよりよい方向だと思う。個人的な意見だ。
記事でも説明されているように、初期のフレーミングとしてはマイクロブログを使っているが、実際にはTwitter系に限らず多様な形が可能だ。たとえばTangledは「Github on atproto」、Leafletは「Medium on atproto」という構成だ。 クライアント側P2P方式の限界は、大規模な集約(aggregation)と一貫性の保証が難しいことで、これは大半の一般ユーザーがソーシャルアプリに期待する基本機能でもある。 OpenAIの例も、atprotoが強みを発揮する領域だ。ネットワーク上にすでにデータがあるため、クローリング、インデキシング、自動化ツールを簡単に接続できる。初期の事例として https://github.com/graze-social/iftta を参照できる。
ソーシャルネットワークは「同じだけど何か追加！」という形ではなく、以前のプラットフォームでは不可能だった新しいやり方が出てきたときに成長する。
だからこそNostrは違う！ ブログ、Twitter系、ストリーミングサービス、メッセンジャーなど何でも作れる。例の一覧: https://nostrapps.com
無料のトップレベルドメイン(TLD)は可能なのだろうか。実際のドメイン登録コストとは何なのだろう。Let's Encryptが証明書を無料にしたことを思うと、非営利団体がドメインも無料提供できない理由がなぜあるのか不思議だ。見た目がよい必要もない。UUID v7をいくつも連ねても構わないし、世界的にユニークで無料なら十分だ。ブラウザは一度接続すれば覚えるのだから、長いアドレスでも問題ない。このアイデアは本当にそんなに悪いのだろうか。
atprotoでは、その役割を did:plc が担っている。 https://web.plc.directory/ で無料のIDを発行できる。たとえば私のIDは https://plc.directory/did:plc:3danwc67lo7obz2fmdg6jxcr だ。ドメインのTXTレコードでその did:plc と関連付けられる。
無料TLDは現実的には難しい。TLDとpublic suffix listにはさまざまなルール、コスト、運用上の特殊性がある https://github.com/publicsuffix/list 参照。ただしTLDではない通常のドメインならいくらでも自由に使えるし、無料サブドメインを配布することもできる。しかし実際にそういうサービスを運営すると、すぐにスパムやフィッシングなどダークインターネットからの攻撃が押し寄せ、運営を後悔することになる。誰でもURLリダイレクタを作ることはできても、実際に運営するのは別問題で、まともに運用すればすぐに問題に直面する。残念な現実だ。
ほとんどIPv6アドレス配布と同じ発想だ。今では大半の家庭向けインターネットに /64 単位のpublic IPv6が割り当てられているが、ISPがたいていポートをファイアウォールしているので実質的に活用が阻まれている。しかもISPを変えるとアドレスを失いやすい。これを本当に永続的でポータブルなIPv6アドレスにするには、個人単位でprovider-independentなアドレス空間を無料配布し、それをBGPでグローバルルーティングに載せる必要がある。理論上は可能だが、まだ実装されたことはない（Let's Encrypt誕生前の状態に近い）。 DNSベースの命名がなぜ必要なのかは分からないが、短くて覚えやすいのでなければDNSはあまり適していない。ただ、ngrokのように独自gTLDでドメインを発行する方式なら試す価値はある。実際、.me ccTLDは過去にそうした形で無料ドメインを配布し、その代わり全トラフィックに中間プロキシサーバーで広告を挿入していた。
.tk は無料で、登録件数では世界最大のccTLDだった。主に悪用例が多かった。Facebookが運営会社（オランダ企業Freenom）をフィッシングへの関与を理由に訴えたため、いまは無料ではなくなっている。
以前 .FREE TLD イニシアチブがあったが、実行の遅れや期限未達などで今は立ち消えになっている https://icannwiki.org/.free
Danの記事は見かけるとクリックしてしまう。オープンウェブは先行者利益のおかげで成功したようにも思えて少し不安だ。一方でオープンソースが成功しているのを見ると希望も感じる。atprotoのようなものが成功する世界を見てみたい。ネットワーク効果のせいで、よりよいアプリが成功できないのは本当に惜しい。
HTMLが成功したのは「無料」だったからだ。当時は有料のハイパーメディア標準がたくさんあったが、それらの競合と違ってアクセスしやすかった。誰でも簡単にブラウザやサーバーを作れる環境だった。
ATProtoがネットワーク効果の壁を破れるよう設計されているのも大きな利点だ。皆がatprotoベースへ移行すれば、ソーシャルネットワークを「最後にもう一度だけ」引っ越せば済む構造になる。最終的には脱中央集権で、自由な競争が可能な環境を提供する。
現実的には、こうしたシステムが広く普及する姿は想像しにくい。従来型ソーシャルメディアのターゲット層と、分散志向のユーザー層はまったく異なる。大半は単にプラットフォームという手段にしか関心がなく、システムには興味がない。結局みんながblueskyアカウントだけ作るなら、従来どおり一部の大手サービスに集中するだけで無意味になってしまう。
皆が bsky.social に集まったとしても、従来に比べれば大きな進歩だ。多くのサーバーがAWSに集まっているからといってウェブが中央集権化したとは言わないのと同じで、必要になればいつでも移れる。
実際のところ、blueskyはまだ完全なfederationが実装されていない。すべてのトラフィックが単一の「BGS」ルーターサーバーに依存している。
残念だが、結局のところ問題の原因は「人間」だ。
この取り組みには複雑な気持ちがある。一方では、アイデアそのものは完全に自分の好みだ。誰もが自分のコンテンツを所有するというIndie web運動の文脈にも合うし、このページや記事の完成度も本当に印象的だ。だが一方で、こうした標準を実際に個人ブログやオープンソースプロジェクトに適用する開発者はほとんどおらず、単なるVlog/ブログ運営者や一般ユーザーでも採用は低調だ。データ所有権、開放性、相互運用性に無関心な人が多い事実が気がかりだ。人々はTikTokやInstagramリールのようなフィードだけを求めているように見える。ビジョンと努力は尊敬するが、これがニッチな趣味ではなく主流になれるのか考えてしまう。
開発者体験をもっと簡単にする改善はまだ必要だ。だがこの分野の進歩は非常に速いので、今後6〜12か月がとても楽しみだ。多くの人はATProtoが単なるBlueskyのためのものではなく、はるかに多くの分野に適用できることを理解していない。この点が市場にもっと具体的に見えてくるには時間が必要だ。
なぜ「データ所有権」という概念がそこまで重要なのか、そして大衆がそれを気にしないことが本当にそんなに心配な理由は何なのか気になる。昔から人々はTV、本、ラジオのように所有権なしでコンテンツを消費してきた。今は自分が何かを投稿して周囲に見てもらえる機会が与えられただけで、Instagramの投稿を実際に「所有」しているかどうかがそれほど重要なのか、という疑問もある。
その意見には同意する。結局、私たち自身が主体的にこの技術を広め、大衆化に力を注がなければ成功しない。いつかオープンソーシャルに魅了された創業者/CTOが大衆的に成功するアプリを出すかもしれないし、何もしなければ絶対に成功しない。