1. 「依存型に触ったことある」もしくは「TaPLを部分的にでも読んだ」あたりが基準になるだろうか。
yamarten
-
https://bsky.app : ウェブクライアント
-
https://staging.bsky.app : bsky.appと同じ？
-
https://status.bsky.app : サーバー状態・メンテナンス情報
-
https://bsky-debug.app : デバッグ情報
-
https://account.bsky.app : ドメイン購入
atprotoにおける「分散」もしくは「フェデレーション」は一意ではない。現状で考えられるアーキテクチャについて妄想してみる。
atprotoのfederationにおける登場人物は主に3つ。ユーザー（クライアント）から近い順にPDS・BGS・App Views(appview)の3つ。
詳細は公式ブログ参照。
実装はあんまり見ずに、ATPの雰囲気を把握するためのメモ
要素としては以下のような感覚。
- Repository: 署名つきRDB
- データ構造がRDB(というか表)という話で、SQL-likeな操作が規定されてるわけではない
Table of Contents
目についたCoqのライブラリ/プラグイン/開発環境などの覚え書き
実用面は気にせず、研究用や無メンテも載せる
10月18日。experimentだったADXが「Authenticated Transfer Protocol」に名を変え正式発表して早一年。特にBlueskySocialが活発に動き出してからのatprotoは色々と変わったことや分かったことがあったので、まとめてみる。
とはいっても「何ができるか」はきっと各所で解説されているので、「何ができていないか」「何をしなくなったか」にフォーカスして、一周年記念らしからぬネガティブな話をする。一年間の道程の概略は本人達がまとめているので、そちらを参照されたい。
解説というより覚書のようなものなので、ある程度プロトコルの中身を知ってる前提。ユーザ視点では「ベータ開始当初の目標は一部未達成で、まだちゃんとベータ」「来年頭に連合開始予定」くらいの認識で良いと思う。
ハンドルアンチを名乗っている割にあんまり具体的な話をしていなかった気がするので、ハンドルという機能が持つ課題を一旦まとめておく。正直に言えば、一時期カスタムハンドルがアカウントの検証手段として過剰に期待されていたことに対する逆張りの気持ちも大いにあるが、それは別として現状のハンドルに対する問題意識を明文化したい。
念の為書いておくと、atprotoの現状理解を整理する一貫として書いているのであって、これらの問題を解決するような仕様変更を求めるつもりはない。
PLCサーバーはDID毎に全てのoperationを保持しており、外部に提供する。これは単に履歴が追えるとか帳簿をつけているとかいうだけの話ではなく、もっと厳密な検証ができる。
operationはrotation keyの持ち主(通常はPDS)が発行するもので、主に直前のoperationのハッシュとPLCサーバーに対する操作、およびそれに対するrotation keyによる署名が含まれている。rotation keyの公開鍵の登録や変更もoperationによって行うため、operation logを辿っていけば各署名の検証に使うべき鍵も分かる。各operationの署名を検証することでoperationの正当性を、ハッシュを検証することでoperationの連続性を確認できる。
NewerOlder