Nostrの未来発展構想

Nostr の基本紹介#

Nostr は非常に軽量なオープンプロトコルで、「機会」（プロジェクト文書に基づく）として分散型ソーシャルメディアプラットフォームを目指しています。プロトコルの仕様は NIP（Nostr 改善提案）で定義されており、こちらで見つけることができます。

このプロトコルの基盤は、非常にシンプルなデータ構造であるEventを処理し保存する WebSocket サーバー（nostr-relay と呼ばれます）です。データ構造は以下のようになります：

{
"id": <32バイトのイベントデータのシリアライズされたsha256>
"pubkey": <イベント作成者の32バイトの16進数エンコードされた公開鍵>,
"created_at": <Unixタイムスタンプ（秒）>,
"kind": <整数>,
"tags": [
["e", <別のイベントのIDの32バイトの16進数>, <推奨リレーURL>],
["p", <鍵の32バイトの16進数>, <推奨リレーURL>],
... // 他の種類のタグが後で含まれる可能性があります
]
"content": <任意の文字列>,
"sig": <シリアライズされたイベントデータのsha256ハッシュの64バイトの署名で、「id」フィールドと同じ>,
}

イベントは常に署名され（Schnorr 署名を使用）、意味的な意味を持つ構造化データを含むことができます。BIP340 で定義された Schnorr タイプの XOnlyPubkeys（現在は Bitcoin Taproot と共に使用されています）は、プロトコル全体で「アイデンティティ」として機能します。

nostr-client は、nostr-relay と対話し、Subscription Filter を使用できるクライアントです。Events フィルターは、クライアントが興味を持つすべての nostr コレクションを表します。

クライアントは登録やアカウント作成を必要としません。クライアントは自分の公開鍵で識別されます。クライアントがリレーに接続するたびに、サブスクリプションフィルターを提出し、クライアントが接続している限り、リレーは「興味のあるイベント」をクライアントにストリーミングします。

リレーはクライアントのサブスクリプションをキャッシュできますが、必須ではありません。クライアントは「クライアント」で全てのことを処理すべきであり、リレーは石のように鈍くても構いません。

クライアント同士は直接会話しません。しかし、リレーはできます。これにより、リレーはクライアントが持っていないデータを取得できます。クライアントは接続しているリレーの外のイベントをサブスクライブできます。

一見すると、Nostr はプロトコルとして無用であるという印象を与えます（なぜ単に署名して生の JSON をダンプし、クライアントに自分で理解させないのか？）が、より深い視点から見ると、「ダムサーバー、スマートクライアント」モデルは、特に分散型プロトコル設計においていくつかの大きなエンジニアリング上の利点を発見できます。

この文書は、これらの愚かなサーバー、スマートクライアント、ビットコインネットワーク、E2E 暗号化がどのように組み合わさって「分散型ソーシャルネットワーク」、DSN（私が思いついた流行語）の問題を解決するかを概説します。

問題の声明#

もしあなたが過去 2 年間岩の下で生活していなければ、現在の出現と「Twitter の代替品」を持つことへの強い要求を知っているでしょう。ユーザーの動機に反しないソーシャルメディアプラットフォーム。

この需要は、GabやMastodonなどの代替ソーシャルメディアプラットフォームを生み出しました。Ex Twitterの責任者の最近の声明は、これが次に解決すべき大きな問題であることを示唆しています。したがって、免責事項：私はこれが簡単に解決できる問題だとは言っていませんし、Nostr がすべての問題を解決できるとも思っていません。しかし、少なくとも「機会」はあります。

分散型メディアプラットフォームを作成する核心的な問題は技術ではなく、社会的なものです。

ソーシャルメディア（またはチャットアプリケーション）を作成することは、新しいソフトウェア開発者が直面する最も教科書的な挑戦かもしれません。システムの核心構造は非常にシンプルです。

物を保存するデータベース、
クライアントと対話するネットワークインターフェース
クエリデータを迅速に取得するためのいくつかのフィルタ。

