at://はどこにあるのか

(overreacted.io)

2 ポイント投稿者 GN⁺ 2025-10-05 | 1件のコメント | WhatsAppで共有

ATプロトコルは分散型ソーシャルネットワークの基盤となるプロトコルで、すべてのデータはat:// URIで識別される
at:// URIはデータの作成者（ユーザー）を authority として指定し、そのデータが実際にホスティングされている場所は別途見つける必要がある
URIの解決手順は、ハンドルをアイデンティティ（DID）に変換し、DIDドキュメントを参照してホスティングサーバーを確認し、そのサーバーにJSONデータをリクエストする順序で進む
2種類のDID方式（did:web、did:plc）がサポートされ、それぞれ長所・短所とデータ保持方式に違いがある
このアプローチはデータの所有権がユーザーにあることを強調し、ハンドルやホスティングが変わってもつながりが維持される永続性を保証する

ATプロトコル、at:// URI、そしてソーシャルデータのアイデンティティ解決プロセス

# ATプロトコルと at:// URI の基本構造

ATプロトコルは分散した複数のサーバーが特定の標準に従って通信するようにし、それら全体を「atmosphere」と呼ぶ
atmosphere 内の各データには固有の at:// で始まる URI が割り当てられ、この URI は一種の JSON データへのリンクの役割を果たす
従来の URI 構造と異なり、ATプロトコルでは**データの作成者（ユーザー）**が URI の authority に設定される
- たとえば、at://ruuuuu.de/app.bsky.feed.post/3lzy2ji4nms2z という形式では、ruuuuu.de がそのデータの所有者であることを示す
実際のデータがホスティングされている物理サーバーは URI に直接含まれず、これを見つけるには追加の解決手順が必要になる

# at:// URI 解決手順の3段階

at:// URI を実際のデータ（JSON）にマッピングするには3段階が必要
1. ハンドル（ruuuuu.de など）をアイデンティティ（DID: Decentralized Identifier）に変換
  - ハンドルはユーザー識別のための別名であり、変更できる
  - 不変のグローバル ID である DID に変換する必要がある
  - 変換方法:
    - DNS TXT レコードで _atproto.<ハンドル> を問い合わせ → did=... の値を確認
    - または、https://<ハンドル>/.well-known/atproto-did にアクセス
2. DIDドキュメント（DID Document）を参照してデータのホスティング情報を確認
  - DIDドキュメントには、そのアイデンティティの公開鍵、サービスエンドポイント（サーバー）などの情報が含まれる
  - did:web:~ の場合、ドメインベースでアクセス（https://ドメイン/.well-known/did.json）
  - did:plc:~ の場合、PLCディレクトリ（https://plc.directory/DID）で参照
  - サービスエンドポイント（serviceEndpoint）が実際のデータホスティングサーバー
3. ホスティングサーバーの API を通じて JSON データをリクエスト
  - com.atproto.repo.getRecord エンドポイントに at:// の各部分をパラメータとして渡してデータをリクエスト
  - 返される JSON が at:// URI に対応する実際のデータ

# 例を通じた解決プロセスの説明

例: at://ruuuuu.de/app.bsky.feed.post/3lzy2ji4nms2z
- 1段階目: ruuuuu.de → did:web:iam.ruuuuu.de（DNS TXT record または .well-known で確認）
- 2段階目: https://iam.ruuuuu.de/.well-known/did.json で DID Document を取得 → serviceEndpoint が https://blacksky.app
- 3段階目: https://blacksky.app/xrpc/com.atproto.repo.getRecord?... にリクエスト → 実際の JSON を返す
```
{
  "uri": "at://did:web:iam.ruuuuu.de/app.bsky.feed.post/3lzy2ji4nms2z",
  "cid": "...",
  "value": {
    "text": "posting from did:web, like a boss",
    "$type": "app.bsky.feed.post",
    ...
  }
}
```
ハンドルが変わっても、DID ベースの at:// URI（permalink）を使えば、アカウントとデータのつながりは維持される

# DID方式: did:web と did:plc の違い

did:web:
- 自分のドメインを管理・認証できる
- ドメインを制御する権限を失うと、ID 全体を失う可能性がある
did:plc:
- PLC（Public Ledger of Credentials）が ID の運用主体
- ドメインには帰属しないが、PLC 運営者が更新を拒否するなど、限定的な制御の可能性は存在する
- すべての変更履歴はハッシュで検証・追跡可能

