ハクソク

世界を動かす技術を、日本語で。

ソーシャルファイルシステム

91日前原文(overreacted.io)

概要

  • ファイルは個人コンピューティングの基本概念
  • ソーシャルアプリでは従来ファイルの概念は希薄
  • ATプロトコルにより、ソーシャルデータもファイルのように扱う発想
  • レコードという単位で投稿やプロフィールを管理
  • 分散型ソーシャルファイルシステムの可能性

ファイルの素晴らしさ

  • ファイルはアプリの外に存在し、ユーザー自身が所有・管理
  • アプリはファイルを読み書きするが、所有権は持たない
  • ファイル形式はアプリ間の共通言語として機能
    • 例：SVGはオープン仕様、複数アプリで互換性
    • .docのような独自形式もリバースエンジニアリングで拡張可能
  • ツールと作品の分離という直感的なモデル
    • 原稿はタイプライターに、写真はカメラに縛られない
  • アプリ非依存のストレージ（ファイルシステム）による自由
  • ファイルは複数アプリで活用・変換・再利用可能
  • アプリが消えてもファイルは残る、新しいアプリでも利用可能

ソーシャルアプリとファイルの関係

  • InstagramやReddit等のソーシャルアプリは従来「ファイル」概念が希薄
  • 投稿やフォロー、投票などはファイルとして扱われていない
  • もし「everything folder」として全てのソーシャル活動をファイル化できたら？
    • 投稿、フォロー、いいね等が個人フォルダにファイルとして保存
    • フォルダがデータの唯一のソースとなり、アプリはそれを反映
    • フォルダの変更はアプリにも即時反映
  • 分散型ソーシャルファイルシステムの構想
    • 各ユーザーのフォルダがネットワーク全体で共有
    • アプリはキャッシュやビューとして機能
  • ATプロトコルはこの仕組みを実現
    • Bluesky, Leaflet, Tangled, Semble, Wisp等が実例

レコード：ソーシャルファイルシステムの単位

  • ソーシャル投稿をJSON形式のレコードとして保存
    • 例：{ text: 'no', createdAt: '2008-09-15T17:25:00.000Z' }
  • 著者情報やカウント系データはレコードから分離
    • 著者のプロフィールは別レコード（例：profiles/self）
    • 返信数やいいね数は他ユーザーのアクションから派生
  • レコード名はタイムスタンプ＋ランダムID等で一意化
    • posts/34qye3wows2c5 など
    • 並び替えでタイムライン表示も容易

レキシコン：データ形式の厳密な定義

  • レコードの形式や制約を明確に定義する必要性
  • TypeScript型だけでは制約表現が不十分
    • 例：「textは最大300グラフェム」「createdAtは日時形式」
  • 独自スキーマ言語（レキシコン）で柔軟に記述
    • 例： 
      {
  "defs": {
    "main": {
      "type": "record",
      "key": "tid",
      "record": {
        "type": "object",
        "required": ["text", "createdAt"],
        "properties": {
          "text": { "type": "string", "maxGraphemes": 300 },
          "createdAt": { "type": "string", "format": "datetime" }
        }
      }
    }
  }
}
  • レキシコンにより、アプリ間で一貫したデータ管理が可能

まとめ：分散型ソーシャルファイルシステムの未来

  • 個人のデータ主権を取り戻す新しいソーシャルの形
  • アプリはファイルのビューや編集ツールとして機能
  • データの移植性・相互運用性が飛躍的に向上
  • ATプロトコルの普及により、ソーシャル活動も「ファイル」として扱う時代へ
  • 既存のソーシャルアプリの枠を超えた新しい可能性

Hackerたちの意見