もちろん、現実の生活でははるかに複雑です。しかし、この設計の鍵はすべてのソーシャルメディア設計にとって同じです。それなら、なぜ私たちはそれを構築して完成させることができないのでしょうか？

問題は、それが「分散型」システムでなければならず、「ネットワーク効果」と開発者エコシステムによる一連のプロトコルに対する新興のエンジニアリングコンセンサスが成功の鍵であるということです。さもなければ、私たちは解決しようとしているのと同じ問題を作り出すことになります。

ここで事態が混乱します。もし今日完璧なソーシャルメディアを構築した場合、他の開発者にその上に構築するようにどうやって説得しますか？もし開発者が機能を構築しなければ、ユーザーはなぜ来るのでしょうか？ユーザーが来なければ、そのメディアプラットフォームの意味は何でしょうか？

Gab と Mastodon の例は明確に示しています。コードをオープンソースにするだけでは不十分です。標準の構築プロセスと設計も公開されなければなりません。さもなければ、一人の人間が少数の人々になり、大多数の人々が自発的に過激なプロジェクトに従事し、最終的にはそのプラットフォームの「慈悲深い独裁者」となるでしょう。

彼らはそのようなプラットフォームの現実的な設計制約を満たす必要があるため、彼らの製品を大規模に提供するために、最終的には特別に設計されたプラットフォームアプローチの小さなチームを作成しました。これにより、クライアント開発者がそのプラットフォームのカジュアルで楽しいアプリケーションを使用するのが難しくなります。ある時点で、彼らは自分たちの小さなプロトコルを設計することを決定するかもしれませんが、最終的には同じ障害に直面します。誰も特定のニッチ市場のために設計されたプラットフォームの上に自発的に構築したいとは思わないのです。

データを保存するコストも非常に高いです。「サーバー所有者」はリソース、メンテナンス、時間を必要とします。現在 Mastodon インスタンスをホストしているすべての人は自発的にそうしており、ユーザーは単に彼らの親切に依存しているだけで、インスタンスが閉じられることはありません。「知識共有」という長年の問題が浮上します。

それでは、私たちはもっと良いことができるのでしょうか？

別のアプローチ、愚かな Nostr アプローチ#

もし私たちが完璧なソーシャルメディアを構築するのではなく、そのようなものを作成するために必要な最も基本的なレゴブロックを構築し、開発者がこの基本的な標準ユニットに基づいて自然に合意に達することができたらどうでしょうか？

これが Nostr が行っていることです。

そのために、次のアプローチを採用しています。

ソーシャルデータフォーマットの最小単位（Event）を指定し、開発者間で自然に合意に達することを促進します。これがプロトコルの核心を定義します。誰もがそのネットワークの一部になるために合意する必要がある最低限のバックボーンです。

Nostr はこれらのプロトコルルールを NIP として定義します。そして、実装が必要なルールのセットである mandatoryNIP に言及します。

これらの mandatory NIP の上に、optional として誰でも NIP を定義できます。リレーは、彼らがサポートする NIP セットを自由に選択できます。

将来の NIP でより多くのタグ項目を定義することで、Event は現場でデータを拡張できます。tag

AnEvents を汎用データストレージとして見ることができます。そこに入れることができる内容には制限がありません。

奇妙に思えるかもしれませんが、既存の多くの「精巧に設計された」代替ソーシャルメディアと比較して、このようなシンプルなプロトコルはより多くの開発者の関心を集めています。

このプロジェクトは開発者の大きな関心を引き起こし、コミュニティはほぼすぐにライブラリ、アプリケーション、リレーを含む豊富なエコシステムを開発しました。そして、このリストは日々増加しています。

Telegram のチャットルームには約 400 人のメンバーがいて、毎日増加しています。

なぜでしょうか？「それが非常にシンプルだからです」。

