Bitsocial と Nostr
Nostr は、フェデレーション型にもブロックチェーン型にもきれいには収まりません。利用者はインスタンスからアカウントを発行されるわけではなく、チェーンもコンセンサスもガスもグローバルな順序もありません。Nostr は リレーベースのソーシャルメディア と表現するのが適切です。利用者は鍵ペアを持ち、イベントに署名してリレーへ公開します。リレーは、それらを保存して配信する普通のサーバーです (NIP-01)。Nostr 自身の README も、ピアツーピアの技術には依存していないと述べています。
そのため Nostr は、ある重要な点でフェデレーション型やブロックチェーン型のシステムよりも Bitsocial に近いと言えます。アイデンティティが暗号学的で、持ち運べるという点です。違いは、データ層と、誰が関門を握っているかにあります。
Nostr の仕組み
- イベントとリレー。 投稿、プロフィール、リアクションはどれも署名付きの JSON イベントです。クライアントは WebSocket 経由でイベントをリレーへ公開し、フィルターを指定して購読します。リレーはイベントを保存し、要求に応じて返します。リレー同士は通信しません。
- 複製。 利用者はふつう複数のリレーに公開します。2023 年に 712 のリレーを調べた研究では、平均的な投稿は 34.6 のリレーに存在していました (Wei と Tyson)。
- 誰かの投稿を見つける。 利用者は自分が書き込むリレーと読み込むリレーの一覧を公開し (NIP-65)、クライアントはその利用者の書き込み用リレーから投稿を取得します。
- アイデンティティ。 各利用者は 1 つの secp256k1 鍵であり、Schnorr 署名で署名します。仕様には鍵のローテーションや復旧が定められていないため、鍵を失えばアカウントも失います。任意の
name@domain識別子 (NIP-05) は、そのドメインの Web サーバー上にあるファイルと照合して確認されます。 - グループ。 推奨されるコミュニティの仕組みは、リレーベースのグループ (NIP-29) です。リレーがグループをホストし、投稿を受け入れる前にメンバーシップと投稿のルールを適用し、グループのメタデータに署名します。以前からあるモデレーター承認制のコミュニティ (NIP-72) は、現在は NIP-29 を優先して非推奨とされています。
- スパム対策。 関門はリレーごとに選びます。プルーフオブワーク (NIP-13)、認証と許可リスト (NIP-42)、支払い、レート制限などです。クライアントはミュートリストと信頼スコアを加えます。
- メディア。 画像と動画は、別の HTTP ファイルサーバーにアップロードされます。
どこが違うのか
誰が投稿を保存し、配信するか
Nostr では、リレーが保存と配信の層です。サーバーが各投稿をオンラインに保ち続けなければなりません。Bitsocial では、HTTP ルーターはクライアントがピアを見つける手助けをするだけです。ルーターは投稿もプロフィールもコミュニティのメタデータもモデレーションの状態も保存せず、クライアントはコミュニティのノードと、そのコミュニティをシードするピアからコンテンツを取得します。ピアツーピアプロトコル を参照してください。
誰が関門を握るか
Nostr では、書き込みの関門を握るのはリレーの運用者です。NIP-29 のグループ以外では、あるリレーに拒否された鍵でも、受け入れてくれる任意のリレーに同じイベントを公開できます。読者に何が見えるかは、そのクライアントがどのリレーを読むかで決まります。NIP-29 のグループは Bitsocial のコミュニティに近く、ホストするリレーが投稿を受理または拒否します。それでも、グループの役割に何ができるかを定めるのはリレーであり、別のリレーが引き継ぐことに同意しない限り、グループの履歴はそのリレーに結びついたままです。
Bitsocial では、コミュニティは独自の鍵ペアを持つ暗号学的なオブジェクトです。コミュニティのノードは所有者が選んだ任意のチャレンジを実行し、受理した状態をピアツーピアネットワークへ公開します。カスタムのスパム対策チャレンジ を参照してください。
インフラの運用
リレーはドメインと WebSocket エンドポイントを持つサーバーであり、人気のあるリレーは、配信するデータのストレージと帯域幅のコストを負担します。前述の 2023 年の研究は、無料リレーの約 95% が寄付ではコストをまかなえないと推定しました。Bitsocial のコミュニティノードは一般向けのハードウェアで動き、コミュニティを読むピアがその共有を手伝えます。
ブラウザ
Nostr の Web クライアントはリレーへ直接 WebSocket 接続を開くため、アプリサーバーは必要ありません。Bitsocial の Web アプリはタブの中でピアツーピアノードを動かし、ピアからコンテンツを取得します。ブラウザ ピアツーピア を参照してください。
古いコンテンツ
Nostr の投稿は多くのリレーに広く複製されるため、古い投稿が残りやすくなります。Bitsocial はコミュニティの最新の状態を保持しますが、古いコンテンツが永久に残ることは保証しません。
比較
| 論点 | Nostr | Bitsocial |
|---|---|---|
| 分類 | リレーベースのプロトコル | ピアツーピアのコミュニティネットワーク |
| アイデンティティ | secp256k1 の利用者鍵。仕様にローテーションの定めはない | 利用者とコミュニティの Ed25519 鍵ペア |
| 投稿の保存場所 | 投稿者が選んだリレー。多くの場合は複数 | コミュニティ所有者のノードと、そのコミュニティを読んでシードするピア |
| 誰が公開を維持するか | リレーの運用者 | コミュニティ所有者のノードと補助のシーダー |
| コミュニティ | リレーがホストするグループ (NIP-29) | 自身のノードが投稿を受理または拒否する第一級のオブジェクト |
| スパム対策 | 各リレーのポリシー。プルーフオブワーク、認証、支払い、許可リスト、レート制限 | 投稿が受理される前に課される、各コミュニティのチャレンジ |
| モデレーション | リレーのポリシー、クライアントのミュートリスト、ラベル、通報 | コミュニティ所有者が自分のコミュニティをモデレートし、何を表示するかはアプリが選ぶ |
| 名前 | HTTPS で確認される任意の name@domain 識別子 | 鍵に解決される .bso と .eth の名前 |
| ブラウザ | リレーの WebSocket クライアント | 通常のブラウザタブ内で動くピアツーピアノード |
| 主なトレードオフ | アイデンティティを持ち運べて複製も広いが、可用性とポリシーはリレーに依存 | リレーへの依存は少ないが、古いコンテンツが永続する保証はない |