何回この記事を読んで楽しんだか覚えてないけど、いつもダンが書いてるって気づくのは嬉しいよね ;)
└
ありがとう！
これはATのいいイントロだったけど、もうちょっと短くても良かったかな。全体的にちょっと過剰に設計されてる気がするし、関心の分離が悪いね。デザインをフラットにして、すべてをレコードに埋め込む方がスマートだと思う。で、他のレイヤーはその上に構築すればいい。すべてのレコードには著者の公開鍵（または署名）を含めるべきだよね。必要なものには、そのハッシュか、ハッシュ＋著者の公開鍵を使えばいい。この方法で、変なファイルシステムの階層を完全に排除できる。あとは、レコードに埋め込むだけ。レキシコンやコレクションは、単なるレコードのフィールドだし。ハッシュを逆引きして何かを見つけるのは、また別の問題だね。
└
そうだね。SSBとANProtoはこれをやってる。実際、公開鍵＋署名のハッシュにリンクするだけで、タイムスタンプ付きのハッシュリンクがレコードに開くことができる。この方法だと、すべてがハッシュ検索になるから、すべてのノードがデータを保存できるんだ。
└
あなたの提案がよくわからないんだけど、私の例（Twitterの投稿）を使って、あなたのシステムでどう保存されるかを示しているの？
この記事は詳細が多すぎて、要点を伝えるのにそこまで必要ないと思う。多くは付録に移せたんじゃないかな？でも、いいメタファーだよね。誰かがPDS用のユーザーフレンドリーなファイルブラウザを書いて、自分で見られるようにすべきだと思う。あと、静的ファイルを提供するウェブサーバーのように、BlueskyのPDSはパブリックファイルシステムなんだ。さらに、Gitリポジトリのように複製されるように設計されてる。データの複製はBlueskyの仕組みの一部だし、複製は自分のコントロール外だよ。明るい面としては、自動バックアップってことだね。だから、パブリックなgitリポジトリと同じように、そこに置いたものは公開されてインデックスされるってことに慣れておくべきだよ。ランダムな人が検索で見つける可能性もあるし、AIがそれを学習するのは避けられない。自分のPDSからは削除できるけど、実質的には永久記録に残るから、その点は覚悟しておいた方がいい。後悔するようなものは置かないようにしよう。できるだけ本名と関係ないエイリアスを選んで、良いオペレーションセキュリティを心がけるのがベストだけど、危険も伴うよね。
└
それがoverreacted.ioの投稿の一般的なスタイルだと思う。
└
> 誰かがPDS用のユーザーフレンドリーなファイルブラウザを書いて、自分で見られるようにすべきだと思う。https://pdsls.dev/はこの目的に役立つと思うよ :) いいアプリだし、オープンソースで、完全にクライアントサイドだよ。編集: あ、pdslsは記事の最後にすでに言及されてるね。
└
僕の書く目的は、頭の中にあるものをその形のまま外に出すことなんだ。もし役に立つけど長すぎるなら、他の人が価値を見出して、アレンジしたりするのを信じてる。 > 誰かがPDS用のユーザーフレンドリーなファイルブラウザを書いて、自分で見られるようにすべきだと思う。記事の最後にデモをいくつかやってるから、そこに飛んでみてね: https://overreacted.io/a-social-filesystem/#up-in-the-atmosp.... そこではファイルマネージャーを提案するよ: > https://pdsls.devを開いてみて。 [...] 本当に昔のファイルマネージャーみたいだけど、ソーシャルな要素があるって感じだね。そう、パラダイムは基本的に「みんながスクレイパー」ってことだよ。
remoteStorageに似てるね [0]。あれはどうなったんだろう？ [0]: https://remotestorage.io/
└
これ、私には似てないな。remoteStorageはユーザー間でデータを集約しないアプリ向けのように見える。ATは集約を解決しようとしてるけど、多くのユーザーが自分のデータを持っていて、表示したいのはそのデータから計算されたものだよね。ソーシャルメディアやHN自体のように。
└
remoteStorageはまだ時々アップデートされてるよ。 https://solidproject.org は、ティム・バーナーズ＝リーが支援している、やや新しい似たプロジェクトだね。（独自の問題もあるけど。）私はこれらのプロジェクトはプライベートデータには比較的うまく機能していると思うけど、パブリックデータはちょっと awkward だね。ATProtoはその逆で、パブリックデータを実現するためのインフラがたくさんあるけど、プライベートデータはまだちょっと awkward だ。でも、人気があるから、もしかしたらその問題を解決するチャンスが大きいかも？それとも、Blueskyはそのための独自の拡張を持っていて、VCのプレッシャーが高まるにつれて、どんどんその部分を閉じていくかもしれない。とはいえ、Blueskyについてはあまり知らないから、この推測は全部無意味かもしれない。
私はずっと、ウォールドガーデンは消費者の好みの結果だと思ってたんだ。原因じゃなくてね。インターネットの影響（すべてが誰にでも開かれていること）は、特定のアイデアや文化の周りに小さなポケットを作ることだった。グループチャットをしてるみたいに、IGやSnapもそういうもんだよ。セグメンテーションが進んでる。私のIGの投稿がHNに表示されないことや、使いたくないサービス（トゥルースソーシャルみたい）に簡単にクロスポストされないことが本当に嬉しい。オープンにしたいなら、ウェブに投稿すればいいじゃん。データポータビリティの利点がよくわからない気がする。なんか、クリプトで「ポケモンのゲームアイテムをカウンターストライクで使いたい」って言ってるみたいで、文脈なしにはそれがどう価値があるのか全然わからない。同じように、HNのSnap投稿や、まだ作られていないサービスのHN投稿もそう。
└
>「私のIGの投稿がHNに表示されないことや、使いたくないサービス（トゥルースソーシャルみたい）に簡単にクロスポストされないことが本当に嬉しい。」ATProtoアプリは自動的にこういう風には動かないし、デフォルトで全ての「ファイル」タイプをサポートしてるわけじゃない。アプリの作成者が特定の「ファイルタイプ」をサポートする必要があるんだ。私のアプリ https://anisota.net はBlueskyの「ファイル」とLeafletの「ファイル」の両方をサポートしてるから、ユーザーはBlueskyの投稿、Leafletの投稿、Anisotaの投稿を見ることができる。でも、これは私がそう設計したからなんだ。誰でもユーザーのPDSの内容を表示するフロントエンドを作れるよ。例えば… Blueskyの投稿はBlueskyで: https://bsky.app/profile/dame.is/post/3m36cqrwfsm24 Blueskyの投稿はAnisotaで: https://anisota.net/profile/dame.is/post/3m36cqrwfsm24 Leafletの投稿はLeafletで: https://dame.leaflet.pub/3m36ccn5kis2x Leafletの投稿はAnisotaで: https://anisota.net/profile/dame.is/document/3m36ccn5kis2x 私はAturiというちょっとしたサイドプロジェクトも持っていて、ATProtoベースのコンテンツを好きなクライアント/フロントエンドで開ける「ユニバーサルリンク」を提供してるよ: https://aturi.to/anisota.net
└
>「インターネットの影響（すべてが誰にでも開かれていること）は、特定のアイデアや文化の周りに小さなポケットを作ることだった。」私はそれに同意するよ。投稿から見ると: >「いくつかのユースケース、例えばクロスサイトのシンジケーションでは、標準的な共同管理のレキシコンが意味を持つ。別のケースでは、アプリに責任を持たせたい。」異なる製品が投稿について意見が違うのは実際に良いことだよ！異なる製品、異なる雰囲気。私たちはそれをサポートしたいし、戦いたくはない。ATは、あるアプリの投稿がデフォルトで全てのアプリに表示されるわけじゃない。ただ、意味があるところで製品が相互運用できるようにするだけ。どのデータをネットワークから表示するかは、製品を設計している人次第だよ。例えば、HNがInstagramの投稿を表示する理由はない。でも、自分のアグリゲーターアプリを作っているなら、HNの情報をRedditの情報と一緒に処理したいかもしれない。ATはその能力を与えてくれる。具体的な例を挙げると、Leaflet（https://leaflet.pub/）はマクロブログプラットフォームだけど、ネットワーク上のLeafletからの引用を追跡するためにBlueskyの投稿を取り込んで、その引用をLeafletのサイドバーに表示するんだ。これはLeafletとBlueskyが協力する必要はなくて、自然に可能なんだ。これをサポートするもう一つの理由は、誰かが十分にモチベーションを持てば製品が「フォーク」できることだよ。データがオープンネットワーク上にあるから、製品のフォークが元のネットワークと完全に相互運用可能になることを妨げるものは何もない（つまり「元の」データを見て、貢献もできる）。だから、フォークは「みんなを移動させる」問題を解決する必要はなくて、実行する価値があるだけの良さがあれば、自然に成長するんだ。これで競争がかなり激しくなるよ。例えば、BlackskyはBlueskyのフォークで、異なるモデレーションの決定を下している（https://bsky.app/profile/rude1.blacksky.team/post/3mcozwdhjo...）けど、ネットワークと相互運用可能なままだ。
└
>「データポータビリティの利点がよくわからない気がする。」Twitterは私のウェブ上の家だったけど、15年近く経って、ある日… - まあ、話は知ってるよね。その時、私は自分のアイデンティティや投稿、いいね、そして全てのソーシャルグラフを、まともな人たちが運営する互換性のあるアプリに持って行けたらいいなと思ってた。結局、全く新しく始めなきゃいけなかった。でも、ATProtoを使えば、まさにそれができるんだ。誰かがアプリ全体をフォークすれば、あなたのアイデンティティ、投稿、いいね、ソーシャルグラフをそのまま保てる。全てが移行できるんだ、他のアプリが同じATProtoのレキシコンを使っている限り（つまり、基本的に同じ種類のアプリ）。
└
同意するよ。ここでの原動力がよくわからない。Instagramにアップロードした生の画像ファイルは全部持ってるし、エディタで作ったバージョンをスクリーンショットしたりダウンロードしたりできる。どこででも公開したテキストも同様だ。生データを自分のファイルシステムに持っていて、どのプロジェクションをインターネットのどこに公開するかを（ある程度）選べるこの形が好きなんだ。IGのフォローやHNのアップボートは、そのプラットフォーム以外では全く価値がない。知らないうちに変な方法で集約されるのは望んでないよ。
ずっと考えてたんだけど、もっと根本的な視点からね。「ファイル」っていうアイデアはもう古いと思うし、捨てちゃってもいいんじゃないかな。すべてをデータの塊として扱って、ハッシュでアドレス指定すれば、記事で説明されてる問題の多くは解決すると思う。もし本当に意味があるなら、互換性のために、関連するデータをファイルシステムの抽象化を通じて公開することもできるしね。それに、ユーザーはアプリを求めてるわけじゃない。ユーザーが欲しいのは機能なんだよ。だから、BlueskyやYouTubeみたいなものじゃなくて、興味のある人と簡単に生活のアップデートを共有する機能とか、ヨガのチュートリアル動画にアクセスする機能が求められてる。アプリの主な問題は、機能が束になってることなんだけど、特定の機能の組み合わせが求められることが多いから、うまくつなげられるといいよね。最近特に思うのは、メッセージングアプリを使ってるときに、メッセージの中の特定の単語を調べたいと思って、それを関連するものとして共有したいってこと。今はその単語をブラウザアプリにコピーして調べて、内容やURLをコピーしてメッセージングアプリに戻って共有しなきゃいけない。チャットしてる同じウィンドウで調べられる機能があったら最高だな。メッセージバブルの横にブラウザコントロールを埋め込んで、必要に応じてそのコントロールを他の人にも直接アクセスできるようにしたら、彼らが自分のアップデートをすることで、即席のコンテンツコラボレーションが生まれるかもしれない。パーソナライズされたワークフローをその場で作れるようにするために、こういう障壁を壊す時が来たと思う。アプリが支配するデバイス内レベルでも、APIサービスが支配するデバイス間レベルでもね。
└
ファイルシステムは、文字通りというより比喩的に使ってるんだ。「アプリ」は「ファイル形式」に対して多対多だからこの比喩を選んだ。ファイル形式はレキシコンの強力なアナロジーだと思ったから、説明の他の部分もそれに基づいて構築したんだ。リポジトリのデータ構造についての技術的な詳細は、https://atproto.com/specs/repository を読んでみて。リポジトリのデータ構造はコンテンツアドレス方式（マークルツリー）で、リポジトリの内容のすべての変更（追加、削除、レコードの更新など）は新しいコミットデータハッシュ値（CID）を生成する。コミットは暗号的に署名されていて、回転可能な署名キーを使うことで、コンテンツ全体または一部の再帰的な検証が可能になる。リポジトリとその内容は、バイナリDAG-CBOR形式で正規に保存されていて、データオブジェクトがコンテンツハッシュ（CIDリンク）で相互参照されるグラフになってる。大きなバイナリデータはリポジトリに直接保存されず、ハッシュ（CID）で参照される。アプリについて言えば、ATは実際にはある程度ポストアプリだと思う。レキシコンはアプリと1:1じゃないからね。アプリ間でレキシコンを共有できるし、境界があいまいになって、君が言ってるような未来が見えると思う。
POSSEとATプロトコルは、相互運用可能なマーケットプレイスとして理解できる。RedditやInstagramのようなプラットフォームはすでにこのように機能してる。製品はユーザーコンテンツで、支払いは注意で、プラットフォームの取り分は広告や行動データ。ダンはこの構造が避けられないものではないと主張してる。もしソーシャルデータが人々が所有し、自分で保存するものとして扱われれば、アプリケーションはソーシャルグラフの所有者ではなく、ユーザーが制御するデータを読み取るインターフェースになる。私は商取引のために似たようなモデルを考えてる。売り手は、自分が制御するホスティングサービスとして、注文、カート、支払いなどの商取引ロジックを展開し、マーケットプレイスは売り手のAPIと直接統合する。これによりプラットフォームのオーバーヘッドが削減され、手数料が下がり、価値を生み出している人々に所有権が戻ることで、マーケットプレイスはゲートキーパーではなく、相互運用可能な発見のレイヤーに変わる。
> アプリは来たり去ったりするけど、ファイルは残る—少なくとも、私たちのアプリがファイルを考えている限りは。そうだね: https://www.swyx.io/data-outlasts-code-but all lasting work is done in files/data (can be parsed permissionlessly, still useful if partially corrupted), でも経済的なインセンティブが私たちをコードに留まらせようとする（壊れやすいし、メンテナやビルドツール、ハードウェアの基盤が壊れたら基本的に死ぬ）。基準が出てくると（コードがデータを受け入れたり出したりすることを強制する）それは文明にとって非常に価値がある。開発者エコシステムがインセンティブのバランスを変えて、GoogleやMicrosoft、OpenAI、Anthropicのような企業がデータ基準に貢献したり参加したりしたいと思うようになるのは、私たち開発者コミュニティが持っている最も強力なレバーの一つだと思う。（同時に、企業が基準を拡張したり受け入れたり消滅させたりするのにも注意が必要だけど…正直、Chrome以外で本当に成功した例を思いつくのは難しいな）
└
お久しぶり！ :) 「間接法則」なんて知らなかった、面白いね。
新しいソーシャルプラットフォームにとって面白いコンセプトだね。すでに連携された分散環境に存在するプラットフォームで、通信プロトコルやデータ形式を共有してる。既存の商業プラットフォームにこれを考慮させるのは難しいと思うけど。それがあれば、人気のあるソーシャルメディアでのコミュニケーションや投稿を管理するためのマーケティングツールがもっと簡単になる。とはいえ、ソーシャルマーケティングツールはすでに似たようなアナロジーを発明して、自分のコンテンツやフィードバックをインスタンスやネットワーク間でコントロールできるようにしてる。今も、BSKYが未来だと言う人もいれば、Mastodonが未来だと言う人もいる…でもみんなFacebookやInstagram、若者たちはTikTokも使ってる。これらは閉じられたプラットフォームで、ハックするためのツールはあっても、基準は残らない。
「The Unix Programming Environment」を読んでるんだけど、基本的なツールとファイル（ほとんどはプレーンテキスト）でどれだけのことが達成できるかに気づかされたよ。現代の同等物がどんなものになるか考える時間を持ちたいな。例えば、Slackがファイル（とテキスト）指向でUNIX風だったらどうなるだろう？UNIXにはユーザー間のライブメッセージングという原始的なチャットがあったし、もっとシンプルでうまく組み合わさるシステムに戻る動きが見たいな。