今回は、分散型SNSのBlueskyに使われているAT Protocolについて勉強し"ながら"つらつらと書きたいと思います。

AT Protocol はこちら

AT Protocol は Authenticated Transfer Protocol の略称で、大規模な分散型ソーシャルアプリケーションのためのプロトコル

それぞれの個人には@から始まるドメイン名が与えられます。Twitterのアカウントみたいに

ユーザのデータは全て署名された Data repositoriy に保存され、複数の Repository をまとめたPersonal Data Server ( PDS )があります。PDS 同士でデータの同期を行います。

"Lexicon" と呼ばれるスキーマネットワークを使ってAT Protocol の動作を行います。つまり関数みたいなもの？？

Lexicon で内容のみを交換することで、ドキュメント単位でのやり取りが必要なくなります。Webとは違ってデータのみの交換。イメージとしてはAPIみたいな感じかなぁ。

AT Protocol は small network と big network で構成されています。 small network は特定の個人について、big network はその個人の外側の相互的な活動を集約します。

• Small-world: delivery of events targeted at specific users such as mentions, replies, and DMs, and sync of datasets according to follow graphs.
• Big-world: large-scale metrics (likes, reposts, followers), content discovery (algorithms), and user search.

PDS が small network を担当して、small network をクロールする indexing services が big network を担当します。

network を分けるのはユーザの高い選択性を意図しているとのこと。見たいものを選べるってことかな

web サービスと同様に Indexers を自由に選択できます。コンテンツ等はサードパーティーサービスによって提供されつつもPDSに統合されます。どんな情報もPDSに格納されるってことかしら

ユーザデータは署名された PDS に登録され、DID によって検証される。DID はユーザ証明書の登録機関で、TLSの証明書システムに似ています。ユーザーのPDSから独立していることが期待されています。DID document の中に署名の鍵などが登録されているようです．

DID Document には Signing key と Recovery key の2種類の公開鍵が登録されています。Signing key は DID Document と ユーザの Repository への変更を証明します。 Recovery key はDID Document への変更を証明し、72時間以内であれば Signing key の上書きができます。

Sigining key は PDS で管理し、Recovery key は ユーザ自身で管理します。これによってユーザ自身がPDSのホストに頼らず、新しいPDSにユーザデータを移行できます。

クライアント側に容量の許す限りユーザデータのバックアップが行われます。PDSが予告なく消えた場合でも新しいPDSに自信DIDとユーザデータをアップロードできます。

ATP (AT Protocol) は Speech と Reach の2つのレイヤーに分かれています。Speech レイヤーでは中立的で権限は分散され誰でも発信できるようデザインされています。Reach レイヤーは Speech レイヤーの上に存在し、柔軟性と拡張性を持たせて構築されます。

「Speech レイヤーはWebページ、Reach レイヤーは検索エンジン」みたいな感じですかね?

「Speech レイヤーはWebページ、Reach レイヤーは検索エンジン」みたいな感じですかね?

そうみたいですね。

The base layer of ATP (Personal Data Repositories and Federated Networking) creates a common space for speech where everyone is free to participate, analogous to the Web where anyone can put up a website. The Indexing services then enable reach by aggregating content from the network, analogous to a search engine.

AT Protocol は ATP とも @-procotol とも略されるみたいです。@-protocol 好きです。

＠-protocol の v1 は主に5つの仕様で構成されています。

• Authenticated Transfer Protocol
• Cross-system RPC (XRPC)
• Lexicon Schemas
• NameSpaced IDs (NSIDs)
• DID:Placeholder (did:plc)

いや，＠-protocol == AT Protocol でいいのか？

とりあえず仕様を1つずつ見てみます。
まずXRPCから行きますかね．．．

XRPC

XRPC は 全般的な目的をもつ server-to-server のメッセージングプロトコルです。

XRPC は ATP のために作られましたが、ATP 特有のものは含まれていないため、複数のユースケースに適用できる汎用的な通信レイヤーです。

XRPC には4つの特徴があります。

• Contract-oriented: XRPC の Method は全て入力と出力を定義するスキーマによって宣言されます。スキーマは機械が読めるドキュメントとして公開されます。
• HTTP-based: XRPC の Method は、動作に応じて GET または POST メソッドを使用し、HTTP/S を使用して転送されます。
• Cacheable: XRPCの"クエリ" Method は、一般的な HTTP ベースのキャッシュ技術でうまくキャッシュできるように設計されています。
• Support for multiple encodings: XRPCは構造化データ (JSON) および非構造化バイナリ Blob をサポートしています。

XRPC は server-to-server と client-to-server のメッセージングをサポートしています。それぞれのユーザは PDS を持っており、PDS がネットワーク上のエージェントの役割をはたします。

XRPC の Method には以下の特性がふくまれています。

