分散型SNS、NostrとATProtocolのちがい
[!NOTE]
shreyan - Nostr and ATProto を参考に書いています。英語が読める人はこっちを開いたほうが早いです。
前提、共通の祖先 SSB
Nostr も ATProto も Secure Scuttlebutt を参考に作られています。ニュージーランドのヨット乗りが考案したプロトコルです。名をドミニク・ターといいます。沖に出てオフラインになっても使える SNS です。
P2P で、たまに通信が繋がったときまとめて通信します（ゴシッププロトコル）。ブロックチェーンでできています。
Nostr と ATProto の比較
| 項目 | Nostr | ATProto |
|---|---|---|
| アイデンティティ | 公開鍵と秘密鍵のペア。 | DID。 DID ドキュメントには、ユーザーの公開鍵とデータのホスト先（PDS）へのリンクが含まれています。 |
| データ | イベント。個別に自己完結した単位です。 すべて公開情報で、投稿単体で扱います。 デジタル署名により、複数の場所にホストしてもアイデンティティが一貫しています。 | リポジトリ。ユーザーデータが格納されています。 すべて公開情報で、ユーザーのすべてのデータを一貫してコピーできます。 デジタル署名により、他の場所に複製してもアイデンティティが一貫しています。 |
| 信頼 | 最小化が原則です。唯一の例外を除き、誰も信頼しません。 クライアントは、リレーから受信したイベントの整合性と信頼性を検証する責任があります。 ユーザーは署名者（多くの場合、ブラウザ拡張機能）を監査し、完全に信頼する必要があります。 署名者が信頼できない場合、すでに手遅れです。アイデンティティを破棄する必要があります。 | それぞれのコンポーネントに、一定の信頼を置きます。 ユーザーは PDS や DID 公開台帳（DID PLC）を監査し、一定の信頼を置きます。 PDS が信頼できない場合、ユーザーは回復鍵で DID ドキュメントを更新して PDS を切り替える必要があります。 DID PLC が悪意を持つ場合、PLC はまったく応答しないか、不正だと検証できる応答を行います。 ユーザーはアイデンティティを破棄するか、別の PLC 実装に再登録を行う必要があります。 |
| 信頼 | 複雑なクライアント実装が必要です。 信頼の必要性を排除することを目指しています。これはクライアント側の検証に大きく依存しています。 | ユーザーは依然として PDS を選択・信頼する必要があります。 |
| 開発 | より分散化されています。 開発者は自由に実験を行って、実装が広まればプロトコルとして標準化されます。 | より中央集権的で慎重な開発プロセスです。 Bluesky 社がプロトコルの方向性を導き、コミュニティからのフィードバックを募集しています。構造化された変更が重視されます。 |
| アプリケーション | クライアント実装の複雑さが増し、大量のデータを扱うことが難しい可能性があります。 リレーとクライアントの両方の実装によるフィルタリングに依存しています。 | クライアントの負荷を軽くできますが、単一障害点を招く可能性があります。 データをインデックスする集中型のサーバー（AppView）を利用します。 |
Zooko の三角形
識別子の 3 つの望ましい特性です。ほとんどすべてのシステムは、いずれかを犠牲にせざるを得ません。
- 人間にわかりやすいこと（覚えやすく使いやすいこと）
- 安全であること（許可されていないユーザーが ID を不正利用できないこと）
- 分散していること（特定のサーバーや機関に依存しない方法で識別子を管理できること）
Nostr と ATProto は安全と分散を実現しています。特定のサーバーに恒久的に紐づかない ID を採用しています。データをデジタル署名によって検証可能にしています。
人間にわかりやすいか
- Nostr: わかりにくいです。最大限の分散化を優先しています。サーバーを一切介在させません。
- ATProto: わかりやすいです。利便性を優先しています。鍵ペアをサーバー（PDS）に置き、鍵管理の煩雑さを軽減しています。