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 sigs を使用）、意味的な意味を持つ構造化データを含むことができます。BIP340 で定義された Schnorr タイプの XOnlyPubkeys（現在はビットコインの 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 として定義しています。そして、実施すべきルールのセットである mandatory NIP を言及しています。Nostr プロトコルについて議論するために必要なルールです。

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

将来の NIP でさらにタグ項目を定義し、Event は現場でデータを拡張できます。tag

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

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

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

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

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

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

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

すでに 2 つの進行中の Twitter のようなアプリケーション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 自体がポータルの一例ですが、このユースケースでは使用が難しいです。インドの地元チームは、CypherPost という p2p ビットコイン取引の特定のユースケースを促進することに焦点を当てており、これは非常に適切な portal 実装です。最終的には、プロジェクトリポジトリに簡略版の rust 候補実装が追加されます。しかし、人々は自分のポータルを自由に開発し使用でき、ネットワークの他の部分と互換性を保つことができます。

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

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

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

終わりの言葉#

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

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

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

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

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

翻訳：Hoodrh

原文住所