このシンプルさにより、興味のある誰もが簡単に JSON ストリーミングを作成し、プロトコルを任意の既存のリレーと対話させることができます。

こちらで現在稼働中の Nostr リレーのリアルタイムリストを見つけることができます。

すでに進行中の Twitter に似たアプリケーションが 2 つありますbranleとNOSTR-twitter。

人々は基本的な NIP の上に新しい追加の詳細をほぼ定期的に追加しています。

このプロトコルのシンプルさは、開発者がオープンスタンダードに迅速に収束し、すべての複雑さをクライアントに置くことを可能にします。アプリケーション全体の体験はクライアントによって処理され、リレーはダムデータサーバーとして機能します。これにより、開発者はクライアントアプリケーション上で迅速に移動し、イテレートできる一方で、任意の利用可能なリレーと互換性を保つことができます。

これにより、クライアントの互換性も向上します。異なる 2 つのアプリケーションがあっても、お互いの投稿を見ることができます。このプラットフォームの核心は分散型であり、クライアントはシンプルなストレージプロトコルを介して互換性を持っています。これが「ダムサーバー、スマートクライアント」モデルの巧妙さです。基本的な標準に迅速に合意し、優れたクライアントアプリケーションをより早くイテレートします。

クライアント層で複雑さをカスタマイズし、リレー層で相互運用性を実現できます。

欠けている部分#

私たちがコアレゴブロックの外観を理解したら、残りの部分は DOS 保護、リレーインセンティブ、ユーザー間で nostr サブスクリプションデータを伝達する方法です。

Nostr にビットコインを組み込む#

ビットコインのおかげで、リレーインセンティブと DOS 保護を一度に解決できます。

そのインフラストラクチャが脆弱な「自発的」基盤に依存している場合、強力なソーシャルネットワークを構築することはできません。私たちが知っているように、「製品が無料であれば、あなたが製品です」。これらの未来のメディアプラットフォームは、ビットコインにネイティブに統合されるべきです。

これを実現するためのワンストップソリューションは、BDKを使用することです。さまざまなビットコインインターフェースとデータベースを処理するのに十分柔軟な高性能ビットコインウォレットライブラリです。payment request と payment response イベントタイプを定義するためにいくつかの新しい NIP が追加されました。

彼らが発行する各イベントに対して、支払いは一度きりのオンチェーン取引であるか、クライアントとリレー間の一連の LN 支払いである可能性があります。（BDK + LDK は現在積極的に開発中です）。リレーは sats/byte 単位で料金を設定でき、もし彼らが「自発的」にしたい場合は、0 に設定することを選択できます。

これにより、高メンテナンスの公共リレーがそのサービスを通じて利益を得る方法が提供され、同時に DOS 攻撃から保護されます。

エンドツーエンド暗号化サブスクリプション共有#

Nostr リレーは単なるシンプルな JSON データのダンプであることを忘れないでください。subscription フィルターを介して取得されます。これにより、nostr はクライアント間の汎用データ共有プラットフォームになります。ビットコインがあれば、私たちが話しているのは、nostr リレーネットワークを介して共有されるビットコインスクリプト、記述子、DLC 契約、その他のビットコイン DeFi 情報です。しかし、これらは敏感な情報であり、公共のプラットフォームで平文で共有すべきではありません。

そのためには、暗号化された nostr サブスクリプション共有メカニズムが必要です。これは、参加者間の暗号化されたサブスクリプションデータ共有を促進する別のサーバーである可能性があります。

これを次の方法で実現できます：

期待される受信者の公開鍵から派生した DH 共有秘密を使用して [subscription+] を暗号化します。relay-addres
暗号化されたデータを受信者の公開鍵と共にこのサーバーに公開します。
受信者クライアントは通知を受け取り、データをダウンロードして解読し、nostr から実際のデータを取得するためのサブスクリプションを取得します。
実際のデータも同じ共有秘密で暗号化された暗号文であるため、受信者はそれを解読する方法も知っています。

