ハクソク

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

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

概要

sAT Protocolは静的サイトを利用した分散型SNSプロトコル。
ユーザーは自身のドメイン上でデータを暗号化して管理。
サーバーやリレーを介さず、友人間のみで情報共有。
公開鍵認証やフォローリストによる限定的なアクセス制御。
GitHub Pagesなど任意の静的サイトホスティングに対応。

sAT Protocolの概要

  • 分散型ソーシャルネットワークプロトコル
    • 静的サイトを基盤とした設計
    • 各ユーザーが自分のドメインを所有
    • データは暗号化JSONとして保存
  • サーバーレス構成
    • 中央サーバーやリレーサーバーを使用しない
    • データは自分のサイトから友人のブラウザへ直接転送
  • 限定的なコミュニケーション
    • 相互フォロー必須
    • インフルエンサー向けではなく、友人同士のやりとりが前提

クイックスタート手順

  • このリポジトリをForkして自分のリポジトリを作成

  • GitHub Pagesをmainブランチから有効化

  • GitHub PagesのURL(例:https://username.github.io/satellite/)にアクセス

  • デフォルトでは/satellite/パスを利用

    • 他用途で/satellite/を使っている場合は、ルートにsatproto_root.jsonを配置し、リポジトリ名を指定
    {
      "sat_root": "my-custom-repo"
    }
    

アイデンティティと認証

  • ユーザーのアイデンティティはドメイン名
  • HTTPS/TLSによる認証
  • コンテンツ取得=ドメイン所有者による発信の証明

発見(Discovery)ドキュメント

  • sAT対応サイトは以下のパスで発見用ドキュメントを公開

    GET https://{domain}/satellite/satproto.json
    
    • プロトコルバージョンと公開鍵を含む
    {
      "satproto_version": "0.1.0",
      "public_key": "<base64-encoded X25519 public key>"
    }
    
  • デフォルトで/satellite/を参照

  • 別パスの場合はsatproto_root.jsonで指定

暗号化モデル

  • 全データ暗号化:ユーザーとフォローリスト内ユーザーのみ復号可能
  • 鍵管理
    • X25519鍵ペアを各ユーザーが生成
    • 公開鍵は発見ドキュメントで公開
    • 秘密鍵はブラウザのlocalStorageに保存
  • 投稿データ暗号化
    • 256ビットのランダムなコンテンツキーでXChaCha20-Poly1305暗号化
    • フォロワーごとに公開鍵で封入したコンテンツキーを保存(libsodium crypto_box_seal利用)
    • フォロワー用鍵ファイル:keys/{follower-domain}.json
  • セルフキー(keys/_self.json)
    • 自分用のコンテンツキーと認証情報を自分の公開鍵で暗号化し保存
    • 新端末やストレージ消去後はドメイン名と秘密鍵で復元可能

鍵ローテーション(アンフォロー時)

  • アンフォロー時の処理
    • 新しいコンテンツキー生成
    • すべての投稿を新キーで再暗号化
    • 残りのフォロワー分の鍵封入ファイルを再生成
    • keys/_self.jsonも更新
    • アンフォローされたユーザーは復号不可

復号フロー

  • 例:BobがAliceのサイトを閲覧する場合
    • Aliceのデータパスを解決(satproto_root.jsonまたは/satellite/)
    • keys/bob.example.com.jsonを取得
    • Bobの秘密鍵でコンテンツキーを復号
    • posts/index.jsonで投稿IDリスト取得
    • 各投稿(posts/{id}.json.enc)をコンテンツキーで復号

データ構造

  • 投稿

    • 各投稿は個別に暗号化ファイルとして保存
    • 投稿インデックス(posts/index.json)は平文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桁ランダム(例:20260309T141500Z-a1b2)
  • フォローリスト

    • follows/index.jsonに平文JSONで保存
    {
      "follows": ["bob.example.com", "carol.example.com"]
    }
    

フィード集約

  • クライアントはフィードを以下の手順で構築
    • ユーザーのフォローリストを取得
    • 各フォロー先のリポジトリパスを解決
    • 各フォロー先の投稿を自分用の鍵で復号
    • 全投稿をcreated_at降順でマージ
  • 返信(Reply)
    • reply_toとreply_to_authorがセットされた投稿
    • 返信はフラットスレッドとして元投稿の下に表示
    • ネスト返信は非対応(トップレベル投稿へのみ返信可)
    • 元投稿が閲覧できない場合、返信も非表示
    • フォローしているユーザーの返信のみ表示(スパム防止)

投稿の公開

  • クライアントは新規投稿時
    • 一意なIDで投稿作成
    • コンテンツキーで投稿JSONを暗号化
    • posts/{id}.json.encとして静的サイトへアップロード(例:GitHub Contents API)
    • posts/index.jsonを更新
    • 認証情報はkeys/_self.jsonで暗号化保存

静的サイト構成例

{domain}/satellite/
  satproto.json           # 発見・プロフィール・公開鍵
  posts/
    index.json            # 投稿IDリスト(平文・新しい順)
    {id}.json.enc         # 個別暗号化投稿ファイル
  follows/
    index.json            # フォローリスト(平文)
  keys/
    _self.json            # セルフ用鍵封入ファイル
    {domain}.json         # フォロワー用鍵封入ファイル

FAQ

  • これはRSS+PGPですか?
    • はい
  • AT Protocolのサーバーレス版ですか?
    • はい
  • スケールしませんか?
    • しません(友情も同様)
  • “s”は“slow”や“shitty”の略でも?
    • もちろん
  • セルフホスト可能ですか?
    • 可能(CORS有効化が必要)
  • 友達にフォローを頼む方法は?
    • テキストや直接依頼(友達なら直接話せるはず)

このプロトコルは、小規模・信頼関係ベースのSNSを自分で構築したい人に最適。
サーバーレス・暗号化・相互フォローによる強固なプライバシーとシンプルな運用が特徴。

Hackerたちの意見

この部分を読みながら、自分の眉毛の高さのグラフを共有できたらいいのにと思ってる。 > sATプロトコル(s@)は、静的サイトに基づいた分散型ソーシャルネットワーキングプロトコルだよ。各ユーザーは、自分のデータを暗号化されたJSONストアに保存した静的ウェブサイトを持ってる。
でも、公平に言うと、目標の範囲が狭いことを考えれば、合理的なシステムに見えるね。スケールしないけど、それは意図的なものだし。ただ、少数の友達と控えめな投稿数でも「フィード集約」が実用的じゃなくなる可能性があると思う。暗号的には、問題は暗号文が公開で列挙可能になることで、X25519由来のキーで保護されてる。量子コンピュータが実現すると思うなら、これは「今収穫して後で復号」攻撃に非常に脆弱だよ。
つまり、データを使ってネットワークの応答やリクエストを送信できるデータベースがあって、クライアントが受け取ると静的ウェブサイトを構築するってことか。なるほど、なるほど…
> キーローテーション(フォロー解除)_ / . .
あなたのアプリはたくさんのフィードを取得して、それを素敵なページにまとめてくれる、まるでRSSフィードリーダーみたいにね。違うのは、各フィードがあなたしか復号できないように暗号化されてるから、暗号技術が強いアイデンティティ保証を提供して、プライベートメッセージも可能にするってこと。基本的にはPGP + RSSで、特定の構造のファイルにマッピングされてるだけ。既存のフォーマットを再利用するために、RSS/ATOMフィードにすることもできるね。このアイデアの再利用はいいことだし、時間が証明してるアイデアだよ。PGPに似たものは、キー配布の問題があって、何十億人ものユーザーにはスケールしないだろうけどね。キーローテーションや取り消しも別の問題だし。でも、小規模なネットワークなら大丈夫だし、非常に小さくて低電力のデバイスでも動くはず。たぶん、接続が不安定でもいけるかも。
昔、foafっていうものがあったんだよね。https://ja.wikipedia.org/wiki/FOAF それに、pingbackもね。https://ja.wikipedia.org/wiki/Pingback ... 完全に分散型のソーシャルメディアに最も近いものだったと思う。
Webmentionは現代の相当物だね: https://indieweb.org/Webmention (IndieWebのウィキは、今の個人ウェブサイトベースのソーシャルネットワーキング技術を探るのに最適なリソースだと思う。著者にはぜひチェックしてみてほしいし、そこから何かを発展させてほしいな :)
XFNも忘れないで! https://en.wikipedia.org/wiki/XHTML_Friends_Network
> 通常、クライアントはデフォルトで/satellite/の下を探すよ。そのパスがすでに使われている場合は、ドメインのルートに{ "sat_root": "my-custom-repo" }を含むsatproto_root.jsonファイルを置いてね。クライアントはこれを最初にチェックするから。ここで`/.well-known/`は役立つかな? https://ja.wikipedia.org/wiki/Well-known_URI
.poorly-known
ああ、AT Protoがリリースされたときと同じだね。ルートに物を置くことで互換性の問題やセキュリティの脆弱性を引き起こしてる。ため息。
これ、他の多くの代替ソーシャルや連合型、自ホスト型のアイデアと同じ問題を抱えてる。Matrix、keybase、pgpとかね。暗号化に依存しすぎてるんだよね。確かに、オープンでありつつプライベートなことができるのはすごい技術だけど、1. 電話が壊れたときに新しいのを手に入れても友達をフォローできるようにしたい。2. 自分はかなり技術に詳しいけど、X25519のキーペアが何かは正確にはわからない。もっと小さなコミュニティ向けに設計された、でも超セキュアな通信じゃないものが欲しい。ユーザー名とパスワードで守られていて、それを登録したサーバーに渡す感じ。サーバーがキーを回転させるのは管理者が考えて、兄弟サーバーとキーを交換すればいい。具体的なことは適当に言ってるけど、こういう考え方があれば、非技術者でも成功するものが作れると思う。もし批判的に聞こえたらごめん、これはクールだよ。ただ、家族や友達とFacebookやメールの代わりに使えるものではないんだよね。
1. 初期化が終わったら、プライベートキーをエクスポートして安全な場所に保存するように促されるよ。例えば、パスワードマネージャーとかね。2. プロトコルを実装したいなら別だけど、知らなくても大丈夫! (非常に基本的な)実装を使うだけなら、リポジトリをフォークしてアクセスを与えるだけでいい。これが家族や友達にはちょっと難しいかもしれないから、あなたが設定してあげる必要があるかもね。(でも、彼らは自分のウェブサイトを持てることに喜ぶと思うよ!)
何年も前に、特別なフォーマットのメールをソーシャルネットワークのトランスポートレイヤーとして使うアイデアを思いついたんだけど、予想通り、何も進展しなかったよね。https://medium.com/@hliyan/email-re-skinned-as-a-social-netw...
Cloudflareトンネルは面白い選択肢だね。自己ホスティングだけど外部のセキュリティもあるし。
自分も似たようなコメントをするかもしれないな。実際的な観点から見ると、正当な意見だと思う。でも、もしかしたら… 中間業者から解放されるためには、非技術者がもっと自分でやる文化を作らないといけないのかも。技術的な難しさの問題じゃないと思う(大体はね)。人々はただ、誰かに自分のことをやってほしいだけなんじゃないかな。
完全に同意。家から誰があなたのトラフィックを嗅ぎ取るの?NSAとかISP?もうやってるよね。企業ネットワークと同じで、あなたのデータはどうせMITMだし。楽しむためのものは暗号化しなくていいよ。買い物やサーバーへのSSHじゃないんだから。
nostrの話題が出てるのを見るのは面白いね。 https://satellite.earth/ (Satellite nostrクライアント) https://nsite.run/ (文字通りnostr上の静的サイト)
> プライベートキーはブラウザのlocalStorageに保存される。うわぁ…あの人たちはいつになったら学ぶんだろう? _どんな_ ブラウザストレージも信頼できないよ。ウェブ体験に何か問題が起きたら? ブラウザ設定をクリアする。新しいプロファイルを作る。ブラウザを再インストールする。ブラウザのlocalStorageはファイルシステムの代わりにはならない。バックアップもできないし、すごく不安定だし、重要なことには絶対に使うべきじゃない。これは「両方の世界の最悪」なケースで、マルウェアは問題なくアクセスできる一方で、正当なバックアッププログラムは締め出される。(確かに、投稿には「新しいデバイス」の流れが言及されてるけど、どれだけの人が(1)プライベートキーをエクスポートすることを覚えていて、(2)デバイスと一緒にそれを失わないだろうか? 実際には、最初にlocalStorageが失われるまでネットワークを使い続ける人が多いと思うし、その後はフィードが永遠に失われてイライラして、ネットワークを去る可能性が高いと思う。
反対はしないけど、フロントページが「X25519キーペア」みたいな用語を軽々しく使ってるのを見ると、大衆の普及や使いやすさはこのプロジェクトの目標じゃないって明らかだね。中間者なしでソーシャルネットワークが成立するかどうかを探る実験みたいに見える。
こういう取り組みが増えてるのは嬉しい。でも、ソーシャルメディアとE2EEメッセンジャーを本当に分散化するには、Discordみたいなものが必要だと思う。ただし、各サーバーはMinecraftサーバーのような実際の自ホスト型サーバーでね。2人のユーザー間のDMは、共通のサーバーで処理されるべき。アカウントの認証情報はNostrのようなプロトコルで管理され、ボーナスとしてグローバルツイート機能も付いてくる。Yggdrasilネットワークみたいなもので全体を運営して、IPv4v6やDNS、既存のハードウェアインフラに縛られず、それらを活用できるようにする。そして、サーバーの位置を特定しにくくするために、相互のサーバー間のオニオンルーティングも追加する。SoftEther VPNのやり方を参考にして、すべてのトラフィックをHTTPSでラップして、自動的にNATトラバーサルを行うようにして、ISPのファイアウォールの背後からサーバーをホストできるようにする。それがなければ、長期的には大手テック企業や政府に負けちゃう。でも、これを達成できれば、分散型ウェブは本当に飛躍する。オープンソースのファームウェアを使ったWiFiルーターを使って、メッシュネットワークを作って新しいウェブの物理レイヤーインフラの代替として機能させることができる。既存のインターネットの帯域幅も活用できるし、ノードを発見して調整するために少しのデータを送るためのブロックできないパスがあればいいんだ。
もっとbittorrent、edonkey/kad、ipfs、ブロックチェーン、ウェブアーカイブに近いものが欲しいかな。連合されたネットワークがあって、人々は招待されたネットワークに投稿したり、サインアップしたりできる。個々のサーバーがダウンしてもネットワークは生き残る。データはエッジでキャッシュされる。あなたのバージョンは腐りやすすぎると思う、これを特徴として見ない限り。良いコンテンツが早かれ遅かれ消えてしまうのが見える。ページを見ている人をホストとして使うこともできるよ。 https://gabe.durazo.us/tech/ephemeral-p2p-project/
> それがなければ、長期的には大手テック企業や政府に負けちゃう。これはソフトウェアの問題じゃない、技術がどんなに良くても、大衆は常に大手テックネットワークに集まるから、分散型ネットワークは億ドルのマーケティング予算を持つことは絶対にない。
まさにこれを作ってるよ。Mikoto Platformsでは、「スペース」はどんな物理ノードにも置けて、DMはE2EEで複数のノードを通じてルーティングされるんだ。
ユーザーの視点から、これが実際に何なのかを最初に説明してほしいな。フォーク、パス、JSON、分散型、暗号化、キーのローテーションとか色々あるけど、なんでこれに手を出すべきなのか、誰が使うのか全然わからないよ(分散型ソーシャルネットワークも、自分だけしかいなかったらあんまり楽しくないしね)。
自分でこれを設定できる技術的な友達が少なくとも数ダースは思いつくし、レクリエーショナルなパラノイアにも興味がある人たちだよ。さらに、学ぶ意欲がある人や手伝ってもらうつもりの人も、あと十人か二十人はいると思う。今のところ、その友達のグループは、Mastodon(セキュリティはほぼゼロだけど、見つけやすさはそこそこ)とSignal(基本的には電話番号を知ってる人に限られる)を組み合わせて、そこそこ満足してる感じ。これを試してみるつもりだし、特定の友達グループと話し合って、どれくらい反応があるか見てみるよ。
ちょっと脱線するけど、ソーシャルネットワーキングプロトコルは、そのプロトコル自体のために設計されるべきじゃないよ。そうじゃないとネットワーク効果を享受できないから。プロトコルはユーザーに直接的な利益を提供しないと、ネットワークに参加し続ける意味がなくなる。参加が最終的に人々のネットワーク、つまり社会を形成するんだ。自分はBitTorrentをその成功例としていつも挙げるけど、みんなただ物をダウンロードしたい(映画やアダルトコンテンツとか)だけど、結局は共有ネットワークに参加することになる。個人的には、新しい実用的なソーシャルネットワークプロトコルの攻撃ポイントはデータ管理だと思う。今は人々が生成、消費、保存、共有するデータの量が膨大だからね。もっと便利にデータを管理して、簡単に共有できるのが副産物として得られる感じ。
でも、良いプロトコルが普及には重要だと思う。多くの良いアイデアが、実装が複雑すぎたり、十分に堅牢じゃなかったり、未来を考えていなかったりで早々に消えてしまったからね。
> プロトコルはユーザーに直接的な利益を提供しなければならない。そうしないとネットワークに参加し続けることはない。 分散型ソーシャルネットワークを試してみたけど、気づいたことがあるんだ。それは、ビッグテックのようにドーパミンを感じさせるものがないから、絶対に広がらないってこと。LemmyやPixelfedを訪れるのを忘れちゃったのも、アプリを開いたときに同じコンテンツを2、3回見て「ここでは何も起こってない」と感じたから。だから、チェックする必要がなくなったんだ。Signalだってインスタのストーリー機能があるけど、誰もそれを使ってるのを見たことない。だって、みんなSignalに「ただスクロールするため」に行くわけじゃないから。メッセージを送ったり読んだりするために行くんだよ。どんなソーシャルメディアも、人々が訪れたくなるコンテンツが必要なんだ。訪れないと何かを逃してると感じさせないと、結局は開かれないアプリになっちゃうよ。
これは興味深いね。でも、そのサイトにこのプロジェクトの意図やユースケースを説明する哲学的なドキュメントがあればいいのに。暗号技術がデザインの根幹にあるから、公開投稿が望まれていないのかなって思う。