s@ : 静的サイトベースの分散型ソーシャルネットワーキング

 (satproto.org)
9 ポイント 投稿者 GN⁺ 2026-03-13 | 1件のコメント | WhatsAppで共有
  • 静的ウェブサイトを利用した分散型ソーシャルネットワーキングプロトコルで、各ユーザーが自分のデータを直接所有・管理する構造
  • すべてのデータは暗号化された JSON ストアに保管され、ブラウザクライアントがフィードを集約し、投稿を公開
  • サーバーやリレーなしで、友人同士のウェブサイトとブラウザ間の直接通信で動作
  • ユーザーのドメイン名がそのままアイデンティティとなり、HTTPS/TLS を通じて認証
  • 単純な構造で自己主権型ソーシャルネットワークを実現し、個人間の信頼に基づく交流に焦点

sAT Protocol 概要

  • s@ は静的サイトベースの分散型ソーシャルネットワーキングプロトコルで、各ユーザーが自分のウェブサイトにデータを保存
    • すべてのデータは暗号化された JSON ファイルの形で保存され、ブラウザクライアントがこれを読み取って投稿の公開とフィード集約を実行
    • 中央サーバーやリレーなしで動作し、データはユーザーのサイトから友人のブラウザへ直接移動
  • 相互フォロー関係がなければ投稿のやり取りはできず、インフルエンサー中心の構造を排除
  • プロトコルは GitHub Pages など特定のホスティングサービスに依存しない

アイデンティティ (Identity)

  • ユーザーのドメイン名がアイデンティティの役割を果たす
  • HTTPS/TLS によって、そのドメイン所有者がコンテンツを公開したことを認証

ディスカバリー (Discovery)

  • https://{domain}/satellite/profile.json パスでプロトコルバージョンと公開鍵を提供 
    {
  "satproto_version": "0.1.0",
  "public_key": "<base64-encoded X25519 public key>"
}
  • デフォルトパス /satellite/ 以外を使う場合は、.well-known/satproto.json ファイルで実際のストア位置を指定可能

暗号化モデル (Encryption Model)

  • すべてのユーザーデータは暗号化された JSON ストアに保存され、ユーザー本人とフォロワーだけが復号可能
  • X25519 キーペアを使って公開鍵を profile.json に公開し、秘密鍵はブラウザの localStorage に保存
  • 投稿データはXChaCha20-Poly1305で暗号化され、コンテンツキーはフォロワーごとに libsodium の crypto_box_seal で暗号化
  • keys/_self.json ファイルにはユーザーのコンテンツキーと公開用シークレット情報が含まれ、本人のみ復号可能

鍵ローテーションとアンフォロー

  • アンフォロー時には新しいコンテンツキーを生成し、すべての投稿を再暗号化
  • 残っているフォロワー向けに新しい鍵エンベロープを生成し、keys/_self.json を更新
  • アンフォローされたユーザーは以後投稿を復号できない

復号フロー

  • 訪問者が友人のサイトを訪れると、自分の秘密鍵で keys/{follower-domain}.json を復号してコンテンツキーを取得
  • その後 posts/index.json と個別投稿 (posts/{id}.json.enc) を取得して復号

データ構造 (Data Schema)

  • 各投稿は個別に暗号化されたファイルとして保存され、posts/index.json には投稿 ID が新しい順に並ぶ
  • 投稿オブジェクトの例: 
    {
  "id": "20260309T141500Z-a1b2",
  "author": "alice.com",
  "created_at": "2026-03-09T14:15:00Z",
  "text": "Hello, decentralized world!",
  "reply_to": null,
  "reply_to_author": null
}
  • 投稿 ID は ISO8601 UTC タイムスタンプと 4 桁のランダムハッシュで構成

フォローリスト (Follow List)

  • https://{domain}/satellite/follows/index.json パスに平文 JSON として保存 
    { "follows": ["bob.example.com", "carol.example.com"] }
  • 暗号化されず、フォロー関係は鍵エンベロープを通じてすでに露出している

フィード集約 (Feed Aggregation)

  • クライアントはフォローリストを読み、各フォロー先の投稿を復号して時系列フィードを構成
  • 投稿は created_at 基準の降順でソート

返信 (Reply)

  • 返信は reply_to と reply_to_author フィールドが設定された投稿
  • ネストされた返信はサポートせず、最上位投稿にのみ直接返信可能
  • 元の投稿を見られない場合（未フォロー状態など）、返信は表示されない

