ハクソク

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

どこにあるのか://

2025年10月3日原文(overreacted.io)

概要

  • AT Protocol は分散型SNSの基盤となる新しい通信プロトコル
  • at:// URI はデータの所在や所有者を示す独自のリンク形式
  • URI解決は「ハンドル→DID→ホスティング」の3ステップ
  • DID Document で実際のデータ保管サーバや検証情報を取得
  • ハンドル変更やホスティング移転でもリンクが壊れない恒久的な参照を実現

AT ProtocolのURI解決手順

  • AT Protocol は分散型SNSの基盤技術
  • すべてのサーバが JSONデータ を「at://」形式のURIで公開
  • 各JSONデータは固有の at:// URI を持つ
  • URIの構造は「スキーム」「権限（ユーザーや組織名）」「パス」で構成
  • at://の 権限部 は「データ作成者自身」を指す
  • データの物理的なホスティング先はURIに直接含まれない

URI解決の3ステップ

  • ハンドル（例：ruuuuu.de）からDID（分散ID）への変換
    • DNSのTXTレコードまたはHTTPSでDIDを取得
      • DNS例: _atproto.ruuuuu.de TXT "did=did:web:iam.ruuuuu.de"
      • HTTPS例: https://barackobama.bsky.social/.well-known/atproto-did
  • DIDからホスティングサーバの特定
    • DID Document（JSON）を取得し、serviceEndpointでサーバURLを確認
      • did:webの場合: https://iam.ruuuuu.de/.well-known/did.json
      • did:plcの場合: https://plc.directory/did:plc:xxxxxx
  • ホスティングサーバからJSONデータを取得
    • serviceEndpointで示されたサーバからデータ取得

DID Documentの役割

  • DID Document は「インターネット上のパスポート」的役割
    • alsoKnownAs: ハンドルとの紐付け
    • publicKeyMultibase: 署名検証用公開鍵
    • serviceEndpoint: データのホスティング先

ハンドルとDIDの違い

  • ハンドル は人間に読みやすく、変更可能
  • DID は不変でグローバルに一意なID
  • at:// URIはDIDベースで保存することでリンク切れを防止

DIDの種類

  • did:web
    • ドメイン名所有によるID管理
    • ドメイン失効時にIDも失効するリスク
  • did:plc
    • Bluesky独自の分散ID
    • ドメインに依存せず、より永続的

まとめ：AT Protocol URI解決のポイント

  • at:// URI は「誰が作ったか（権限）」を中心に設計
  • DID で永続的な参照を実現し、ハンドルやホスティングの変更に強い
  • DID Document でハンドルの正当性確認とホスティング先特定が可能
  • 開発者は DIDベースのURI を保存・利用することで、リンク切れを防止
  • ユーザーはハンドルで識別、アプリやサービスはDIDで識別・管理

参考コマンド・実装例

  • DNSによるDID解決: 
    nslookup -type=TXT _atproto.<handle>
  • HTTPSによるDID解決: 
    curl https://<handle>/.well-known/atproto-did
  • did:webのDID Document取得: 
    curl https://<domain>/.well-known/did.json
  • did:plcのDID Document取得: 
    curl https://plc.directory/did:plc:<id>

AT Protocolを活用するための実践ポイント

  • SDKや既存クライアント （pdsls, Taproot, atproto-browser等）を活用
  • DID解決キャッシュ の導入で高速化・安定化
  • DID Documentの検証 と最新ホスティング情報の取得を自動化
  • at:// URIはDID形式で保存 し、将来の変更にも耐える設計

このように、AT Protocolは リンクの永続性 と 分散性 を両立し、ユーザーや開発者にとって柔軟かつ堅牢なSNS基盤を提供。DIDとDID Documentの理解が、AT Protocolを活用する上での鍵となる。

Hackerたちの意見

著者です！質問があれば喜んで答えます！この件については、こちらのコメントを見てください: https://news.ycombinator.com/item?id=45469167。記事のイントロが詳しくなくてごめんなさい。技術的な質問（at://の解決方法）を探している狭い範囲の人たち向けに書いたつもりでした。あらかじめ言っておくと、実際にat:// URIを解決することは、アプリの作者としてはあまりやらないことです。アプリの一般的なモデルは、ウェブソケットを通じてネットワーク上のすべてのデータコミットをリッスンし（例えば、https://pdsls.dev/jetstream?instance=wss%3A%2F%2Fjetstream1....）、興味のあるものをローカルデータベースに書き込むことです。だから、at:// URIはデータのユニークなグローバル識別子として使うことが多いけど、実際には解決することはあまりないと思います。データはプッシュされてくるからね。でも、いつでもオンデマンドで取得できるのはいいことだと思います。この文章では、解決手順を「追いかける」ことが、ハンドル、アイデンティティ、ホスティングの関係を理解するのにとても良い方法だと思ったので、解決に焦点を当てました。

