概要

• ファイル は個人コンピューティングの基本概念
• ソーシャルアプリ では従来ファイルの概念は希薄
• 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プロトコル の普及により、ソーシャル活動も「ファイル」として扱う時代へ
• 既存のソーシャルアプリの枠を超えた 新しい可能性