公開 (Publishing)

  • 新規投稿を作成 → コンテンツキーで暗号化 → 静的サイトへアップロード → posts/index.json を更新
  • アップロードには GitHub Contents API などを利用可能
  • 公開用シークレット情報は keys/_self.json に暗号化して保存

静的サイト構造の例

{domain}/satellite/
  profile.json              # 公開鍵およびプロフィール
  posts/
    index.json              # 投稿 ID 一覧
    {id}.json.enc           # 暗号化された投稿
  follows/
    index.json              # フォロー一覧
  keys/
    _self.json              # コンテンツキーおよび認証情報
    {domain}.json           # フォロワーごとのコンテンツキー

FAQ

  • 「RSS + 暗号化？」 → はい
  • 「AT Protocol から firehose をなくした版？」 → はい
  • 「スケーラブルか？」 → いいえ（「友情もスケールしない」）
  • 「s は slow/shitty の略？」 → はい
  • 「セルフホスト可能？」 → はい、ただし CORS の有効化が必要

関連記事

1件のコメント

 
GN⁺ 2026-03-13
Hacker Newsのコメント

  • このプロジェクトも、多くのオルタナティブなソーシャル／セルフホスト型ネットワークが抱える問題を同じように抱えているように感じる
    暗号化中心の設計は確かに格好いいが、新しい端末に乗り換えたときに友人のフォローを復元しにくく、X25519鍵ペアのような概念も一般の人には理解しづらい
    自分は、単純にID・パスワードベースでサーバーが暗号化を代行する構造のほうが現実的だと思う
    こういうアプローチこそ、非技術ユーザーでも使えて、ビッグテックの代替になり得る方向だと思う

    • 自分も似た考えだ。ただ、中間者のいない世界を望むなら、結局は非技術ユーザーも多少は自分で管理するという文化的変化が必要だと感じる
    • 初期設定のあとで秘密鍵をエクスポートして、パスワードマネージャーなどに保管すればよい。プロトコルそのものを実装するのでなければ、そこまで複雑ではない
      ただし家族や友人には自分が代わりに設定してあげる必要があるかもしれない。それでも、自分だけのWebサイトを持てるようになればかなり気に入ると思う
    • 記事末尾のFAQによれば、これはAT Protocol(BlueSky) の一部要素を省いた概念実験に近い
      実際には、静的ブログをBlueSkyに統合するアイデアと見ることができる。
      BlueSkyのアイデンティティを活用したり、静的サイトジェネレーターのプラグインで認証情報を自動取得する形に改善できそうだ
    • 以前、メールをソーシャルネットワークのトランスポート層として使うアイデアを試したことがあるが、うまくいかなかった
      関連記事 を参照
    • ビッグテックの代替を目指しているのかは分からない。単に小さなコミュニティが便利に使えるなら、それだけでも成功だと思う

  • ブラウザのlocalStorageに秘密鍵を保存するという点に驚いた
    ブラウザ設定の初期化や再インストールでデータが消え、バックアップもしづらく、マルウェアからのアクセスは容易だ
    結局、鍵を失えばフィードも永久に失われるので、ユーザー離れにつながる危険が大きい

    • 同意する。「X25519鍵ペア」のような用語を当然のように使っているあたり、このプロジェクトは大衆普及よりも概念実験に近いと感じる
    • 「安全な場所に鍵をエクスポート」ボタンひとつで解決できると思う。URL.createObjectURL(localStorage.getItem(...)) のような簡単なコードでファイル保存を促せる
    • 完璧を目指すあまり、『十分に良い』解決策を見落としてはいけない。鍵のダウンロード／アップロード機能を追加するだけでも、大半の問題は解決する
      もちろん鍵を失えばアクセス不能になるが、2FAや暗号資産ウォレットの利用者も同様の責任を負っているので、完全に不可能という話ではない

  • /satellite/ パスの代わりに /.well-known/ を使ってはどうかという提案
    Well-known URI 標準を参照している

    • 「.poorly-known」と冗談で返している
    • AT Protoの初期にルートパスを使ってセキュリティ脆弱性が生じたことを思い出して心配している
    • .well-known はホスト全体向けなので、ストリーム単位には不適切だと主張している。複数ディレクトリに分けておくほうがよいという見方だ

  • .well-known/ の提案は真剣に検討する価値があると思う
    すでにIANA登録標準として広く使われており、セキュリティや発見のためのファイルがここに置かれている
    /satellite/satproto.json ではなく /.well-known/satproto.json に置けば衝突も避けられ、プロトコルのエンドポイントであることも明確になる

    • ただし .well-known はホスト単位なので、アカウントごとに複数ディレクトリを置きたい場合には適さないという反論もある

  • ソーシャルネットワークのプロトコルは、技術そのもののためではなくユーザーに直接的な利益を与える必要がある
    BitTorrentのように、人々が単純に「必要だから」参加するようになってこそネットワーク効果が生まれる
    データ管理や共有のしやすさから出発するアプローチが現実的だと思う

    • いくつもの分散型SNSを使ってみたが、結局のところ人はドーパミン刺激がなければ訪れなくなる
      LemmyやPixelfedはコンテンツが少なく、「何も起きていない場所」のように感じた
      Signalも同様に単なるメッセージング用途なので、「スクロールする理由」がない
      結局、継続的に訪れてもらうにはコンテンツとFOMO(見逃すことへの恐れ) が必要だ
    • それでも良いプロトコル設計は重要だ。複雑すぎたり将来への備えが足りなかったりすると、どれほど良いアイデアでもすぐに消えてしまう

  • 本当に分散化されたソーシャル／E2EEメッセンジャーを作るなら、Discordのように各サーバーが実際に独立してホストされる構造が必要だ
    アカウントはNostrのようなプロトコルで管理し、Yggdrasil Network上で動かしてIPv4/6やDNSへの依存を減らすべきだ
    HTTPSでトラフィックを包み、NAT越えを自動化すれば、誰でもサーバーを運用できる
    そうした構造になってこそ、ビッグテックや政府の統制から逃れられる

    • ただし技術だけでは足りない。大衆は結局、マーケティング資本の大きいプラットフォームに集まるだろう
    • 自分は、BitTorrentやIPFSのようなキャッシュベースの分散ネットワークのほうが良いと思う
      サーバーが消えてもデータはエッジに残り、ユーザーのブラウザがホストの役割を担うこともできる
      ephemeral-p2p-project を参照
    • こうした構造はすでに geogram.radio で実験されている
      各デバイスがサーバーとして動作し、WebRTCで完全なP2Pメッセージングを実現している
      インターネットがなくても無線接続でデータ交換が可能だ
    • 自分はMikoto Platformsで似たものを作っている。「Spaces」は物理ノードのどこにでも存在でき、DMは複数ノードを経由してE2EEルーティングされる

  • 以前にはFOAFや Pingback のような完全分散型ソーシャルの試みがあった

    • その現代版が Webmention だ
      IndieWeb Wikiは、このような個人Webベースのソーシャル技術を探るうえで良い資料なので勧めたい
    • もうひとつの例として XFN も忘れてはいけない

  • 「sAT Protocolは静的サイトベースの分散型ソーシャルネットワーク」という説明を読みながら、眉がどんどん上がっていくグラフを描きたくなった

    • それでも目標範囲が狭いぶん、筋の通ったシステムだとは思う
      ただし暗号文が公開で列挙可能なので、量子コンピュータ時代には危険かもしれない
    • これはPGP + RSS の組み合わせに近い。各フィードを暗号化して、個人だけが復号できるようにする
      小規模ネットワークには適しているが、鍵配布やローテーションの問題から大規模への拡張は難しい
    • 「データベースを転送してクライアントが静的サイトをビルドする」という概念として理解した
    • 「Key Rotation (Unfollow)」の部分はASCIIアートで冗談っぽく表現されている

  • ユーザーの立場からすると、これが何をするサービスなのかから説明が必要だと感じる
    fork、パス、JSON、暗号化といった技術用語ばかりで、実際の利用シナリオが見えてこない

    • とはいえ技術に関心のある友人は結構いるので、**『偏執的なセキュリティ志向』**を持つ人たちと一緒に試してみるつもりだ
      MastodonやSignalでは満たせない領域なので、これで実験してみる価値はある

  • こういう分散型ネットワークの実験を見ると本当に興味深い
    たとえ構造的な問題が多くても、新しい組み合わせを学べるのが楽しい
    ただ、フォロー／アンフォローのたびにサイト全体を再暗号化・再ビルドしなければならないのはあまりにも面倒だ
    さらに、フォローしないとコメントが見えない構造はスケーラビリティを大きく制限する
    それでも、RSS・ActivityPub・静的サイトの混合という点は魅力的だ
    静的サイトで動的な友達リストのアクセス制御を実装しようとする試みは矛盾しているが面白い
    結局、愛憎が同時に湧くような構造だ。それでも、こうした試みは歓迎したいし感謝している