これらのサーバーは非常に軽量である可能性があります。なぜなら、彼らはすべての履歴サブスクリプションデータを保存する必要がないからです。彼らは定期的に古いデータをクリアし、受信者がダウンロードした後にリアルタイムでクリアすることさえできます。これにより、彼らのコストは非常に低くなり、インセンティブの問題を解決する必要がありません。

これらのサーバーは、共通のプロトコルに従う必要はありません。任意の設計で自由に実装できます。彼らはクライアントに接続する方法を持ち、彼らに関連することが発生したときに通知する方法を知っている必要があります。

彼らは nostr リレーのように検閲に強いです。もし一つが故障したり停止したりした場合、誰でも別のものを立ち上げることができます。彼らは履歴を保持する必要がないため、一つのサーバーから別のサーバーに切り替えても全体の情報フローには影響しません。

これらのサーバーはデータを利用することもできません。なぜなら、彼らが見るのはランダムな暗号化された blob だけだからです。そのため、彼らは高度なセキュリティを必要としません。

最終的な画面#

したがって、これらすべてを組み合わせると、Nostr、ビットコイン、暗号化されたサブスクリプション共有により、参加者間でデータを共有するための非常に強力でデフォルトのプライベートソーシャルネットワークが得られます。

これにより、人々の隠れたソーシャルネットワークが特定の信頼できるエンティティに対して彼らの投稿を選択的に開放する可能性が生まれます。

これらの投稿は、DLC 契約、複数の当事者間のマルチシグの記述子、サブスクリプションメンバーにのみ公開される DLC オラクルなどである可能性があります。

このフレームワークにおいて、「アイデンティティ」の基本単位は公開鍵です。公開鍵は現実世界の別名に似ています。誰でも任意の数の別名を持つことができます。もし一つの別名が漏洩した場合、彼らはすぐに別のものを作成できます。まるで私たちが各支払いのために新しいビットコインアドレスを作成するように。

公開鍵を別名として使用することで、あなた自身のプライベートな信頼できるネットワークに選択的に開放することができます。あなたは一つの公開鍵をあなたのグローバルな別名（広く知られている Twitter ユーザー名）に関連付け、その後、特定の人々の間でのみ通信するために任意の数の平行な別名を使用することができます。

これらすべての公開鍵に関連するデータは完全に無関係であり、複数の nostr リレーに分散することができます。

最終的にまとめられるモデルは：

高度に相互運用可能で非常にシンプルなリレープロトコル、nostr。
optional リレーが選択的に参加できるアップグレードを使用して新しいリレー機能を追加するための柔軟なフレームワーク。
nostr サブスクリプションを伝達するための暗号化されたサブスクリプション共有メカニズム。
ビットコインのネイティブ統合、同時に「通貨インターネット」と DOS 保護を促進。
クライアントが公共およびプライベートコンテンツを発表するための分散型発行層。
これらのコンテンツを解釈するクライアントの複雑さと、ビットコイン機能を使用するためのローカル金融契約生成 UI。

web3.0 のすべての内容とは異なり、これは別の「ブロックチェーン」を含むものではありません（私はこれがひどいことだと知っています）。

前進の道#

良さそうに聞こえますが、私たちはまだそれを実現していません。そして、これらの夢を実現するためには、大量のエンジニアリング設計が必要です。前方には未知の問題が待っています。これらのリレーとクライアントの設計決定は慎重に計画する必要があります。単にシンプルなプロトコルがあるだけでは不十分です。

これらのリレーは効率的で堅牢であり、公開の場で厳格な同行レビューを受け、基本的なセキュリティレベルが保証される必要があります。この作業は公開で行われる必要があり、要素の設計は可能な限り柔軟であり、さまざまなクライアント開発者のニーズに応える必要があります。

もしこのものが、人々が自分のサーバーに展開できる専門サービスに拡張され、その上に重要な製品を構築するための基盤となる必要があるなら、私たちが必要とするのは、趣味のコードやサンプルアプリケーションだけではありません。

