- ファイル中心のパーソナル・コンピューティングの概念をソーシャル・コンピューティングへ拡張し、ユーザーが作成したあらゆるコンテンツを、アプリではなく本人が所有する構造として説明
- ATプロトコルを基盤に、アプリ間のデータ相互運用を可能にする分散型ソーシャル・ファイルシステムの概念を提示
- 各ユーザーは自分の「everything folder」またはリポジトリ(repository) を持ち、投稿・いいね・フォローなどがJSONベースのファイル(record) として保存
- DID(Decentralized Identifier) と
at:// URI体系により、ホスティング変更やハンドル変更があっても永続的に識別可能なリンクを維持
- この構造はアプリではなくデータ中心のソーシャル生態系を形成し、誰でも新しいアプリを作って既存データの上で動作させられるようにする
ファイル・パラダイムと社会的拡張
- ファイルはもともとアプリ内部ではなく、ユーザーが制御する空間に存在し、アプリはファイルを読み書きする道具として機能するだけ
.svg のようなオープンなファイル形式は、複数のアプリが同じデータを共有できるようにする- 「ファイル形式こそがAPI」という原則のもと、アプリ間の相互運用が可能
- この概念をソーシャルアプリに適用すると、投稿・フォロー・いいねのような行為もファイルのように扱える
- ユーザーのすべてのオンライン活動を収めた**「everything folder」** が存在
- アプリはこのフォルダ内のデータを反映し、フォルダが単一の真実の源泉(source of truth) として機能する
ATプロトコルとソーシャル・ファイルシステム
- ATプロトコルはこうした構造を実際に実装した技術であり、Bluesky、Leaflet、Tangled、Semble、Wisp などがこれを基盤として動作
- アプリはユーザーデータを所有せず、ファイル単位で分離されたデータ保存によって新しいアプリが既存データを再利用できる
- すべてのユーザーのフォルダが集まって分散型ソーシャル・ファイルシステムを構成する
レコードとコレクション構造
- 各投稿はJSONファイル(record) として表現され、作成者情報や派生データ(いいね数など)は含まない
- 例:
{ text: 'no', createdAt: '2008-09-15T17:25:00.000Z' }
- ファイル名はタイムスタンプベースのキー(record key) で生成され、衝突を防ぐ
- ファイル構造はlexiconと呼ばれるスキーマで定義され、各アプリは独自のlexiconを設計できる
- 例:
com.twitter.post, fm.last.scrobble, io.letterboxd.review
- 同じ概念でもアプリごとに異なるlexiconを持て、ドメインベースの名前空間によって衝突を回避する
検証と信頼
- Lexicon Policeは存在しない — どのアプリも他のアプリのデータを強制できない
- アプリは入力されたデータを読み取り時に検証(validate on read) し、有効でなければ無視する
- lexiconを変更する際には下位互換性の維持が必須であり、互換性を壊す変更は新しいlexiconとして分離する
- lexiconは公開配布でき、DNSを通じてドメイン所有の証明を行う
リンクとアイデンティティ(Identity)
- ユーザーが作成した「いいね」や「返信」は他のレコードを参照する必要があるため、永続的なリンク体系が必要
- いくつもの試行の末にDID(Decentralized Identifier) を使ってアイデンティティを確立
did:plc:6wpkkitfdkgthatfvspcfmjo のような識別子は変更不可- 各DIDは現在のホスティング、ハンドル、公開鍵情報を含む文書として解決される
at:// URIはDID・コレクション・レコードキーを組み合わせ、ホスティング変更後も壊れないリンクを提供
- 例:
at://did:plc:6wpkkitfdkgthatfvspcfmjo/com.twitter.post/34qye3wows2c5
JSONハイパーリンクと関係表現
- 各「いいね」「リポスト」「返信」は、他のレコードを参照するハイパーリンク型JSON構造
- 例:
parent フィールドが他の投稿の at:// URIを参照する
- UI上のあらゆる情報(作成者、テキスト、いいね数など)は、このようなファイル間の接続から計算できる
リポジトリ(Repository)とデータフロー
- ユーザーの「everything folder」はリポジトリ(repository) と呼ばれ、DIDで識別される
- 内部には複数のコレクション(collection) とレコード(record) が存在
- リポジトリはどこでもホストでき、移動してもリンクは維持される
- アプリはリポジトリをファイルシステムのように読み取るか、ストリーム(WebSocket) として購読してリアルタイム同期できる
- 各コミットは署名付きハッシュツリー(Merkle tree) によって検証され、データ改ざんを防止
- リレー(relay)サーバーは単にイベントを再送するだけで、検証可能な構造によって信頼を確保する
Atmosphere探索と実例
- pdsls.dev はDIDやハンドルを入力してソーシャル・ファイルシステムのエクスプローラーのように動作
- 例示アプリSidetrail はユーザーのレコード変更をリアルタイムに反映し、データがアプリではなくリポジトリに存在することを示す
- teal.fm Relay デモは、実際のAPIがなくても
fm.teal.alpha.feed.play レコードをインデックスして音楽再生履歴(scrobble) を可視化
lex-gql ツールを使ってLexiconベースのGraphQLクエリを実行できる
- Bluesky では、ユーザーが自作のカスタム・フィード・アルゴリズムを配布可能
- 例:
@spacecowboy17.bsky.social の「For You」フィードは独立して動作し、共有データ上で第三者が機能を改善できる
結論
- ソーシャル・ファイルシステムはアプリ中心ではなくデータ中心のインターネット構造を提示する
- ユーザーは自分のデータリポジトリを所有し、アプリはその上で反応的に動作する
- 「何でもするアプリ」ではなく、「何でも可能な生態系」 への転換を目指す
1件のコメント
Hacker News の意見
アプリは消えても、ファイルは残る
swyx の記事では、長く持続する成果物は結局ファイル／データの形で存在することが強調されている
データは権限がなくてもパースでき、一部が壊れていても依然として有用だが、経済的インセンティブは依然としてコード中心に動いている
標準が登場してコードがデータを受け取り、出力するようになれば、文明全体に大きな価値が生まれる
開発者エコシステムが Google、Microsoft、OpenAI、Anthropic のような企業をデータ標準化に自発的に参加させるよう促すことが、私たちが持つ最も強力なレバーの一つだと思う
でも今のアプリは広告収益に依存するウェブサイトの形なので、そうした構造で動くインセンティブがまったくない
Apple を見ても、標準が世界を変えられない場合は多い
createdAt フィールドが任意の値なら、自分の都合のいいように記録をさかのぼって修正することもできるのでは？
署名(signing)によって、生成時点やその後に改変されたかどうかを検証する方法があるのか気になる
POSSE と AT Protocol は相互運用可能なマーケットプレイスとして理解できる
Reddit や Instagram のように、ユーザーコンテンツが商品で、注意(attention)が通貨であり、プラットフォームは広告や行動データで収益を得る構造だ
しかしこうした構造は必然ではない
ユーザーが自分のソーシャルデータの所有権を持てば、アプリはデータを読むインターフェースへと変わる
私も似たモデルをコマースに適用している。販売者が自分の注文・決済ロジックを直接ホストし、マーケットプレイスは販売者 API と直接統合する構造だ
こうすればプラットフォーム手数料を減らし、価値を生み出す主体に所有権を返せる
記事があまりに詳しすぎて、核心を伝えるには少し過剰だと感じた
それでも比喩は見事だ。PDS 用のファイルブラウザがあれば直接体験できそう
Bluesky の PDS は基本的に公開ファイルシステムで、Git のように複製(replication)が設計に組み込まれている
複製は制御できないが、自動バックアップという利点もある
結局 PDS に載せたものは恒久的な記録のように残るので、慎重であるべきだ
役に立つが長いなら、他の人が必要な部分だけ持っていけばいい
記事末尾の デモセクションで、実際のファイルマネージャの例を見ることができる
「みんながスクレイパーになる世界」という表現が本質だ
「ファイル」という概念は、もう古いと思う
すべてをハッシュベースの blob データとして扱えば、多くの問題は消える
ユーザーが欲しいのはアプリではなく、機能(capability) だ
たとえば「ヨガ動画を見る能力」や「知人に近況を共有する能力」であって、YouTube や Bluesky 自体ではない
アプリはそうした機能を束ねた形にすぎない
メッセージングアプリで単語を検索し、その結果をすぐ会話欄の中で共有できるようなカスタムワークフローが必要だ
PerKeepから着想を得た
「アプリとファイルフォーマットの多対多関係」を説明するためのメタファーとして使った
ATProto の repository 構造の説明を見ると、Merkle-tree ベースのコンテンツアドレス化構造になっている
Lexicon はアプリと 1:1 ではないので、AT はすでに**ポストアプリ(post-app)**時代に向かっている
私は**閉じたプラットフォーム(walled garden)**が消費者の好みの結果だと思う
インターネットがすべてを開いてしまったことで、人々は特定の文化やアイデアを中心にした小さな空間を求めるようになった
IG や Snap は、そうした細分化されたグループチャットのような存在だ
自分の IG 投稿が HN や Truth Social に自動共有されないほうが、むしろありがたい
データポータビリティの価値があまりピンとこない。文脈の違うプラットフォーム間の横断には意味がないと感じる
私が作った Anisota は Bluesky と Leaflet のファイルをどちらもサポートするよう設計した
例として、同じ投稿を Blueskyと Anisotaでそれぞれ見られる
また Aturi というプロジェクトで、ATProto ベースのコンテンツへの汎用リンクも提供している
ATProto では、同じ Lexicon を使うアプリならアイデンティティとデータの完全な移行が可能だ
元画像は自分のローカルにあり、各プラットフォームはただ別の表現にすぎない
プラットフォーム間の意味のない統合は望まない
AT は単に相互運用性を可能にするだけで、すべてを統合するわけではない
たとえば Leaflet は、Bluesky の投稿を引用追跡のために取り込んで表示する
こうした構造のおかげで、製品をフォークしてもネットワークと完全互換であり、競争が活発になる
実際に Blacksky は Bluesky をフォークして別のモデレーションポリシーを適用した事例だ
Dan の書く記事はいつも面白い。読んでいると、結局彼が著者だったのだと気づく
自己記述型データモデル(self-describing data model)には懐疑的だ
ATProto の「Lexicon を追加するだけでクライアントが生まれる」という主張は誇張に感じる
実際には UI を作るにはデータの意味を理解する必要があり、Lexicon だけでは不十分だ
結局、文書を見て自分で実装するのと大差ない
標準化は良いことだが、わざわざ世界中で複製される DB レベルの問題ではない
それでもロックイン(lock-in)を減らそうとする試みは高く評価する
ただし Twitter が直面した本当の問題は、政治的コンテンツやスパムのような社会的要因だった
しかし Bento のように愛されていたサービスが消えれば、誰かがそのデータを復元しようとするはずだ
たとえば Blento は ATProto ベースの Bento 代替サービスで、オープンソースなので誰でも再び立ち上げられる
こうした構造は、ユーザーコンテンツの持続性を保証する意味ある前進だ
『The Unix Programming Environment』を読み、単純なツールとテキストファイルだけでも多くのことができると気づいた
Slack がファイル中心の UNIX スタイルで作られていたらどうなっていただろう、と想像してしまう
単純で組み合わせ可能なシステムに戻りたい
人が読みやすいシリアライズは良いが、毎回パースして再整形するのはつらい
新しいソーシャルプラットフォームが分散・連合環境で共通プロトコルとデータフォーマットを共有するという発想は興味深い
ただ、既存の商用プラットフォームを説得するのは難しそうだ
こうした標準が定着すれば、ソーシャルマーケティングツールが複数のネットワークを統合管理しやすくなるだろう
とはいえ現実には、Facebook、Instagram、TikTok のような閉じたエコシステムが依然として支配している