• ID: The ID of the schema for the method's inputs and outputs.
• Type: Query (non-effectful, cacheable) or Procedure (effectful, non-cacheable).
• Parameters: Encoded in the URI query segment. Affects caching.
• Input: The request body.
• Output: The response body.

Method の呼び出しは、リクエストのID, Parameter, Input, および特定のHTTPヘッダーを指定する必要があります。戻り値もHTTPレスポンスに関する何らかの情報を提供しなければなりません．
XRPCは、APIで使用する場合、HTTPのセマンティクスを完全に抽象化するものではありません。抽象化とは？

ID は NSID を用いて識別されます。
例

com.example.status()
io.social.getFeed()
net.user.blob.ping()

Method schemas は Lexicon Schema Documents を用いた JSON でエンコードされます。

Method の shema はネットワークからアクセス可能かつ機械が読めるよう設計されています。現在ではネットワークから利用可能であることは必須ではありませんが、Method の利用者が単一の標準的かつ権威のある表現ができるように shema を後悔することが強く推奨されます。

schema を取得するには組み込みの getSchema を使用してください。このリクエストでは NSID の権威に送信されます。

getSchema についてのドキュメントは 2023/03/12 現在では整備されていない模様です。(TODO とだけ書かれています。)

Method type が Query の場合は GET，Procedure の場合は POST を使用します

次は NameSpaced IDs (NSIDs) にします

NSIDs

NameSpaced IDs (NSIDs) は ATP 全体で methods, record type, その他 sematic information を識別するために使用されています。

NSIDs は Reverse Domain-Name Notation を使用し，最終セグメントより前のセグメントは有効なドメイン名に対応する必要があります．
example.comの所有者は com.example.fooを使用できますが，foo.example.comも管理下に置かない限りcom.example.foo.barは使用できません．
これらのルールにより schemas はユニークであり，登録されたドメインに対して明確に権限が対応すること、リクエストが潜在的に解決されることを保証します．

それぞれの NSIDs は 1つの Authority によって管理されます。( com.example.foo は example.com が管理 )
全ての Authority には階層や関係はありません。 example.com と foo.example.com は完全に独立した Authority であるとみなされます。

最後はDID Placeholder (did:plc)ですね

DID Placeholder (did:plc)

DID Placeholder は暗号化され、強い整合性を持ち、回復可能な DID メソッドです。

そもそも DID ってなんですかね。

