atprotoにインスタンスはない
(overreacted.io)- 「Blueskyのインスタンス」を探すという問いは、Mastodonのインスタンスモデルをatprotoにそのまま当てはめたものであり、atprotoはホスティングとアプリ集約を分離して設計されている
- RSSとGoogle Readerのように、データはアプリの中に閉じ込められず、ホスティングされたリポジトリにあり、複数のアプリがそのデータを取得して表示する形で動作する
- Mastodonのインスタンスは、ホスティング・アプリ・アイデンティティ・連合関係がひとつの箱に束ねられた構造であり、管理者の判断やインスタンス障害がユーザー体験に直接影響する
- atprotoでは、ユーザーはホスティングを移したり、新しいアプリを作って試したりでき、Tangled、Semble、SidetrailのようなアプリはBlueskyとは別個に動作する
- atprotoの分散性を見るには、「Blueskyインスタンス数」よりも、代替ホスティングへの移行と新しいアプリのエコシステムが実際に機能しているかを見るべきである
RSSとGoogle Readerに近いモデル
- RSS時代には、ユーザーは自分のブログに記事を投稿し、Google ReaderやFeedlyのようなアプリが複数ブログの記事を集約していた
- 記事はGoogle Readerの中に「住んでいる」のではなく、それぞれのブログやホスティング先に残っている
- 核心はホスティングと集約の分離である
- ホスティングは実際のコンテンツが存在する場所である
- 集約アプリは複数ソースのコンテンツを見せる投影（projection）に近い
中央集権的ソーシャルメディアとMastodonの対応
- 従来のソーシャルメディアは、すべてのユーザーをひとつのアプリと空間に集める方式で運営されている
- この構造では中央集権化と強いネットワーク効果が生まれ、分散型ソーシャルネットワークの議論はこの問題をどう分割するかから始まる
- Mastodon的なアプローチは、各コミュニティが自分たちの「小さなFacebook」または「小さなTwitter」を運営する方式であり、その箱がインスタンスである
Mastodonインスタンスが束ねるもの
- ユーザーは特定のインスタンス「の中」に属することになる
- Mastodonのログイン形式が
[email protected]なのも、アイデンティティにインスタンスが含まれるためである - ユーザーは抽象的な「Alice」ではなく、「instance #1のAlice」になる
- Mastodonのログイン形式が
- 異なるインスタンスのユーザー同士がやり取りするには、インスタンス同士がメッセージをやり取りしなければならない
- Aliceがinstance #1にいてBreeがinstance #2にいるとき、AliceがBreeをフォローすると、Breeの投稿がinstance #1へ転送される
- この転送関係が**連合（federation）**である
- ホスティングとアプリが一緒に束ねられているため、ユーザーはインスタンスに強く依存することになる
インスタンス結合が生む制約
- インスタンス管理者同士で対立が起きると、互いに連合を停止できる
- この場合、ユーザーは友人の投稿をもう見られなくなることがある
- ユーザーのインスタンスが停止すると、そのインスタンスにひも付いたアイデンティティも消える
- フォロワーが追っていたのは「そのインスタンスのユーザー」だからである
- インスタンス間の接続矢印は**O(n²)**で増加する
- 現時点では大きな問題ではないかもしれないが、この方式のソーシャルネットワークが人気を得れば重要になる可能性がある
atprotoの核心的な違い
- atprotoはMastodon的なインスタンス概念を前提にせず、RSSとGoogle Readerのモデルへ立ち返る
- ネットワークレベルでホスティングと集約を分離する
- データはホスティングにある
- アプリは複数人のホスティングからデータを集約する
- したがってatprotoにはインスタンスがない
- ホスティングは変更できる
- アプリは複数ホスティングのデータを集約する
- この構造は、「ひとつのアプリを複数コピーで運用すること」よりも、さらに豊かな分散構造として読める
ユーザー自身ができる分散化
- ユーザーはホスティングを切り替えられる
- 筆者は自分のatprotoデータをEuroskyへ移し、いくつかのUX上の問題を除けば自動で進んだと述べている
- より積極的にやるなら、Cloudflareで無料で自分でホスティングすることもできる
- 新しいアプリを試したり、自分で作ったりもできる
- TangledとSembleは、Blueskyとは無関係なatprotoアプリの例である
- 筆者はSidetrailというアプリを作っており、このアプリはオープンソースである
- atprotoには、アプリ制作のためのStatusphereチュートリアルもある
「Blueskyインスタンス数」が的外れな理由
- Mastodonでは、分散性をインスタンス数で測るのは自然である
- Mastodonでできる主な分散の方法が、ホスティングとアプリが結合した箱をより多く運営し、互いに会話させることだからである
- atprotoでは、すべてのアプリがAtmosphere全体の投影に近い
- FeedlyやGoogle ReaderがBlogosphere全体を表示するのと同じ構造である
- Blueskyデータベースサーバーの完全なコピーを複数運用することは可能だが、Google Readerのコピーをたくさん運用するのと同じくらい一般的に有用というわけではない
- 一部のコピーは特定の必要のために存在する
- Blackskyは、異なるモデレーション哲学のような特定の要求に応える事例である
- reddwarf.appクライアントは専用データベースなしで、コミュニティ運営の無料キャッシュであるconstellationを使っている
- Relayのような共有ネットワーク基盤は、1年間低コストで運用されてきたという
atprotoで見るべき指標
- atprotoの分散性を見るには、「Blueskyインスタンス数」ではなく次を見るべきである
- 人々が代替ホスティングへ移行しているか
- 人々が新しいアプリを作り、使っているか
- ホスティングとアプリを分離すれば、クローズドなソーシャルと連合型ソーシャルの両方で壊れたインセンティブを修正できる
- ユーザーのデータはアプリの外に置き、アプリはそのデータの上で集約する構造こそがatprotoの核心である
1件のコメント
Hacker Newsのコメント
「Blueskyのインスタンスはどこにあるんだ」という質問をわざと誤解して、ATProtoを持ち上げてActivityPubを貶しているように見える
そうすると、ATProtoのリレーとその長所短所、ActivityPubのアカウント移行とその長所短所のような興味深い技術的事実が省かれたり歪められたりして、似た問題を解こうとしている2つのプラットフォームの間に不要な対立を生む
「インスタンス」をサーバー、実行中のソフトウェア、仮想マシン、コンテナのような一般的な意味で使う人もいるだろうに、なぜわざわざMastodon的な概念としてだけ受け取るのか分からない
図と説明は良かったが、ActivityPubへのさりげない当てこすりは、情報伝達というより敵意から出たものに感じられて残念だった
「Google Readerのインスタンスはどこにあるんだ」と比較すると、その質問の不自然さがよく分かると思ったし、記事の最後の2つの図は、初期のatproto/ActivityPub議論でよく見落とされていた点をかなりうまく説明していると思う
リレーを入れなかった理由はここに書いた: https://news.ycombinator.com/item?id=48600963
リレーはモデルの核心というより性能最適化に近いので、記事ではモデル自体に集中したかった
単語に特定の概念と構造が結びつき始めると、「分散型ソーシャルメディア」と聞いて多くの人がActivityPub式の連合構造を思い浮かべ、ATProtoを見て「なぜ人々が登録するBlueskyインスタンスが1つしかないのか」と尋ねるようになる
まったく新しい観点ではないとしても、こうした既存の連想が頭の中で固まっている人たちに後で再リンクする価値のある有用な記事に見える
「filioque」勅令の代わりに、「連合」の定義をめぐって双方が食い違う話をするブログ記事が行き交っているわけだ
Fediverseモデルは従来のソーシャルネットワークの観点から理解しやすいが、ATProtoはユーザーにデータ主権を与えつつ、中央集権型ソーシャルネットワークの拡張性を得ようとする新しい概念だ
ここの比喩は破綻していると思う
RSSはGoogle Readerにまったく依存しておらず、全盛期でさえ、今のメールがGmailに依存しているより依存していなかった
ATProtoでは、AppViewが有用になるにはリレーに大きく依存し、リレーの運用コストもかなり高い
また、RSSの図の黄色い円がブログを意味しているのに対し、Facebook投稿を意味する円は性質が異なる。ブログはそれ自体で独立している
ATProtoが悪いという意味ではないが、この記事は明確にするというより混乱を増やしているように感じる
以前は全トラフィックを保存していたので少し高かったが、sync 1.1でその部分が外れ、今では月20ドルの仮想マシンでもかなり簡単に動かせる
本当に高価で難しいのは、中央集権型であれ分散型であれ変わらないモデレーションだ
この記事の著者は9か月前にリレーに関するありがちな誤解を扱っている: https://news.ycombinator.com/item?id=45077291#45078223
私が見るに、リレーはATProtoを高性能に動かすための接着剤だ
コンテンツには無関係にデータを運び、各AppViewが把握すべきサービス数を減らす役割を果たしているように見える
記事でも述べられているように、Mastodonに対する大きな改善点は、リレー、AppView、PDSがそれぞれ異なるスケーリング要件を持つ別個のサービスだという点であり、システム設計上の問題に対するかなり美しい解法だ
[1] https://atproto.com/guides/glossary
ただし、見えない最適化であり、ほかの戦略もあるので、記事ではほとんど省いた
たとえば今日では、多くの小規模アプリは独自のデータベースインデックスを作らず、Constellation(https://constellation.microcosm.blue/)に依存しているため、リレーをまったく使っていない
ホスティングすると違法になるコンテンツだけを削除していると主張しているが、それがどこまで本当なのかは分からないし、今後変わるリスクも常にある
https://docs.bsky.app/blog/blueskys-moderation-architecture#...
2つの方式の違いを説明している点はよかった。
ただし、「インスタンスが解決する問題をATProtoはどう解決するのか」という問いには答えておらず、もどかしかった。
たとえば投稿のデフェデレーションを、友人の投稿が見えないかもしれない原因不明の理由程度に片づけてしまうと、「ではatprotoはデフェデレーションが解決する問題をどう解決するのか」に答えられない。
このフレーミングから自然に出てくる基本的な答えは「解決しない」である。
ホスティングのレベルでは、blogspot.com や Cloudflare が特定の案件でブロックするのと同じように、明白に違法なものを理由にホスティング事業者がアカウントを停止できる。
アプリケーションのレベルでは、アプリ管理者とモデレーターが、ユーザー生成コンテンツを扱うほかのウェブサービスと同じように調整する。
アプリ開発者が選ぶ問題であり、Reddit のようにユーザー領域のモデレーションの基本要素を提供することも、Bluesky のように別個のモデレーションサービスを差し込むこともできる。
互いに争いうる「コミュニティインスタンス」に相当するものがないため、デフェデレーションもない。あるのはホスティング、アプリ、そしてアプリ開発者の選択によるアプリレベルのモデレーションだけである。
これは Microsoft がメールでやっていることと本質的に似ている。最大手のプロバイダー以外からのメッセージを捨て、実質的にデフェデレーションすることで、ユーザーがメッセージを届けるには Microsoft やほかの既存大手事業者を使わざるをえないようにする。
そうなると新しいインスタンスはメッセージを届けられず、ユーザーも獲得できない。既存の大手事業者には新しいインスタンスと連合しないという歪んだインセンティブが生まれる。
このようなアーキテクチャの選択は、長期的には寡占を固定化する効果がある。
スパム対策に必要だと言われるが、DKIM や逆引きDNS などを正しく設定すれば Gmail に通常どおり配送できるように、そうしていないプロバイダーもあるし、彼らがより多くのスパム問題を抱えているわけでもない。
明白な代替案はクライアント側でフィルタリングすることだ。Microsoft のような運営者ではなく、uBlock のような性質のフィルターリスト提供者がフィルターを供給すれば、特定のインスタンスを運営していない以上、全員を自分のインスタンスへ誘導するインセンティブはない。
firehose 全体を消費できる AppView が非常に多くあり、そのあいだを自由に選べて、自分でも安価に運用できる代替宇宙であれば別だが。
ATProto は、デスクトップやモバイルの RSS リーダーなしで、Google Reader または同規模の複製サービスでしか RSS を読めない世界の RSS に近い。
アヒルのようにガーガー鳴くならアヒルだ。
アカウントには単一のPDSがあり、DID はユーザーの正式なデータフィードであり書き込み先でもある PDS を指している。
データは複製できるが、PDS が正本として扱われる。
これは分散アーキテクチャというより、クライアント/サーバーアーキテクチャにはるかに近い。
P2P データベースもなく、DHT やピアに書き込むわけでもない。PDS に書き込み、その書き込みが選択的にミラーされる。
発見も DNS で行われるので、ピアにデータを問い合わせるわけでもない。
リレーにはピアとしてではなく、PDS に正本としてホストされたデータのコピーを要求するクライアントとして接続する。
PDS をインスタンス、リレーをミラーと呼ぶことが無理だとは思わない。
ただし、Mastodon を語る人たちが「インスタンス」と言うときに普通意味しているものとは異なる。
Mastodon でインスタンスとは、データホスティング、アプリ、コミュニティ、モデレーションが結びついた不可分の束である。
ATprotoは、一貫性のために真の分散化を犠牲にし、MastodonとActivityPubは、よりアクセスしやすい分散化のために真の一貫性を犠牲にしている、という理解
一般的なセルフホスト利用者にとっては、ActivityPubノードを運用するほうが、ATのコンテンツリレーを運用するよりはるかに取り組みやすいから
ATで「分散化」できるのは結局のところ自分のデータだけで、ネットワークの一部を共同所有するというより、自分のデータの所有に近い
HNでもすでに何度も繰り返されてきた話でもある
ActivityPubでは、インスタンス運営がデータ、アプリケーション、その後の拡張の問題まで全部引き受けることになるので、自分で運用責任を負うか、他人のインスタンスに縛られるかのどちらかを選ぶ必要がある
選んだインスタンスが気に入らず移ろうとしても、まだ変わっていなければ、ほぼ最初からやり直しになる状態
AtProtoでは、同じアイデンティティを保ったまま別のアプリケーションプラットフォームへ移るのが簡単で、プラットフォームからデータを持ち出してセルフホストするのも、ユーザー体験としては難しくても少なくとも可能ではある
例えば最近Tangledを初めて使ってみたけど、既存のbskyベースのドメイン(h14h.com)でログインできた。新しいアカウントや新しいユーザー名を作る必要はなく、すでにそこにあったかのようだった
VPSでgitリポジトリをセルフホストする設定も、長くても午後半日仕事で、ほとんど気にしなくていいバックエンドサービスとして動いている
最悪の場合、tangled.orgに「リポジトリが古く、最新のTangledと互換性がない可能性があります」といったバナーが出て、最新バージョンでDockerイメージを再ビルドしてデプロイすれば解決する
アーキテクチャとしてはAtProtoのほうが確かに頭に入れるのは難しいけど、実際にユーザーに触れさせるところまで持っていくのはずっと単純だと思う
自分の頭の中では、ひとつのスライダーというよりトレードオフのビュッフェに近い
ちなみにAPの世界でも、個人や小さなチームがリレー、ミラー、キャッシュ、AppViewなどを運営している。ただ、規模が大きくなるほど高くつく可能性がある、という点はその通り
ATは一貫性だけでなく、アプリ全体にまたがる共有データモデルも提供している
だからアプリ同士が他のアプリのコンテンツを参照してレンダリングできる。型付きJSONのWebのような形で、異なるアプリは同じネットワークを見るレンズだ
誰でも既存データの上に新しい体験を作れるし、APにはこれに相当するものがほとんどない
APはデータをアプリに結び付けるが、ATでは、世界中のデータが入ったひとつのグローバルデータベースをすべてのアプリがクエリしているのに近い
なぜ議論がいつもリレーで止まってしまうのか分からない。今では、その気になればリレーはだいたい月30ドルで動かせるし、Blueskyやコミュニティのリレーを無料で使うこともできる
多くのアプリはリレーをまったく使わず、Constellation(https://constellation.microcosm.blue/)のようなコミュニティインデックスに依存している。独自サーバーやデータベースすら動かしていないアプリもある
でもむしろ逆に、ATprotoのほうがより分散化されている、あるいは少なくともそうなろうとしている、と主張したい
ActivityPubの世界では、アイデンティティ、アプリケーション、ホスティングが本質的に結び付いている
Lemmyを使うには、そのLemmyインスタンスに2つ目の恒久的に分離されたActivityPubアカウントを作るか、自分のMastodonインスタンスがLemmyに理解できるメッセージを送れる範囲でしかLemmyを使えない
新しいActivityPubアプリはどれも新たな相互運用性の問題を生む。各アプリが自分のアイデンティティとホスティングを所有しているからだ
自分がセルフホストしたMastodonインスタンスがLemmyサーバーにアイデンティティを提供し、そのLemmyサーバーが自分のインスタンスに、自分の代わりにコンテンツをホストしろと指示する方法はない
ATProtoが言っているレベルに合わせるには、少なくともそのくらいは必要だ。ただ、実在するATProtoがどこまでそれに当てはまるのかは分からないし、現実に存在するActivityPubも、支持者たちが言うほど相互運用的ではない
このブログはアーキテクチャをうまく説明している
でも実際には、Blueskyという会社が主要アプリを運営し、ユーザーデータの大半をホスティングしていることが「問題」だと思っていた
プロトコルレベルでは分散化されていても、実際のシステムは統制主体という観点では依然としてかなり中央集権的だ
必ずしもBlueskyの責任だという意味ではないけれど、ここまではそういう流れだったのではないかと思う
この問題はBlueskyやATProtoに特有のものではなく、営利組織でも非営利でもボランティア集団でも、誰かが常に問題にする対象を見つける
自分は投資家でもないし、初期ユーザーだったという以外にBlueskyと利害関係もない。自分なりの限界の中でプロトコル、会社、ウェブサイトも理解している
サイトとアプリはよく動いている。人々は、より大きくより良い解決策を作ることより、問題探しに集中しすぎている
大多数は、LemmyやMastodonのような暫定的なP2P解決策を望んでいない。コンテンツが一か所にあり、その主体に責任を問えることを望んでいる
だからP2Pソーシャルネットワークは決して大衆化しないと思う。LemmyやMastodon周辺のドラマは、Twitter、Reddit、Facebookなどを全部合わせたより多かった
これは自分の2セントだけど、配偶者や友人たちも同じ考えのようだ
理論上も実際上も分散化されている
ただ、Blueskyが最大の部分を運営しているので、コミュニティやマインドシェアのレベルでは分散化されていないとは言えるけれど、その点も変わりつつある
「インスタンスはない」と言うだけで、そのアーキテクチャが認証、同期、発見といった問題をどう回避しているのかは説明していない
Google Reader をたとえに選んだのは、不吉に感じる
RSS は Google Reader の終了後も生き残ったが、RSS を使っていたすべてのコミュニティが生き残ったわけではなく、その多くは今でも RSS が何なのかも知らない
分散化されたものだと主張しながら、分散化エコシステムにおける巨大な 社会的中央集権化 を良い事例のように繰り返し指し示すのは、ほとんどフロイト的にすら感じられる
とくに私たちは、その結末をすでに知っている
Google Reader は多くの RSS の家をひとつに束ね、ソーシャルグラフやコメントのような価値を加えたが、Google 幹部の気まぐれで崩壊し、RSS をほぼ殺し、印象的なソーシャルグラフを破壊した
そんなたとえでは ATProto に大きな信頼は持てない
アプリはそれをインデックスするだけ
だからこのたとえでは、誰でも同じグラフを使って Google Reader を復活させたり競合したりできる
気になるなら、今 http://leaflet.pub が実際にそういう形で動いている
デスクトップやモバイルの RSS リーダーは使えず、Google Reader や同規模のクローンサービスでしか RSS を読めないと想像すればいい
最近も誰かが NetNewsWire について話していた
重要な違いは、ブログには自分の Web サイトがあり、RSS フィードに全文を必ず載せる必要はないということ
Bluesky は普通そうは動かない。PDS にあるものはすべて複製される
また、簡単に複製できるよう、ブログ全文を PDS に入れることを推奨している
そうすると、インデックスしたい者は誰でもコピーを持っていけて、彼らがそれで何をしようと制御できない
必ずそうしなければならないわけではない。自分の Web サイトにブログを載せて、Bluesky にはリンクだけを投稿することもできる
atproto アカウントの上に HTTP フロントエンドを載せるのは推奨されるやり方で、実際そうしている人も多い
私も pfrazee.com でそうしているし、正本が atproto にある私の leaflet ブログ記事も、自分のブログでレンダリングしている
RSS との比較は誤解を招く
Atproto アプリは、ユーザーのコンピュータ上で動いてコンテンツの出所に直接つながる RSS リーダーとは違う
Atproto アプリは、読者に提供するコンテンツを制御し、フィルタリングし、形作る サーバー だ
Atproto アプリは、検閲、シャドウバン、広告表示、アルゴリズムフィード化を好きなように行える
ユーザーは無力で、クリエイターは叫ぶことしかできない被害者になる
誰でもデータをどこにでもホストできるという事実は、そのデータを配布する手段がなければ完全に無意味だ
まず、そうしたことをしない別の AppView を使える
フィードはユーザーの望む形でアルゴリズム化できるし、複数のアプリがあれば、ひとつの中央の作り手が望むアルゴリズムに縛られることもない