# アイデンティティ、ホスティング、データの分離と永続性

at:// はアイデンティティとデータホスティングを分離し、ユーザーデータのポータブル化と永続的リンクの生成を可能にする
Handle（別名）はいつでも変更でき、ホスティングサーバーも同様に移転できる
DID（アイデンティティ）は不変であり、これに基づく at:// URI は永続的なパーマリンクとして利用できる
DIDドキュメントには、handle の所有証明、署名検証鍵、ホスティング情報がすべて含まれ、信頼性と柔軟性を保証する

# 実際の応用と開発に関する言及

現実には、大半の AT ベースのアプリは Websocket などでデータを push 受信し、内部 DB に集約している
それでも at:// URI の解決方法を理解することは、ネットワーク特性の理解とデータ移植性の確保に不可欠
at:// の仕組みは HTTP、DNS、JSON の上にソーシャルネットワークの抽象化を提供し、データ所有権がユーザーにあることを技術的に実装している

# 結論

ATプロトコルと at:// URI は、ソーシャルデータのアイデンティティ、接続性、永続性を技術的にさらに進化させる
開発者は、ハンドル解決、DID の活用、DIDドキュメントの構造、実際のデータリクエスト方法など中核ワークフローの理解が必要
この構造により、自分のコンテンツとアイデンティティ、そしてホスティング場所のあいだに柔軟性と所有権を得られる

1件のコメント

GN⁺ 2025-10-05

Hacker Newsの意見