必要なのは、もう一つのクールな nostr アプリケーションではなく、深く考えられ設計されたインフラストラクチャライブラリであり、影のスーパーコーダーがそれを使用して「内部ビットコイン」を持つクールな nostr アプリケーションを構築できるようにすることです。

rust-nostr の紹介#

rust-nostr は、上記の問題を解決することを目的とした構想段階のプロジェクトです。このアイデアは、モジュール化され、拡張が容易で、強力なセキュリティ保証を持ち、開発者が自分のニーズに応じて簡単にカスタマイズできる完全なワンストップ nostr インフラストラクチャスイートを提供することです。非常に簡単にダウンロード、展開、サーバー内で管理できます。

全体の構造はまだ未定ですが、以下は rust-nostr の大まかな輪郭です。

バイナリボックスが nostrd を生成します。Nostr-Relay の軽量で効率的な Rust 実装。nostrd にはサポートされる NIP のセットが付属します。デフォルトでは基本的な NIP を含むことができます。ビルド時に機能フラグを使用して追加の NIP を指定できます。
nostr-cli は nostrd サーバー管理者として使用できます。また、他のリレーと nostr プロトコルで対話し、cli nostr クライアントとしても使用できます。メンテナンスアクセスは基本またはクッキー認証を通じてリレーに提供されます。
豊富な nostr-API ライブラリ。プロジェクトに含まれ、開発者が nostr クライアントを構築するためのシンプルな開発ツールとして使用できます。これらの API は ffi を介して他の言語に公開され、開発者にクールな Nostr クライアントを構築するためのワンストップツールが提供されます。
portal は暗号化された nostr サブスクリプション共有サーバーです。portal の仕様はプロジェクトの一部ではありません。なぜなら、それはすでに解決された問題だからです。これは暗号学文献でよく理解されており、オープンソースの中には多くの候補実装があります。Signal App 自体が portal の一例ですが、このユースケースには使いにくいです。インドのローカルチームは、CypherPost という p2p ビットコイン取引の特定のユースケースを促進することに焦点を当てており、これは非常に適切な portal 実装です。最終的には、プロジェクトリポジトリに簡略化された rust 候補実装が追加されます。しかし、人々は自分の portal を自由に開発し使用でき、ネットワークの他の部分と互換性を保つことができます。

これらすべて（portal を除く）は、BDK と LDK を介してネイティブビットコイン + Lightning に統合されます。

インフラストラクチャのすべての部分が常に相互に同期することを保証するために、彼らはプロジェクトの CI パイプラインで厳格な統合テストを行います。

これらすべてが配置されると、rust-nostr スイートを使用して、相互にビットコイン DeFi を行うさまざまなより複雑なクライアントを提案できます。

終わりの言葉#

ここまでのところ、これは単なる原始的なアイデアであり、私は未知の課題が何であるかさえわかりません。私は多くのことを期待しています。「細部が成功を決定する」と言われています。これは野心的なプロジェクトのように思えますが、実際にはそうではありません。

プロジェクトの範囲を制限して非常に具体的な構築ツールを提供することで、これはいくつかの積極的な Rust 開発者によって実現可能です。Rust はそれを構築するのに最も適した言語でもあります。なぜなら、コンパイラレベルでプロトコルルールを厳密に定義することを可能にし、エラーの余地を減らし、非常に簡潔で監査しやすいコードを生成するからです。

「製品」を作ろうとせず、単にレゴブロックを解決することで、私はこれが実現可能だと考えています。

その後、このプロジェクトはビットコイン起業家にさまざまなアプリケーションの道を開くことができます。アプリケーションスペースの制限は想像力だけです。

したがって、もしあなたがこの問題に関心があり、手を差し伸べたいと思うなら、または一般的な提案や意見がある場合は、Twitter で @rajarshimaitra に連絡してください。DM は開放されています。

翻訳：Hoodrh

原文住所