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

すみません、急なイントロで。要するに、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をスイスの独立した法人に移行しています。ATコミュニティも考えたり実験したりしています。（記事にはそこにリンクがあります。）

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

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

君の名前で投稿するにはプライベートキーが必要だよ。DNSレコードはDIDドキュメントがどこにあるかを指し示すだけだけど、DIDドキュメントが元に戻ることを確認するチェックがあって、これが解決プロセスの一部として自動的に行われるんだ。DNSSECはDNSレコードの変更に対する追加のセキュリティを提供するけど、これがないからといって誰かが君になりすますことはできない。なぜなら、君のサーバーがそれに同意する必要があるから。

DNSポイズニングは状況によっては心配だけど、いつもそうとは限らない。at://文字列の一般的なケースは、ハンドルではなく「権限」スロットにDIDを入れることだよ。その場合、did:plcやdid:webを解決する際には、通常のHTTPSホスト名が関与していて、ウェブPKIもある。だから、DNSポイズニング攻撃はほとんどのウェブブラウジングと同じだよ。ハンドルから始めると、DNSを使うことになる。解決がHTTPSでよく知られているなら、ウェブPKIがあるけど、TXTレコードもサポートされていて比較的一般的なんだ。今のところ、我々が推奨しているのは、ハンドルをサーバーサイドで解決すること、エンドデバイスではなくてね。もしローカルで解決する必要があるなら、信頼できるプロバイダーへのDoHを使うこと。これが完璧ではない（サーバーホスティング環境はポイズニングに対して脆弱なままだし）、でも攻撃面をかなり減らすことができる。DNSSECはこの問題に対する現在の解決策だ。でも、これを義務付けるのは大きな摩擦になると思う。第三者によるDNSSECの問題で、我々のプロダクションネットワークでもかなり目立つ事件があったんだ。例えば、多くのアクティブなアメリカの上院議員がNAME.senate.govをアイデンティティ確認の一形態として使ってる。senate.govのDNSサーバーはDNSSECを使っていて、ほとんど問題なく動いてたんだけど、DNSSECの設定が壊れたせいで、数十人の上院議員がBlueskyアプリで「無効なハンドル」として表示されることになった。これはDNSSECエコシステムに対する信頼の大きな損失で、それ以来我々はこれを推進していない。もし他のアプリケーションレイヤープロトコルがこれを必要として、成功裏に採用されれば、再考するかもしれないね。

これ、俺には合ってない気がする。君がコントロールしてるのはアイデンティティ（つまりDIDドキュメント）だよ。アイデンティティをコントロールしてる限り、ハンドルかホスティング、つまりPDSのどちらかを変更できる。ホスティング/PDSは君のDIDをコントロールしてないから。

メールだとPGP/SMIMEキーを持って他のところに移せるから、そこはいいよね？ATprotoも似たような感じじゃない？

ユーザーではないけど、こういう仕組みは必要だと思う。メールユーザーの約0%がメールホストを変えて、古いメッセージと新しいメッセージの間で自分の身分を証明できるかっていうと、難しいよね。これの価値は、Blueskyの「悪用のウィンドウ」を制限することにある。FacebookやTwitterは、私が許容できる範囲を超えてエンシティフィケーションを進めてるけど、それでも多くの人がそこにいる。Blueskyの競合は、どうアプローチするかを決められる。部分的に互換性を保ちながら、UIやリポジトリのストレージ、ユーザー管理で競争することもできるし。

「ほとんどの人はドメインを持っていないから、そのアイデンティティは第三者に所有されることになる。」確かに、その結果、そういうユーザーは突然の禁止など特定のリスクに常にさらされることになる。ホスティングサービスが敵対的になるときにね。完全な保護は、中立的なTLDの下で自分のドメインを持ち、DNSを使ってトラフィックのルーティング方法を説明するプロトコルを持つことだけど、ほとんどのユーザーがドメインを持っていないから（あなたが指摘したように）、ホスティングサービスが協力的なときに部分的な柔軟性と保護で改善できる余地がまだある。このプロジェクトは、ユーザーがドメインを持っていないからこそ、Blueskyのハンドルを保持しつつ（仮に）データホスティングを別のプロバイダーに移すことを可能にしている。今のビッグソーシャルでは、データがFacebook/X/Instagram/TikTok/YouTubeに永遠に閉じ込められるのとは違ってね。Blueskyはこれに興味を持っているのは、ユーザーが自分のハンドルを設定し、ホスティングをBlueskyに移すこともできるから。時には、既存の最先端を改善するのは、完璧な解決策を提供することではなく、私たちが当然と受け入れている制約に対する改善を提供することで実現することもあるよね（ほとんどのユーザーが自分のドメインを設定しないという事実みたいに）。

GitとGitHubみたいな感じだね（少なくとも長い間は、今はちょっと改善されたけど）。