Where It's at://

📄 Summarized by Claude Sonnet 4.5

2025年10月2日

どんなもの？

AT Protocolにおけるat:// URIの解決プロセスを段階的に解説した技術記事

JSONで構成される分散型ソーシャルネットワーク「atmosphere」において、at:// URIがどのように実際のデータに到達するかを実例とコマンドを用いて説明している

従来のHTTPSプロトコルとは異なり、データの作成者（ユーザー）がURIの権威部分に配置される設計思想を解説

先行研究と比べてどこがすごい？

従来のHTTPSではURIの権威部分がホスティング先を指すのに対し、AT Protocolではデータの作成者（ユーザー）が権威となる

ユーザーはハンドルやホスティング先を変更してもアイデンティティ（DID）は不変であり、既存のリンクが壊れない

did:webとdid:plcという2つのDIDメソッドを提供し、ドメイン依存とドメイン非依存のトレードオフを選択可能

データの所有権がアプリではなくユーザーに帰属する分散型アーキテクチャを実現

技術や手法のキモはどこ？

at:// URIの解決は3段階のプロセスで構成される

1. ハンドルからアイデンティティ（DID）への解決：DNS TXTレコードまたはHTTPS GETで_atproto.<handle>またはhttps://<handle>/.well-known/atproto-didを照会

2. DIDからホスティングへの解決：DID Documentを取得しserviceEndpointフィールドから実際のサーバーを特定

3. ホスティングからJSONへの取得：com.atproto.repo.getRecordエンドポイントで目的のデータを取得

DID Documentは「インターネット上のパスポート」として機能し、ハンドル、署名用公開鍵、データの保管場所を記載

did:webは特定ドメインに依存するが設定が簡単、did:plcはPLC Directoryという集中型レジストリに依存するがドメイン喪失リスクを回避

どうやって有効だと検証した？

実際のat:// URI（at://ruuuuu.de/app.bsky.feed.post/3lzy2ji4nms2zなど）を使用した具体例を提示

各段階で実際のnslookup、curlコマンドの実行例とその出力を掲載

pdsls、Taproot、atproto-browserなどの既存ツールで同じ結果が得られることを確認可能

解決プロセスの各ステップで取得されるJSON構造を詳細に表示し、検証可能性を担保

議論はある？

did:webのトレードオフ：ドメインの制御を失うとアイデンティティ全体を失うリスクがある

did:plcのトレードオフ：PLCレジストリの運営者がアイデンティティに一定の制御権を持つ（更新拒否やデータ提供拒否の可能性）

BlueskyはPLCをスイスの独立法人に移管中であり、コミュニティは代替案を検討・実験中

パフォーマンス向上にはDNS/HTTPS参照の代わりに解決キャッシュ（QuickDIDなど）の使用が推奨される

多くのアプリはWebSocket経由でデータをプッシュ受信するため、実際にはat:// URI解決が不要な場合もある