第五右派のもとでの新しいソーシャルメディアのデザインは何年にもわたって検討されてきたが、大量に採用される兆候はない。この 1 年、暗号化技術の継続的な開発とマスク氏の Twitter 買収に関する懸念により、分散型ソーシャル ネットワークは新たなチャンスをもたらしました。
これらのソーシャル ネットワークが解決しようとしている問題には、検閲の強化、コンテンツのモデレーションの柔軟性の向上、人々がオンラインで話す内容を形成および追跡する大手ソーシャル メディア企業の権限の削減などが含まれる可能性があります。
新しいプラットフォームが出現して成長するにつれて、代替ソーシャル ネットワークの選択には政治的な考慮が伴うことがよくあります。 Getr、Parler、Gab、Truth Social などのサイトはすべて、Twitter に代わる言論の自由を宣伝することで右派の要望に応えています。
今日私たちが議論するのは、Nostr-ダムス、最近大きな注目を集めている新しいソーシャルメディアプロトコルであり、やや革新的です。これらには、Nostr の技術原則、解決すべき主要な管理問題、リレーの動作継続を促す方法などが含まれます。
ノストルの概要
2020に発売、 私たちの は、ユーザーが自分の ID を所有し、公開鍵と秘密鍵の暗号化を使用したデジタル署名を使用して投稿を検証できるようにする分散型プロトコルです。これらの投稿は、相互接続されたサーバーのネットワークに伝播されます。このプロトコルはブロックチェーンを使用していませんが、初期の実験ではソーシャル ネットワークには遅すぎることが判明しました。しかし、構造的な類似点があり、ノストラはその自由主義とオープンソースの精神により、仮想通貨群の中で初期のニッチ市場を見つけました。
マストドン vs. ノストラ
Nostr プロトコルと最初のリレー サーバーは、2020 年後半に開発者 fiatjaf によって作成されました。広く注目を集める前は、Nostr は Twitter と Mastodon の問題に対する軽量なソリューションを目的とした、地味なニッチ プロトコルでした。
2016 年に設立されたオープンソース ネットワークであるマストドンでは、誰でもサーバーをセットアップできます。この設計はよく「フェデレーテッド」と表現されますが、それがどのように定義されるかによって、「Web3」という曖昧な境界線に収まる場合とそうでない場合があります。マストドンでは、ユーザーはカスタム コンテンツ モデレーション ルールを使用して厳選されたコミュニティに参加できます。現在、登録ユーザー数は 200 人以上に達し、リベラル派、ジャーナリスト、学者の安全な避難所となっています。
In Twitter および マストドン システム、アイデンティティ/ユーザー名は、サーバーを実行する人によって制御されます。
Nostr の主な違いは、各ユーザーがサーバー オペレーターが所有するユーザー名を使用するのではなく、公開キーと秘密キーのペアを使用して機能を処理することにより、Nostr が検閲に耐えられるようになっている点です。これは、Nostr プロトコル全体を構築するための中心的な構成要素の 1 つです。
イベント: これは、クライアントと、メッセージを送信および取得するために接続する中継サーバーによって使用される基本的なオブジェクト/データ タイプです。このプロトコルの一般的な概念は、クライアントがリレー サーバーにイベントを送信し、リレー サーバーがイベントを保存してインデックスを作成し、他のクライアントがリレー サーバーと通信して、受信して保存したイベントを要求できるというものです。原作では ニップ 01では、次の 3 つの異なるイベント タイプが定義されました。
- ユーザー名、写真、プロフィールなどのユーザーに関するメタデータを送信します。
- SMS と基本コンテンツを送信する
- イベントクリエイターをフォローしている人が接続する中継サーバーを推奨
すべてのイベントは、特別に定義された方法で構造化されます。作成者の公開キー、作成タイムスタンプ、タイプ (または仕様上の種類)、コンテンツ ペイロード、およびイベント作成者の署名が含まれます。あるいは、他のイベントまたはユーザーを参照し、作成者の署名を除くすべてのハッシュである ID 値を持つタグが存在する場合もあります (ビットコイン トランザクションの TXID と同様)。
これにより、ユーザーは署名 (および鍵が侵害されていない場合はその鍵の所有者) を検証して、そのメッセージがその中の公開鍵の所有者によって実際に作成されたこと、およびメッセージが署名以来変更されていないことを保証できます。それ。
ビットコイントランザクションは、署名後に無効化することなく変更できないのと同様に、ユーザーは、トランザクションの作成者が作成した後はトランザクションを変更できません。 私たちの イベントは、それを明らかな詐欺とすることなく署名しました。
イベント型システムはオリジナルから大幅に拡張 NIP。直接暗号化されたメッセージには、送信者の秘密キーと受信者の公開キーを組み合わせて共有秘密を構築するイベント タイプがあり、その結果は、送信者の公開キーと受信者の秘密キーを組み合わせて得られるものと同じになります。は同じです (これが BIP 47 とサイレントペイメントの仕組みです)。
置換可能なイベント タイプと一時的なイベント タイプもあります。置き換え可能なイベントの場合は (当然のことですが)、イベントの元の作成者が新しいイベントに署名して古いイベントを置き換えることができるように設計されています。この仕様に従う中継サーバーは、古いイベントをストレージから自動的に削除し、受信時に新しいバージョンのクライアントへの提供を開始します。
一時的なイベントは、リレーに送信されると、その作成者を購読しているすべてのユーザーにブロードキャストされるように設計されていますが、リレー サーバーはイベントを保存しないでください。これにより、オンラインにいる人だけがブロードキャスト中にメッセージを見る可能性が生じます。他の人のイベント (いいね! や絵文字など) に対する反応を表すイベント タイプもあります。
最後の質問に関して言えば、イベントにはタグを含めることもできます。現在、次のタグ タイプがあります。 イベント (正確な Nostr イベントを指します)、 公開鍵 (別のユーザーをタグ付けまたは参照するため)、および 件名 (電子メールの件名などの機能を模倣するため)。
これらすべてには、データがフェッチされる特定のリレー サーバーへのポインタを含めることができるため、ユーザーは実際に異なるサーバー上で対話できるようになります。つまり、ユーザーはリレー サーバー上で自分のコンテンツを公開し、そのコンテンツを別のユーザーが別のサーバー上で対話したり参照したりできます。これにより、ユーザーは、大量の複雑な操作に関連するデータがどこにあるかを見つける必要がなく、対話のスレッド全体を適切な順序で一貫して取得できるようになります。
原作では NIPでは、クライアントが受信したいイベントのフィルターを含むメッセージ/データ構造をサブスクライブすることによって、クライアントがリレー サーバーと対話する方法の仕様が与えられました。これらのフィルターでは、ユーザーの公開キー、正確なイベント、イベントの種類、さらには以前の基準に基づいて指定したい特定の期間を指定できます。
ユーザーは、公開キーまたは「1xjisj…」などのイベント ID のプレフィックスを送信し、その短い文字列で始まる公開キーから XNUMX つ以上のイベントを受信することもできます (これは、実際に見たいものを中継サーバーから隠すのに役立ちます) 。
全体として、このプロトコルは、ユーザー間でメッセージを渡すための非常にシンプルな一般的なスキームであり、メッセージの整合性の保証やメッセージ送信のための公開キー ID の使用などの重要なことをカバーすると同時に、エンド インフラストラクチャのリレー サーバーを高度に一元化したり、ユーザーが実行できるようにしたりすることも容易にします。ユーザーが 1 つのリレー サーバーの使用を禁止された場合でも、大規模な混乱を引き起こすことなく、シームレスに相互作用しながら、独自の個人リレー サーバーを構築できます。
別のサーバーに移動したり、独自のサーバーを実行したりできます。また、以前のサーバーからプラットフォームを切り離してもデジタル ID やフォロワーを失うことはありません。秘密鍵の管理は維持されており、ユーザーはその秘密鍵を他の場所で使用して認証できるからです。彼らがそれらを見つけたら。
リレー サーバーは、自由に動作させることもでき、メッセージの公開またはダウンロードに少額の料金を請求することもでき、メッセージの送信にハッシュ キャッシュ スタイルの Proof-of-Work を必要とする NIP を備えることもできます。
投稿をホストして他のユーザーのみが利用できるようにする単一のリレー サーバー、または Twitter や Reddit などの大規模に動作するサーバー (クライアントは必要に応じて情報を表示および整理できるため、あらゆるソーシャル メディアをシミュレートできます) にすることができます。これらはすべて、ユーザーをロックアウトすることなくシームレスに相互運用します。
Nostr が対処すべき主要な管理問題
ユーザーの公開鍵/秘密鍵は、Nostr がプロトコルとして機能する上で不可欠な部分です。これは、実際のユーザーと他のユーザーがユーザーを識別する方法との間の緊密な結びつきとして機能し、中継サーバーがこれら 2 つの関係を解くこと、つまり誰かの識別子を別のユーザーに与えることを防ぎます。また、このプラットフォームの最大の問題の 1 つである、ユーザー自身のアイデンティティを制御できないことも解決されます。
しかし、これにより新たな問題も発生します。鍵を紛失したり、漏洩したりする可能性があり、そのような事態が発生した場合、ユーザーは助けを求めることができなくなります。
これには必然的に、ユーザーが検証可能かつ発見可能な方法で、あるキー ペアから別のキー ペアに切り替え、プロトコルを通じて他のユーザーと対話するためのスキームが必要になります。プロトコル全体は、イベントが特定のユーザー (ID キー) からのものであることを証明することに基づいているため、誰かのキーが侵害されると、これらの保証はすべて無効になります。
Nostr では、あるキーのローテーションを別のキーに結び付ける実際の暗号化スキームが必要です。開発者 fiatjaf は、この問題を解決する可能性のある基本的な解決策を提案しました。基本的なアイデアは、Taproot ツリーがビットコイン キーにコミットされる方法と同様に、単一のマスター シードから派生したアドレスの長いリストを取得し、「調整された」キーのセットを作成することです。
Taproot は、Taproot ツリーのマークル ルートを取得し、それを公開鍵に「追加」して、新しい公開鍵を作成します。これは、そのマークル ルートを秘密キーに追加して、新しい公開キーと一致する秘密キーを取得することで複製できます。 Fiatjaf のアイデアは、コミットメントを最後から最初まで逆方向に連鎖させて、調整された各キーに、次に調整されたキーが作成に使用されたという証拠が実際に含まれるようにすることです。
したがって、チェーンの最後のキー Z から始めると想像してください。これを何かで微調整してから、戻って、調整されたキー Z を使用してキー Y の調整されたバージョンを作成できます (Z' + Y = Y')。ここから、Y' を取得し、それを使用して X を調整できます (Y' + X = X')。これをキー A まで繰り返し、A' を取得し、そこからそのキーを使用します。これが壊れると、ユーザーは未調整のキー A と調整後のキー B' を含むイベントをブロードキャストできます。
これには、B' が A' の生成に使用されたことを示すために必要なすべてのデータが含まれており、ユーザーはすぐに A' のフォローを中止し、代わりに B' をフォローすることができます。彼らは、B' がそのユーザーの次のキーであることを明確に知っており、代わりにそのキーに従います。
しかし、この提案にはまだいくつかの問題があります。まず、使用されるすべてのキーは事前に生成する必要があり、まったく新しいキーのセットにローテーションする方法はありません。これは、このローテーションを公証できるこのスキームにマスター キーをコミットするか、最初から非常に大規模なキーのセットを生成するだけで解決できます。
どちらの方法も実現可能ですが、最終的には、ルート キーまたはキーマテリアルを安全に保ち、個々のホットキー (ホットキー) のみを Nostr クライアントに公開する必要があります。
ただし、このスキームはユーザーを保護したり、ルート キーのマテリアルが失われたり侵害された場合に ID を回復するためのメカニズムを提供したりするものではありません。
ここで考えられる解決策について説明します。もう 1 つの考え方は、あるキーから別のローテーションへのイベントに署名するためにも使用する必要があるマスター コールド キーにキーを調整することです。キー A' があります。これは、A と M (マスター キー) を加算することによって派生されます。回転イベントは、A、M、B' (B と M を加算することで生成) と M の署名になります。 M は、3 分の 2、5 分の 3 など、複数の署名のしきい値キーにすることができます。
これにより、損失に対する冗長性が追加され、キーのローテーションのための安全なメカニズムが提供される可能性があります。これにより、サービスを利用して回復を支援したり、これらの鍵の一部を信頼できる友人に広めたりすることへの扉も開かれます。ビットコイン自体のマルチシグと同じ柔軟性を提供します。
PIN26 も、この問題に対処するのに非常に役立つ可能性のある提案です。これは、あるキーからの署名によって、別のキーがそのキーに代わってイベントを発行することを許可できるようにする、イベントのプロトコル拡張を指定します。 「トークン」または委任された署名証明は、最初の公開鍵に代わって 2 番目の公開鍵によって公開されるすべてのイベントに含まれます。時間制限を設けることもできるため、委任トークンは自動的に期限切れになり、更新する必要があります。
キーの管理とセキュリティの問題は、トレードオフと問題点に満ちた非常に大きな設計領域を伴う非常に大きな問題です。ただし、Nostr がユーザーのこれらの ID の整合性を保護および維持できない場合、ID として使用される公開キーと秘密キーのペアのみに基づくプロトコルは大規模には採用されません。
ノストルに面した拡張
Nostr プロトコル全体は、どこかでリレー サーバーを実行している誰かに依存しています。 「Nostr ネットワーク」はなく、リレーとリレーに接続されているクライアントだけがあります。人々がリレーを実行するよう動機づけられる必要があり、これは最終的にはリレーが長期的にどこまで拡大できるかに大きな影響を与えることになります。 Nostr リレーが収益を上げるか、少なくとも運営コストを賄うのに十分な資金がもたらされない限り、Twitter サーバーと同じ規模のリレーは存在しないでしょう。
広告協賛
Nostr がプロトコルとして機能する仕組みを考えると、広告を完全にブロックするのは簡単ではなく、実現不可能な解決策となります。リレー サーバーは、収益モデルとして広告を使用しようとすることができます。これは、オンラインのほぼすべての無料サービスの主な収益モデルであるようですが、問題は、ユーザーは基本的にオプトインする必要があることです。リレーは、クライアントに送信するイベントに広告を簡単に挿入できます。ただし、クライアントは、サブスクライブする予定の公開キーによって作成されたものでない広告イベントを UI から簡単にフィルタリングすることもできます。
マイクロペイメント
特にマイクロペイメントを統合する試みが現在進行中であることを考えると、マイクロペイメントも明白な解決策です。 ライトニング ネットワーク Nostr アプリにさらに緊密に組み込まれます。このモデルは、充電方法に大きな柔軟性を提供します。 Relay は、イベントの投稿、ダウンロード イベントの読み取り、またはその 2 つの組み合わせに対してのみ課金でき、消費するリソースの数に基づいてそれぞれの価格を調整します。ただし、このモデルを Twitter の規模まで拡張できるかどうかは疑問です。
コンテンツのマイクロペイメントは、 ライトニング ネットワークしかし、本当に世界規模に拡張するには、2 つの根本的な問題があります。
まず、ビットコインの普及はまだ十分ではありません。たとえ誰もが魔法のように、Nostr でのすべての小規模なサービスのやりとりに対して支払うことを受け入れたとしても、Twitter のような大規模なものをサポートするのに十分なビットコインを保有する人は存在しないでしょう。 Relay は法定通貨でサブスクリプション料金を請求できますが、これらの支払い方法では、公開またはダウンロードされるイベントごとに少額の料金を支払うことはできません。
第二に、人々はこの種の無料サービスに実際に慣れています。これはまさに期待通りです。マイクロペイメントが本当に大規模な中継をサポートできるとは思えません。
リレーを使用するすべてのクラスのユーザーにマイクロペイメントを強制することなく、マイクロペイメントをより「粘り強く」、またはより持続可能なものにする方法があります。 Twitter クローンを除いて、Nostr 上にさまざまなアプリケーションを構築することについては多くの話題がありました。 GitHub、Wikipedia、さらには Uber まで。
最後が重要です。それは経済的期待です。人々は、求人がどこかに掲載されたときに手数料を払ったり、オンラインで何かを注文したものの、無料であるべきだと思われるものを提供しなかったときにマーケットプレイスの運営者に手数料を支払うことに非常に慣れています – Google、Twitter。これにより、中継者は、多くの摩擦を引き起こしたり、平均的な潜在ユーザーの期待を裏切ったりすることなく、ユーザーから確固たる収入の柱を生み出す方法を提供できる可能性があります。
マイクロペイメントも要因となる場合、中継事業者は最初にユーザーから資金を受け取るためにライトニングノードを実行する必要があります。これは、リレーによって実装されたマイクロペイメントモデルと適切に相乗すれば、収益が増加する可能性があります。
リレーサーバーが得る収益が増えるほど、これを促進するためにライトニングネットワーク上でより多くの流動性が必要になります。通信事業者がネットワーク内で流動性を展開または分配する方法を正しく計画すれば、中継を介したデータの送受信にかかる手数料に加えて、ルーティング ノードを実行するという単なる行為自体が大きな収益源となる可能性があります。
まとめ
前述の Web3 ソーシャル プロジェクトに加えて、 私たちの および マストドン、などのプロジェクトも含まれます。 ファーキャスター および レンズ、既存のソーシャルメディアプラットフォームをすぐに置き換えることはありません。統計によると、Twitter には数億人のアクティブ ユーザーがいます。 Facebook 何十億も持っていますが、 マストドン たった 2.5万人のユーザー, 私たちの 程度しかありません 220,000 の一意のユーザー ID。 多くの Web3 ソーシャル プロジェクトは、大量採用を遅らせるユーザビリティのハードルに直面しています。
メディアと政治は切っても切り離せない関係にあります。 Web3 ソーシャル プロジェクトが急増し、さまざまなアプリケーションやプロトコル間で公の場での会話が細分化されると、政治的な結果が生じる可能性があります。平 メッシーナ分散型ソーシャルメディアを長らく提唱してきた同氏は、近年相互敵意や誤解が目立つようになった公的議論が分散化によってさらに促進されるのではないかと懸念している。
免責事項： このウェブサイトの情報は一般的な市場解説として提供されており、投資アドバイスを構成するものではありません。 投資する前に、ご自身で調査を行うことをお勧めします。
ニュースを追跡するために私たちに参加してください： https://linktr.ee/coincu
ハロルド
コインク ニュース
著者
知識
ソーシャルメディアの新年: Nostr 原則と主要な管理問題
第五右派のもとでの新しいソーシャルメディアのデザインは何年にもわたって検討されてきたが、大量に採用される兆候はない。この 1 年、暗号化技術の継続的な開発とマスク氏の Twitter 買収に関する懸念により、分散型ソーシャル ネットワークは新たなチャンスをもたらしました。
これらのソーシャル ネットワークが解決しようとしている問題には、検閲の強化、コンテンツのモデレーションの柔軟性の向上、人々がオンラインで話す内容を形成および追跡する大手ソーシャル メディア企業の権限の削減などが含まれる可能性があります。
新しいプラットフォームが出現して成長するにつれて、代替ソーシャル ネットワークの選択には政治的な考慮が伴うことがよくあります。 Getr、Parler、Gab、Truth Social などのサイトはすべて、Twitter に代わる言論の自由を宣伝することで右派の要望に応えています。
今日私たちが議論するのは、Nostr-ダムス、最近大きな注目を集めている新しいソーシャルメディアプロトコルであり、やや革新的です。これらには、Nostr の技術原則、解決すべき主要な管理問題、リレーの動作継続を促す方法などが含まれます。
ノストルの概要
2020に発売、 私たちの は、ユーザーが自分の ID を所有し、公開鍵と秘密鍵の暗号化を使用したデジタル署名を使用して投稿を検証できるようにする分散型プロトコルです。これらの投稿は、相互接続されたサーバーのネットワークに伝播されます。このプロトコルはブロックチェーンを使用していませんが、初期の実験ではソーシャル ネットワークには遅すぎることが判明しました。しかし、構造的な類似点があり、ノストラはその自由主義とオープンソースの精神により、仮想通貨群の中で初期のニッチ市場を見つけました。
マストドン vs. ノストラ
Nostr プロトコルと最初のリレー サーバーは、2020 年後半に開発者 fiatjaf によって作成されました。広く注目を集める前は、Nostr は Twitter と Mastodon の問題に対する軽量なソリューションを目的とした、地味なニッチ プロトコルでした。
2016 年に設立されたオープンソース ネットワークであるマストドンでは、誰でもサーバーをセットアップできます。この設計はよく「フェデレーテッド」と表現されますが、それがどのように定義されるかによって、「Web3」という曖昧な境界線に収まる場合とそうでない場合があります。マストドンでは、ユーザーはカスタム コンテンツ モデレーション ルールを使用して厳選されたコミュニティに参加できます。現在、登録ユーザー数は 200 人以上に達し、リベラル派、ジャーナリスト、学者の安全な避難所となっています。
In Twitter および マストドン システム、アイデンティティ/ユーザー名は、サーバーを実行する人によって制御されます。
Nostr の主な違いは、各ユーザーがサーバー オペレーターが所有するユーザー名を使用するのではなく、公開キーと秘密キーのペアを使用して機能を処理することにより、Nostr が検閲に耐えられるようになっている点です。これは、Nostr プロトコル全体を構築するための中心的な構成要素の 1 つです。
イベント: これは、クライアントと、メッセージを送信および取得するために接続する中継サーバーによって使用される基本的なオブジェクト/データ タイプです。このプロトコルの一般的な概念は、クライアントがリレー サーバーにイベントを送信し、リレー サーバーがイベントを保存してインデックスを作成し、他のクライアントがリレー サーバーと通信して、受信して保存したイベントを要求できるというものです。原作では ニップ 01では、次の 3 つの異なるイベント タイプが定義されました。
- ユーザー名、写真、プロフィールなどのユーザーに関するメタデータを送信します。
- SMS と基本コンテンツを送信する
- イベントクリエイターをフォローしている人が接続する中継サーバーを推奨
すべてのイベントは、特別に定義された方法で構造化されます。作成者の公開キー、作成タイムスタンプ、タイプ (または仕様上の種類)、コンテンツ ペイロード、およびイベント作成者の署名が含まれます。あるいは、他のイベントまたはユーザーを参照し、作成者の署名を除くすべてのハッシュである ID 値を持つタグが存在する場合もあります (ビットコイン トランザクションの TXID と同様)。
これにより、ユーザーは署名 (および鍵が侵害されていない場合はその鍵の所有者) を検証して、そのメッセージがその中の公開鍵の所有者によって実際に作成されたこと、およびメッセージが署名以来変更されていないことを保証できます。それ。
ビットコイントランザクションは、署名後に無効化することなく変更できないのと同様に、ユーザーは、トランザクションの作成者が作成した後はトランザクションを変更できません。 私たちの イベントは、それを明らかな詐欺とすることなく署名しました。
イベント型システムはオリジナルから大幅に拡張 NIP。直接暗号化されたメッセージには、送信者の秘密キーと受信者の公開キーを組み合わせて共有秘密を構築するイベント タイプがあり、その結果は、送信者の公開キーと受信者の秘密キーを組み合わせて得られるものと同じになります。は同じです (これが BIP 47 とサイレントペイメントの仕組みです)。
置換可能なイベント タイプと一時的なイベント タイプもあります。置き換え可能なイベントの場合は (当然のことですが)、イベントの元の作成者が新しいイベントに署名して古いイベントを置き換えることができるように設計されています。この仕様に従う中継サーバーは、古いイベントをストレージから自動的に削除し、受信時に新しいバージョンのクライアントへの提供を開始します。
一時的なイベントは、リレーに送信されると、その作成者を購読しているすべてのユーザーにブロードキャストされるように設計されていますが、リレー サーバーはイベントを保存しないでください。これにより、オンラインにいる人だけがブロードキャスト中にメッセージを見る可能性が生じます。他の人のイベント (いいね! や絵文字など) に対する反応を表すイベント タイプもあります。
最後の質問に関して言えば、イベントにはタグを含めることもできます。現在、次のタグ タイプがあります。 イベント (正確な Nostr イベントを指します)、 公開鍵 (別のユーザーをタグ付けまたは参照するため)、および 件名 (電子メールの件名などの機能を模倣するため)。
これらすべてには、データがフェッチされる特定のリレー サーバーへのポインタを含めることができるため、ユーザーは実際に異なるサーバー上で対話できるようになります。つまり、ユーザーはリレー サーバー上で自分のコンテンツを公開し、そのコンテンツを別のユーザーが別のサーバー上で対話したり参照したりできます。これにより、ユーザーは、大量の複雑な操作に関連するデータがどこにあるかを見つける必要がなく、対話のスレッド全体を適切な順序で一貫して取得できるようになります。
原作では NIPでは、クライアントが受信したいイベントのフィルターを含むメッセージ/データ構造をサブスクライブすることによって、クライアントがリレー サーバーと対話する方法の仕様が与えられました。これらのフィルターでは、ユーザーの公開キー、正確なイベント、イベントの種類、さらには以前の基準に基づいて指定したい特定の期間を指定できます。
ユーザーは、公開キーまたは「1xjisj…」などのイベント ID のプレフィックスを送信し、その短い文字列で始まる公開キーから XNUMX つ以上のイベントを受信することもできます (これは、実際に見たいものを中継サーバーから隠すのに役立ちます) 。
全体として、このプロトコルは、ユーザー間でメッセージを渡すための非常にシンプルな一般的なスキームであり、メッセージの整合性の保証やメッセージ送信のための公開キー ID の使用などの重要なことをカバーすると同時に、エンド インフラストラクチャのリレー サーバーを高度に一元化したり、ユーザーが実行できるようにしたりすることも容易にします。ユーザーが 1 つのリレー サーバーの使用を禁止された場合でも、大規模な混乱を引き起こすことなく、シームレスに相互作用しながら、独自の個人リレー サーバーを構築できます。
別のサーバーに移動したり、独自のサーバーを実行したりできます。また、以前のサーバーからプラットフォームを切り離してもデジタル ID やフォロワーを失うことはありません。秘密鍵の管理は維持されており、ユーザーはその秘密鍵を他の場所で使用して認証できるからです。彼らがそれらを見つけたら。
リレー サーバーは、自由に動作させることもでき、メッセージの公開またはダウンロードに少額の料金を請求することもでき、メッセージの送信にハッシュ キャッシュ スタイルの Proof-of-Work を必要とする NIP を備えることもできます。
投稿をホストして他のユーザーのみが利用できるようにする単一のリレー サーバー、または Twitter や Reddit などの大規模に動作するサーバー (クライアントは必要に応じて情報を表示および整理できるため、あらゆるソーシャル メディアをシミュレートできます) にすることができます。これらはすべて、ユーザーをロックアウトすることなくシームレスに相互運用します。
Nostr が対処すべき主要な管理問題
ユーザーの公開鍵/秘密鍵は、Nostr がプロトコルとして機能する上で不可欠な部分です。これは、実際のユーザーと他のユーザーがユーザーを識別する方法との間の緊密な結びつきとして機能し、中継サーバーがこれら 2 つの関係を解くこと、つまり誰かの識別子を別のユーザーに与えることを防ぎます。また、このプラットフォームの最大の問題の 1 つである、ユーザー自身のアイデンティティを制御できないことも解決されます。
しかし、これにより新たな問題も発生します。鍵を紛失したり、漏洩したりする可能性があり、そのような事態が発生した場合、ユーザーは助けを求めることができなくなります。
これには必然的に、ユーザーが検証可能かつ発見可能な方法で、あるキー ペアから別のキー ペアに切り替え、プロトコルを通じて他のユーザーと対話するためのスキームが必要になります。プロトコル全体は、イベントが特定のユーザー (ID キー) からのものであることを証明することに基づいているため、誰かのキーが侵害されると、これらの保証はすべて無効になります。
Nostr では、あるキーのローテーションを別のキーに結び付ける実際の暗号化スキームが必要です。開発者 fiatjaf は、この問題を解決する可能性のある基本的な解決策を提案しました。基本的なアイデアは、Taproot ツリーがビットコイン キーにコミットされる方法と同様に、単一のマスター シードから派生したアドレスの長いリストを取得し、「調整された」キーのセットを作成することです。
Taproot は、Taproot ツリーのマークル ルートを取得し、それを公開鍵に「追加」して、新しい公開鍵を作成します。これは、そのマークル ルートを秘密キーに追加して、新しい公開キーと一致する秘密キーを取得することで複製できます。 Fiatjaf のアイデアは、コミットメントを最後から最初まで逆方向に連鎖させて、調整された各キーに、次に調整されたキーが作成に使用されたという証拠が実際に含まれるようにすることです。
したがって、チェーンの最後のキー Z から始めると想像してください。これを何かで微調整してから、戻って、調整されたキー Z を使用してキー Y の調整されたバージョンを作成できます (Z' + Y = Y')。ここから、Y' を取得し、それを使用して X を調整できます (Y' + X = X')。これをキー A まで繰り返し、A' を取得し、そこからそのキーを使用します。これが壊れると、ユーザーは未調整のキー A と調整後のキー B' を含むイベントをブロードキャストできます。
これには、B' が A' の生成に使用されたことを示すために必要なすべてのデータが含まれており、ユーザーはすぐに A' のフォローを中止し、代わりに B' をフォローすることができます。彼らは、B' がそのユーザーの次のキーであることを明確に知っており、代わりにそのキーに従います。
しかし、この提案にはまだいくつかの問題があります。まず、使用されるすべてのキーは事前に生成する必要があり、まったく新しいキーのセットにローテーションする方法はありません。これは、このローテーションを公証できるこのスキームにマスター キーをコミットするか、最初から非常に大規模なキーのセットを生成するだけで解決できます。
どちらの方法も実現可能ですが、最終的には、ルート キーまたはキーマテリアルを安全に保ち、個々のホットキー (ホットキー) のみを Nostr クライアントに公開する必要があります。
ただし、このスキームはユーザーを保護したり、ルート キーのマテリアルが失われたり侵害された場合に ID を回復するためのメカニズムを提供したりするものではありません。
ここで考えられる解決策について説明します。もう 1 つの考え方は、あるキーから別のローテーションへのイベントに署名するためにも使用する必要があるマスター コールド キーにキーを調整することです。キー A' があります。これは、A と M (マスター キー) を加算することによって派生されます。回転イベントは、A、M、B' (B と M を加算することで生成) と M の署名になります。 M は、3 分の 2、5 分の 3 など、複数の署名のしきい値キーにすることができます。
これにより、損失に対する冗長性が追加され、キーのローテーションのための安全なメカニズムが提供される可能性があります。これにより、サービスを利用して回復を支援したり、これらの鍵の一部を信頼できる友人に広めたりすることへの扉も開かれます。ビットコイン自体のマルチシグと同じ柔軟性を提供します。
PIN26 も、この問題に対処するのに非常に役立つ可能性のある提案です。これは、あるキーからの署名によって、別のキーがそのキーに代わってイベントを発行することを許可できるようにする、イベントのプロトコル拡張を指定します。 「トークン」または委任された署名証明は、最初の公開鍵に代わって 2 番目の公開鍵によって公開されるすべてのイベントに含まれます。時間制限を設けることもできるため、委任トークンは自動的に期限切れになり、更新する必要があります。
キーの管理とセキュリティの問題は、トレードオフと問題点に満ちた非常に大きな設計領域を伴う非常に大きな問題です。ただし、Nostr がユーザーのこれらの ID の整合性を保護および維持できない場合、ID として使用される公開キーと秘密キーのペアのみに基づくプロトコルは大規模には採用されません。
ノストルに面した拡張
Nostr プロトコル全体は、どこかでリレー サーバーを実行している誰かに依存しています。 「Nostr ネットワーク」はなく、リレーとリレーに接続されているクライアントだけがあります。人々がリレーを実行するよう動機づけられる必要があり、これは最終的にはリレーが長期的にどこまで拡大できるかに大きな影響を与えることになります。 Nostr リレーが収益を上げるか、少なくとも運営コストを賄うのに十分な資金がもたらされない限り、Twitter サーバーと同じ規模のリレーは存在しないでしょう。
広告協賛
Nostr がプロトコルとして機能する仕組みを考えると、広告を完全にブロックするのは簡単ではなく、実現不可能な解決策となります。リレー サーバーは、収益モデルとして広告を使用しようとすることができます。これは、オンラインのほぼすべての無料サービスの主な収益モデルであるようですが、問題は、ユーザーは基本的にオプトインする必要があることです。リレーは、クライアントに送信するイベントに広告を簡単に挿入できます。ただし、クライアントは、サブスクライブする予定の公開キーによって作成されたものでない広告イベントを UI から簡単にフィルタリングすることもできます。
マイクロペイメント
特にマイクロペイメントを統合する試みが現在進行中であることを考えると、マイクロペイメントも明白な解決策です。 ライトニング ネットワーク Nostr アプリにさらに緊密に組み込まれます。このモデルは、充電方法に大きな柔軟性を提供します。 Relay は、イベントの投稿、ダウンロード イベントの読み取り、またはその 2 つの組み合わせに対してのみ課金でき、消費するリソースの数に基づいてそれぞれの価格を調整します。ただし、このモデルを Twitter の規模まで拡張できるかどうかは疑問です。
コンテンツのマイクロペイメントは、 ライトニング ネットワークしかし、本当に世界規模に拡張するには、2 つの根本的な問題があります。
まず、ビットコインの普及はまだ十分ではありません。たとえ誰もが魔法のように、Nostr でのすべての小規模なサービスのやりとりに対して支払うことを受け入れたとしても、Twitter のような大規模なものをサポートするのに十分なビットコインを保有する人は存在しないでしょう。 Relay は法定通貨でサブスクリプション料金を請求できますが、これらの支払い方法では、公開またはダウンロードされるイベントごとに少額の料金を支払うことはできません。
第二に、人々はこの種の無料サービスに実際に慣れています。これはまさに期待通りです。マイクロペイメントが本当に大規模な中継をサポートできるとは思えません。
リレーを使用するすべてのクラスのユーザーにマイクロペイメントを強制することなく、マイクロペイメントをより「粘り強く」、またはより持続可能なものにする方法があります。 Twitter クローンを除いて、Nostr 上にさまざまなアプリケーションを構築することについては多くの話題がありました。 GitHub、Wikipedia、さらには Uber まで。
最後が重要です。それは経済的期待です。人々は、求人がどこかに掲載されたときに手数料を払ったり、オンラインで何かを注文したものの、無料であるべきだと思われるものを提供しなかったときにマーケットプレイスの運営者に手数料を支払うことに非常に慣れています – Google、Twitter。これにより、中継者は、多くの摩擦を引き起こしたり、平均的な潜在ユーザーの期待を裏切ったりすることなく、ユーザーから確固たる収入の柱を生み出す方法を提供できる可能性があります。
マイクロペイメントも要因となる場合、中継事業者は最初にユーザーから資金を受け取るためにライトニングノードを実行する必要があります。これは、リレーによって実装されたマイクロペイメントモデルと適切に相乗すれば、収益が増加する可能性があります。
リレーサーバーが得る収益が増えるほど、これを促進するためにライトニングネットワーク上でより多くの流動性が必要になります。通信事業者がネットワーク内で流動性を展開または分配する方法を正しく計画すれば、中継を介したデータの送受信にかかる手数料に加えて、ルーティング ノードを実行するという単なる行為自体が大きな収益源となる可能性があります。
まとめ
前述の Web3 ソーシャル プロジェクトに加えて、 私たちの および マストドン、などのプロジェクトも含まれます。 ファーキャスター および レンズ、既存のソーシャルメディアプラットフォームをすぐに置き換えることはありません。統計によると、Twitter には数億人のアクティブ ユーザーがいます。 Facebook 何十億も持っていますが、 マストドン たった 2.5万人のユーザー, 私たちの 程度しかありません 220,000 の一意のユーザー ID。 多くの Web3 ソーシャル プロジェクトは、大量採用を遅らせるユーザビリティのハードルに直面しています。
メディアと政治は切っても切り離せない関係にあります。 Web3 ソーシャル プロジェクトが急増し、さまざまなアプリケーションやプロトコル間で公の場での会話が細分化されると、政治的な結果が生じる可能性があります。平 メッシーナ分散型ソーシャルメディアを長らく提唱してきた同氏は、近年相互敵意や誤解が目立つようになった公的議論が分散化によってさらに促進されるのではないかと懸念している。
免責事項： このウェブサイトの情報は一般的な市場解説として提供されており、投資アドバイスを構成するものではありません。 投資する前に、ご自身で調査を行うことをお勧めします。
ニュースを追跡するために私たちに参加してください： https://linktr.ee/coincu
ハロルド
コインク ニュース
その他の投稿
関連記事