DID は Decentralized Identifiers の略称で日本語にするなら分散型識別子ですかね。
(ここ)[https://www.w3.org/TR/did-core/#introduction]に詳しく載っているみたいです。
グローバルにユニークな識別子の一種であり、検証可能かつ永続的であり集中型レジストリを必要としないエンティティの管理方法みたいです。
後々詳しく学びたい。

どうやら現行の DID に満足できないために新しく DID Placeholder を作ったみたいです。

DID の仕様に従ってはいますが、完全なものではありません。ドメインに特化しており、特定のデータ型を特定の方法で表現できるに過ぎません。今後、より汎化される可能性があります。

現状では各 DID document はたった4つのデータで構成されています。

• Signing key
• Recovery key
• username
• atpPds (ATPのPDS)

DID document は PLC サーバーによって順序付けられた署名された操作のログから生成されます。

それぞれのログには5種類の操作があります。

• create
• rotate_signing_key
• rotate_recovery_key
• update_username
• update_atp_pds

それぞれの操作は以下の形をしています

type Operation = {
  type: string // operation type
  prev: CID | null // pointer to the CID of the previous operation in the log
  sig: string // base64url encoded signature of the operation
  ... // other operation-specific data
}

各操作はログ内での直前の操作への参照を含んでおり、signing key もしくは recovery key によって署名されています。

DID 自体はそのログの最初の操作の sha256 hash から派生します。その後 base32 でエンコードされ、24文字に切り詰められます。
例:

`did:plc:${base32Encode(sha256(createOp)).slice(0,24)}`

操作は PLC サーバによって証明され、順序づけられ、利用可能になります。

PLC サーバの、その機能に制約があります。操作ログはその順序以外は自己証明しています。そのため、PLC サーバの攻撃は以下2つに限定されます。

• Denial of service: 有効な操作を拒否したり、DID に関する情報を提供しない
• Misordering: DID document の履歴に分岐があった際に間違った分岐を提供することができる

Signing and Recovery Keys

Sigining Key と Recovery Key はどちらも DID document に変更を加えられますが，同一ではありません。

Signing Key にのみassertions、 invoke/delegate の機能がある。一方でRecovery Keyは Recovery 操作にのみ使用できる。

Account Recovery

The PLC server provides a 72hr window during which the recoveryKey can "rewrite" history.
PLC サーバは、Recovery Key が履歴を「書き換える」ことができる 72 時間の猶予を提供します。

これは、ユーザの Signing Key が漏れたり、悪者であることが判明した custodian によって保持されているような敵対的な状況で使用されるものです。

このような状況では、Recovery Keyは Signing Key と Recovery Keyの両方を rotate させるために使用されるかもしれません。

このような状況から回復したい場合、ユーザは Signing Key を自分が保持する鍵に rotate する新しい操作に署名し、その操作の prev を最新の攻撃前の操作を指すように設定します。

とりあえず一通り理解したつもりではありますがまだ「ATP完全に理解した」って感じです。実際に何か作ってみて初めてちゃんとわかる気がしますね...

最後に Bing 君に「AT Protocol って何？」と聞いてみたいと思います。

AT Protocolは、大規模な分散型ソーシャルアプリケーションのためのプロトコルです。ユーザーは、署名されたデータリポジトリでデータを安全に交換したり、サーバーの関与なしに新しいパーソナルデータサーバー（PDS）にアカウントを移行したりできます。
AT Protocolは、Blueskyという組織が開発したネットワーク技術であり、最新の分散技術のアイデアをシンプルで高速でオープンなネットワークに統合しています。
AT Protocolはどんなことに興味がありますか？

すごいなぁ...

「AT Protocolの仕組みを教えてください。」

AT Protocolの仕組みは、ウェブが文書を交換するのに対して、スキーマやセマンティックな情報を交換するというものです。これにより、異なる組織のソフトウェアが互いのデータを理解できるようになります。AT Protocolのクライアントは、サーバーとは独立してユーザーインターフェースを作成できる自由度を持ち、コンテンツを閲覧する際にレンダリングコード（HTML/JS/CSS）を交換する必要がなくなります。
AT Protocolは、分散型ソーシャルネットワークと呼ばれるものであり、AT Protocolを使っているどんなサービスともつながることができます2。また、表示される内容や順序に関するアルゴリズムを自分で選択できます。
AT Protocolはどうやってプロセス間通信（IPC）を行っているのかご存知ですか？

「AT Protocolは署名されたデータリポジトリやXRPCという技術を使ってIPCを行っています。」

そうですね。AT Protocolは、データの完全性や信頼性を保証するために、データリポジトリに署名を付けています。また、XRPCという技術を使って、異なるシステム間でリモートプロシージャコール（RPC）を行っています。
AT Protocolに関する質問は他にありますか？

「AT Protocolの利点や欠点は何ですか？」

AT Protocolの利点や欠点については、以下のようなものが考えられます。
利点：
ウェブとは異なり、データのスキーマやセマンティックスを交換できるため、異なる組織のソフトウェアが互いのデータを理解できる。
サーバーとは独立してユーザーインターフェースを作成できるため、コンテンツの表示に関する自由度が高い。
分散型ソーシャルネットワークとして、どんなサービスともつながれるため、ユーザー間のコミュニケーションが容易になる。
アルゴリズムを自分で選択できるため、コンテンツの順序や優先度に関するコントロールが可能になる。
署名されたデータリポジトリやXRPCという技術を使って、データの完全性や信頼性を保証し、異なるシステム間でリモートプロシージャコール（RPC）を行える。
欠点：
プロトコルの作成や適用には多くの労力や時間がかかり、医療分野などではプロトコルに従うことが必ずしも最善ではない場合もある。
HTTPと比べて、ウェブソケット接続は初期化に時間がかかり、サーバー側で多くのリソースを消費する可能性がある。
HTTPと同様に、ポイント・ツー・ポイント接続しかできず、モバイルに最適化されていない。また、プッシュ機能や信頼性の高い交換（再試行ロジックなし）も提供していない。
AT Protocolについてもっと知りたいですか？

Webソケットなんて使ってましたかね...これは私の勉強不足..？

「AT Protocolの将来性について教えてください。」

AT Protocolの将来性については、以下のようなことが言えるかもしれません。
AT Protocolは、Twitterの分散型プロトコルとして開発されたものであり、TwitterはAT Protocolを使ったアプリケーションを作成しています。これは、異なる種類のソーシャルネットワークへの一歩となる可能性があります。
AT Protocolは、Blueskyという組織によって作られたものであり、Blueskyはソーシャルプロトコルを構築することを目的としています。AT Protocolは、最初の試作品であるADXから改良されたものであり、今後もさらに発展していく予定です。
AT Protocolは、ウェブが文書を交換するのに対して、スキーマやセマンティックな情報を交換するというものです。これにより、異なる組織のソフトウェアが互いのデータを理解できるようになります。AT Protocolは、ウェブに代わる新しいインターネット技術となる可能性があります。
AT Protocolに関する質問は他にありますか？

「いいえ、ありがとうございました」