└

あなたの今後の記事を先取りしているかもしれないけど、私はそれを待つのも、ATProtoをもっと深く掘り下げるのも嬉しいです。ただ、質問があります: どのアプリでもPDSにデータを書き込むことができるの？もしそうなら、もっと興味深い質問は、Blueskyフォーマットでデータを書こうとして、Bluesky Appviewが期待するフィールドを省略したり、期待とは異なるフォーマットでデータを書いたらどうなるの？

「at:// URIが与えられたとき、対応するJSONをどうやって見つけるの？」これは鶏と卵の話ですね。よくわからないし、説明のイントロも気になりました。「JSON」が欲しい理由は何ですか？うん、「これを読んで」リンクはざっと見ましたけど、私には合わないです。

└

すみません、急なイントロで。要するに、at://プロトコルは、アプリ同士が深く相互運用できたり、情報をクエリしたり埋め込んだりできるアプリを作ることを可能にします。また、ユーザーがアプリ間で共有のユーザーアイデンティティを持てるようにし、コンテンツを自己ホストしたりホスティングを移動したりしてもアプリに影響を与えないようにします。これは、JSONのビットに特定のユーザーハンドルやホスティングサーバーに結びついていない永続的なURIを与えることで実現されます。記事ではその仕組み（「アイデンティティ」とは何か）を技術的に詳しく説明しています。具体的な例を挙げると、ブログアプリ（https://leaflet.pub）は、別のマイクロブログアプリ（https://bsky.app）でのLeaflet投稿の言及を自動的に「見る」ことができて、それを表示できます: https://bsky.app/profile/o.simardcasanova.net/post/3luujudlr.... これはAPIを叩くことで実現されているわけではなく、両方のアプリがオープンネットワークから同じ情報をそれぞれのデータベースに集約しているだけです。

└

これを「https:// URIがあったら、対応するHTMLをどうやって見つけるか？」って考えると分かりやすいかも。ちょっと単純化しすぎだけど、DNSやHTTP、TLSに不慣れな人に説明するにはいい質問だと思う。

Blueskyが倒産してplc.directoryが閉鎖されたらどうなるの？これって無駄に脆弱に見えるんだけど。

└

これはウェブの仕組みと何も変わらないよね。だから、このプロトコルに対する反論としてはあまり良くないと思う。

└

記事を強引に解釈すると、こういう理由があるんだろうなと思います: > Blueskyは現在、これらの懸念に対処するためにPLCをスイスの独立した法人に移行しています。ATコミュニティも考えたり実験したりしています。（記事にはそこにリンクがあります。）

ダンの説明はいつも素晴らしいし、BlueskyのPLC管理移行に関する最新ニュースともタイムリーです。私たちは、https://fair.pm/のためにWordPressプラグインの配布を分散化するために同じDIDシステムを選びました（ユーザー向けパッケージの一般管理も含む；CargoではなくApp Storeを考えてください）。Blueskyの人たち（特にブライアン）は、私たちを助けてくれて本当に助かりました - Ed25519キーサポートを提供してくれたので、libsodiumを使うことができました。（私たちはDIDsの上にプロトコルを設計していて、Blueskyのスタッカブルモデレーションを使っていますが、atprotoを直接使うことは選びませんでした。でも、素晴らしいのは、DIDsがW3Cの標準であり、PLCがatprotoに縛られていないことです。）

└

正直に言うと、「私たち」って誰なのか、もうちょっと情報が欲しいな（あと「何」についてのリンクも）。技術的な解決策が出てくるみたいだけど、WordPressのドタバタとは違う感じがするね。

だから、こういう at:// リンクを保存しているサーバーは、著者が言うようにカノニカルな表現、つまりパーマリンクを取得するためにDNS/HTTPSの手間が必要になるんだよね。DNSSECが機能してないと、かなり脆弱になるんじゃない？あんまり考えてないけど、即座に思ったのは、DNSポイズニングがここで結構なダメージを与えそうだってこと。公的鍵がDNSエントリから見つけたDIDの一部だから、悪意のあるやつが俺の名前で投稿できちゃうかも。どう思う？

└

これはちょっと理解を超えてるな（答えられる人に聞いてみるけど）、でも https://atproto.com/specs/handle#dns-txt-method には「DNSSECは必須ではない」って書いてあるよ（でも、これが君の聞いてることかどうかは分からない）。>公的鍵がDNSエントリから見つけたDIDの一部だから、悪意のあるやつが俺の名前で投稿できちゃうかも。どう思う？DNSはHandle->DIDを解決するだけだけど、DID->Handleのマッピングを確認するにはDIDドキュメントを取得する必要があるんだ。双方向なんだよね。

Hacker Newsで議論の続きを見る