最近のATProto関連の投稿に触発されてbskyに登録してみたが、見えるのは延々と続くアメリカ政治の話ばかりだった。"こういう投稿を減らす"を押し続けてもほとんど効果がなく、これがこのプラットフォームの本質なのか気になる。海外の妙な論争についてのありきたりな意見ばかり見せられるのは精神的につらい
- 新規アカウントでは"Discover"フィードはかなり良くない。いいねやフォローのデータがたまると徐々に良くはなるが、それでも最高とは言えない。個人的には"For You"フィードを勧める。これはいいねの反映が速く、ランダムなコンテンツをあまり押してこない。"Dev Trending"フィードもかなり良い For You Feed, Dev Trending
- 自分がやったのは、まともそうなアカウントをいくつか見つけてフォローし、"Discovery"タブは完全に隠したこと。その後はフォロワー/フォロー中に出てくる人たちの相互作用を見て、自然にフォロー一覧を増やしていった。あるいはブログやウェブサイトでアカウントを見つけてフォローした。自分としては、これが本当のソーシャルメディアらしい使い方で、自動化されたおすすめコンテンツを無理やり流し込まれるのは好みではない
- 幸い、bskyにはフォローしている人の投稿だけを表示する非アルゴリズム型フィードがある。こういうやり方こそメンタルヘルスを守る唯一の方法だと思う
- 1年以上bskyを使ってみたが、アメリカ政治のコンテンツが大半だった。ヨーロッパ人の自分にはただのノイズに感じられたので、Mastodonに戻った。技術系の人をフォローするにはMastodonのほうがずっと良かった。ニュースはfeedlyのRSSで全部受け取っている。今はBlueskyがなぜ必要なのかも分からない。単にTwitterの左派版のように感じる。技術としてはNostrの発展形として興味深かったが、それだけだ
- 設定で Contents and Media > Your Interests > News and Politics をオフにするのを勧める。アメリカ政治ではない他国のニュースや政治コンテンツだけを見たい場合は、特に方法を知らない
このプロジェクトがアイデンティティやデータ所有権の問題を本当に意味のある形で解決しているのか、まだ分からない。アイデンティティの面では、自分のドメインを使うか、他人のドメイン（Blueskyなど）を使うかの違いしかない。ほとんどの人はドメインを持っていないので、結局その人のアイデンティティは第三者が握ることになる。データも同じで、Blueskyや他のサーバーでアカウントがブロックされればリポジトリも閉じられ、データを別の場所へ移す機会すら失う。これはメールと同じで、自分のドメインとサーバーがなければ実質的には何もコントロールできない
- ATではデータはハンドルやホスティングではなくDID(Decentralized Identifier、分散識別子)に帰属する。自分の書いた記事ではこの点をかみ砕いて説明した。もし"ハンドル"のドメインを失っても、そのハンドルが無効化され、アプリでユーザー名の代わりに"invalid handle"と表示されるだけに近い。投稿やフォロワーなどのデータはDIDで引けるのでそのまま残る。ハンドルは単なる別名のようなものだ。ハンドルの変更もアプリの"ハンドル変更"機能でできる。ホスティングについても同様で、（障壁はあるが）リポジトリのバックアップさえ取っておけば別の場所へ移せる。バックアップの自動化も可能で、すでに自動バックアップしてくれるサードパーティ製アプリも出ている。公式のBlueskyアプリでもリポジトリをエクスポートできる。ホスティング事業者が協力的な場合は PDSMover のようなケースがあるし、非協力的でも adversarial pds migration を見れば可能だ。今は技術的知識が必要だが、いずれこのプロセスも簡単になることを期待している。リポジトリを新しいホストに載せれば、以前と変わらない同一のアイデンティティとして、すべての投稿やフォロワーなどが戻ってくる。これはメールとはかなり違う。今は少し難しいが、ATエコシステムの発展に伴ってずっと使いやすくなるはずだと思う
- ドメインを持っていても、いつか持てなくなる可能性はある。サーバーと違ってドメインは登録事業者（レジストラ）に依存するので、より脆弱だと感じる。そのためレジストラを選ぶときは自国の法律の下にある事業者を選んだ。そうすれば問題が起きたとき、多少は回復の望みを持てると思ったからだ
- ドメインを持たない大多数のユーザーは、ホスティング事業者が"敵"になった瞬間に生じるリスク（例: 突然のアカウント凍結）に常にさらされている。完全な防御は、結局のところ中立的なTLDでドメイン自体を直接所有し、DNSでトラフィックをルーティングすることでしか得られない。それでも、こうした現実（自分のドメインを使う人はほとんどいない）のもとで、このプロジェクトは部分的な柔軟性と保護を加え、既存のBig Social（Facebook、X、Instagramなど）でデータが永遠に閉じ込められるのに比べれば前進だ。Blueskyはこうした環境でも、ハンドルはそのままでデータホスティングだけを移せる可能性があるから注目されているのだと思う。業界は完璧を一度に達成するのではなく、現実的な問題を少しずつ改善しながら進歩していくものだと思う
- アイデンティティ証明の最善は秘密鍵の所有だと思う。ホスティングはBitTorrentが最も堅牢ではないかとも感じる。コンテンツをgitリポジトリに置き、コミットに署名してトレントで配布する方式も考えられる。更新通知にはNNTPやRSSを考えていた。問題は発見性と相互作用の欠如（コメントがないこと）だ
- 少なくともメールならPGP/SMIME鍵を持ち出して別の場所へ移せる。ATprotoも似たコンセプトなのではないかと思う
Danの説明は毎回すばらしい。最近のBlueskyがPLCの運営権を移管するというニュースとも重なってタイムリーだ。私たちのチームも fair.pm でWordPressプラグインの分散配布のために同じDIDシステムを採用した（いわばApp Storeのようなパッケージ管理）。Bluesky側（特にBryan）にはかなり助けてもらい、私たちはlibsodiumを使えるようEd25519鍵のサポートまで実現した。私たちのプロトコルはDIDとBlueskyのstackable moderationの上に設計中だが、atproto自体は直接使っていない。重要なのはDIDがW3C標準であり、PLCがatprotoに縛られていないことだ
- "私たち"が誰なのか、そしてこれがWordPressドラマを技術的に解決しようという試みなら、もう少し詳しい説明が聞きたい
- PLCがatprotoに依存しないとは言うが、PLC（did method）は結局Blueskyか何らかの中央権威に結びついたものではないのか。こんなに中央集権的なのに、なぜDIDと呼ぶのか気になる。did:plcはポータブルでもないし、なぜdid:webのように書いてPLCのような動作を持たせなかったのか、なぜmethod-specific-idを公開鍵ハッシュベースなどの移植可能な形にしなかったのか、なぜDHT（例: did:pkarr）のような分散化にしなかったのかも気になる。PLCは結局また別の中央集権システムに見える
at:// を解決するには plc.directory にGETリクエストを送る必要があり、この時点でシステムが100%中央集権モデルに変わってしまうように見える。少なくとも複数の信頼ディレクトリをプロトコルから分離して置けるようにしてほしかった（DNSルートやCAのように）
- 個別にやりたいなら did:web:fqdn も使える。これは記事でも説明している
at:// リンクを保存するすべてのサーバーは、結局DNS/HTTPSを経由して正式な(permalink)表現を見つけなければならないように思える。DNSSECがきちんと機能しないと、この構造自体が少し脆弱に見える。まだ深く考えたわけではないが、すぐ思いつく懸念としては、DNSポイズニングのような問題で攻撃者が自分の名前で投稿できてしまうのではないか、ということだ（公開鍵がDNSから取得したDIDに含まれているので）
- DNSポイズニングは懸念になりうるが、実際には必ずしもそうではない。at:// ではauthorityの部分にDIDを入れるのが一般的なので、ハンドルではなくDIDで要求すれば、結局はHTTPSとWeb PKI環境に依存することになる。ハンドルから始める場合でもWeb PKIとTXTレコードを経由する。推奨される方法は、handlesはサーバー側で解決し、もし自分で行うなら信頼できるDoH（DNS over HTTPS）プロバイダーへ問い合わせることだ。完璧ではないが攻撃面をかなり減らせる。DNSSECはもちろんこの問題への解決策だが、実運用ネットワークではDNSSEC絡みで何度も面倒な目に遭った。例えばアメリカの上院議員たちは本人確認用に senate.gov ドメインを使っているが、最近DNSSEC設定が壊れて数十人の上院議員がBluesky上で"invalid handle"になったことがある。こうした残念な経験のせいで、今のところDNSSECの義務化を強く推してはいない。もし他の大規模プロトコルがDNSSECを成功裏に必須化したなら、再考の余地はある
- 攻撃者があなたになりすまして投稿するには、必ず秘密鍵が必要だ。DNSレコードはDID文書をどこから取得するかを示すだけで、このDID文書もDNSで再検証される。このプロセスには検証ロジックがある。DNSSECはDNSレコード改ざんのリスクを減らすが、DNSSECがないからといって無関係な第三者があなたになりすまして投稿することはできない。サーバーもそれを拒否する
- その部分は少し難しいが、DNS TXT method にも "DNSSEC not required" と明記されている。いずれにせよDNSはHandle->DID変換だけを担い、検証はDID->Handleを通る双方向のプロセスになっている
記事ではDID変更履歴に使われる鍵についての情報が不足している。例えば自分が foobar.bsky.social だとしても、自分で鍵をアップロードした記憶も、ダウンロードするよう案内された記憶もない。鍵が正確にどこにあり、誰が所有し、どういうタイミングで使われるのか気になる。またDIDが plc.directory にあるなら、そのサイトの運営者が私のDIDを勝手に上書きしてアイデンティティを乗っ取れないようにする仕組みは何なのかも知りたい
at:// というコンセプトは興味深いが、実際にデータ所有ベースのシステムで起こりうる問題も心配だ。例えばユーザーがデータを持っているなら、いつでも内容を好きに変更したり削除したりできる。最初はまともな文章を書いておいて、後から悪意を持って改変することもできる。昔の投稿ハッシュを保存して改変防止しても、新しいサービスはその記録を知らないかもしれない。また、いいね(upvote)のようなものの追跡も難しいし、みんながそれぞれオブジェクトとして保存するなら、誰がアップボートしたかを見つけるのも大変そうだ。偽アカウントを作って自分の投稿だけを延々と上げても制限がなさそうに見える。最後に、さまざまなプラットフォームから流入する膨大な数のアカウントがあると、スパムや悪意ある活動のモデレーションは不可能ではないか。各アカウントが自分のデータを自分で管理する前提で、透明性、責任、モデレーション、スパム対策など、システム設計として成立するのかよく分からない
- 変更管理（history）は一緒に公開すればよい。データ(json)には必要な情報をいくらでも含められるので、既存投稿のアドレスをat://で連結リストのように記述し続けることもできる。DIDはidentity moderationについてよく説明していて、つまり誰なのかを把握し、ブロックしたり判断したりするための十分な根拠を与える。要点は、これはブロックチェーンではなく、データ所有者中心でいつでも共有可能な方式だということだ。誰かが悪意を持って壊しに来ない限り、かなり魅力的な構造だと思う。"この人のどのデータがどこにあるか"が明確に分かるので、そうした透明性などに関心がないなら使わなくてもいいと思う
- 元の内容の悪意ある改変を防ぐために、strongRefというハッシュベースの本当のpermalinkが存在する。Danは記事で詳しく触れていないが、strongRefを保存しておけば既存投稿の内容が変わってもすぐ検知できる。Blueskyが編集(edit)機能を導入していない理由も悪意ある改変のためだ。（参考: permalinksとrecord editingに関する permalink experiment summary, record editing history experiment を参照）アップボート追跡はネットワークをクロールしてデータを集めれば、roaring bitmapなどである程度は可能だ（roaring-bitmaps example）。モデレーションの問題には stackable moderation があり、既存システムよりかなりクールだ。labeler/feedgenをDAG（集合演算ベースのルール組み合わせ体系）にしようという議論もある。データ改ざんの問題は各自のCIDハッシュで変更を検知でき、履歴(history)追跡も技術的には可能だ
さまざまな暗号系プロトコルが分散化を語りながら、結局は一つのプラットフォームに縛られる現実と似ているように感じる
- まだ初期段階だが、tangled.org（GitHub風）、leaflet.pub（Medium風）などもすでに活発に使われている。ネットワークのインデックス作成を自動化するツール（slices.network）などによって、新しいアプリの開発障壁も下がり続けており、今後さらに多くのアプリが出てくると思う。記事ではその仕組みも説明した。重要なのは、"一般"ユーザーにはこうした技術は重要ではないという点だ。Blueskyの大半の利用者は、実際には"分散化"に無関心か、むしろ反感すら持っている。しかし分散化の仕組みは製品の表面に直接現れないので（ウェブ閲覧と同じように）、こういう形の採用はあり得ると思う。ユーザーはただ"ちゃんと動く"ことを望んでいる
- GitやGitHubの過去にも少し似ている気がする（機能が増えるにつれて、少しずつ分散性や柔軟性が高まっていった）
"at:// URIでJSONをどう見つけるのか"という構造的な疑問がある。説明書を読んでも、なぜその『JSON』が必要なのかぴんと来ない。個人的にはこういうやり方はしっくりこない
- 導入が唐突だったのは申し訳ない。at:// プロトコルは、アプリ同士でデータを自由に埋め込み、エクスポートし、ユーザーアイデンティティを共有し、コンテンツのセルフホスティングや移行を可能にする。ハンドルやサーバーに縛られない永続URIを提供するということだ。技術的な仕組みは記事全体で説明している。実例として、leaflet.pub と bsky.app の2つのアプリはそれぞれ同じ公開ネットワークからデータを集約しているので、別個のAPIなしに互いのデータを簡単に連携表示できる（demo post）
- 理解の助けとして、これは"https:// URIでHTMLをどう見つけるのですか？"という質問にたとえることができる。かなり単純化しすぎではあるが、DNS、HTTP、TLSを初めて学ぶ人に説明するには向いている
このプロトコルは巨大なパブリックKafkaトピックのような役割を果たすのか気になる。例えば新しいウェブアプリを作るときにデータを自前で保存せず、すべてのユーザーが各自の空間にデータを保存し、それを聞くリスナーを置いて、プロトコルがデータ伝播を保証するのでアプリ側はそれを購読してキャッシュすればよい、というモデルではないかという質問だ。概念的には面白いが、更新取りこぼしを防ぐためのオフセットや、スケールのためのパーティションのようなKafkaの概念が適用されるのかも気になる
- その通りで、firehoseがほぼその役割を果たす。誰でも購読できるし、自分でfirehoseを動かすこともできる。ATProto for distributed systems engineers を参照。firehoseやjetstreamにはカーソルがあるので、遅れて接続しても最新データまで更新を受け取れる。保持期間はインスタンスによって1〜72時間程度で、完全な履歴が必要ならbackfill方式で処理できる

at://はどこにあるのか

ATプロトコル、at:// URI、そしてソーシャルデータのアイデンティティ解決プロセス

# ATプロトコルと at:// URI の基本構造

# at:// URI 解決手順の3段階

# 例を通じた解決プロセスの説明

# DID方式: did:web と did:plc の違い

# アイデンティティ、ホスティング、データの分離と永続性

# 実際の応用と開発に関する言及

# 結論

関連記事

1件のコメント

Hacker Newsの意見