分散型ソーシャル プロトコル Nostr を 1 つの記事で読む
DeFi之道
2023-02-01 07:09
本文约3303字,阅读全文需要约13分钟
イーロン・マスクによって禁止され、ジャック・ドーシーによって資金提供されているnostrの魔法とは何ですか?

原題:「nostrを理解するための1つの記事:イーロン・マスクを怖がらせる分散型ソーシャルプロトコル」

原文の編集: The Way of DeFi

原文の編集: The Way of DeFi

画像の説明

Twitterの禁止ポリシーが更新されました

序文によると、nostr は検閲に耐えるグローバルな「ソーシャル」ネットワークをきっぱりと構築できる最小限のプロトコルです。

nostr は信頼できる中央サーバーに依存せず、暗号化キーと署名に基づいており、P2P テクノロジーに依存せず、トークンも発行しません。

では、どのように機能するのでしょうか?簡単に言うと、全員がクライアントを実行します。これには、ネイティブ クライアントや Web クライアントなどが考えられます。何か (投稿など) を公開するには、自分のキーで署名し、複数のリレーラー (他の人または自分自身がホストするサーバー) に送信します。他の人から最新情報を得るには、複数のリピーターに他の人について知っているかどうか尋ねることができます。リピーターは誰でも実行できます。それは非常にシンプルで、一部の人の投稿を受け入れ、他の人に転送するだけです。また、中継者を信頼する必要もありません。署名はクライアント側で検証されます。

1.Nostrの使い始め方

2.Nostrクライアント機能比較

最初のレベルのタイトル

副題

副題

Twitterには広告があります。

Twitter は、ユーザーを夢中にさせるために奇妙なトリックを使用します。

Twitter では、あなたがフォローしている人々の実際の履歴は表示されません。

Twitterは特定の人々のアカウントを禁止する予定だ。

Twitterではシャドウバンを使用しています。

Twitter にはスパムがたくさんあります。

サーバー所有者は Twitter のようにユーザーを禁止でき、サーバー所有者は他のサーバーをブロックすることもできます。

ユーザー ID は、サードパーティが管理するドメイン名に関連付けられます。

サーバー所有者は Twitter のようにユーザーを禁止でき、サーバー所有者は他のサーバーをブロックすることもできます。

サーバー間の移行は後付けであり、サーバーの協力がなければ実行できません。敵対的な環境では機能しません (すべてのフォロワーが失われます)。

サーバーを運営する明確な動機がないため、趣味の人や、かっこいいドメイン名に自分の名前を付けたい人によって運営される傾向があります。そうなると、ユーザーは、しばしば Twitter のような大企業よりもひどい、ある人物の圧政にさらされることになり、そこから抜け出すことができなくなります。

サーバーはアマチュア的な傾向があるため、しばらくすると放棄されることがよくあります。これは事実上全員を禁止することになります。

各サーバーの更新を他の多数のサーバーに苦労してプッシュ (そして保存) する必要がある場合、多数のサーバーを持つ意味がありません。これはサーバーの数が膨大であるためさらに悪化するため、より多くのデータをより多くのサーバーに配信する必要があります。場所。

副題

3. SSB(セキュア・スカットルバット)の問題点

あまり問題も多くなく、とても良いと思います。実際、私はこれをベースに構築しようとしていましたが、オープン プロトコルとはまったくみなされていないため、プロトコルが複雑すぎます。これは、おそらく特定の問題に対する簡単な修正として JavaScript で書かれているだけなので、ECMA-262 第 6 版のルールに厳密に従わなければならない JSON 文字列に署名するなど、奇妙で不必要な癖があります。

単一のユーザーから一連の更新を取得することを要求しますが、これは私にとっては不必要であり、コンテンツの肥大化と硬直性を高めます。新しい投稿が効果的であることを確認するには、すべてのサーバー/ユーザーがすべての投稿チェーンを保存する必要があります。なぜ彼らはこんなことをするのでしょうか? (おそらく彼らには正当な理由があるのでしょう)。

Nostr は主に P2P 同期用に設計されているため、Nostr ほど単純ではありません。

副題

4. サーバー ソリューションの実行が必要なその他の問題

全員が独自のサーバーを実行する必要があります。

最初のレベルのタイトル

2. Nostrの動作原理

Nostr には、クライアントとリレーラーという 2 つのコンポーネントがあります。各ユーザーはクライアントを実行し、誰でもリピーターを実行できます。

すべてのユーザーは公開キーによって識別され、すべての投稿が署名され、すべてのクライアントがそれらの署名を検証します。

クライアントは、選択したリレーラーからデータを取得し、選択した他のリレーラーにデータを公開します。リピータは別のリピータとは通信せず、ユーザーとのみ直接通信します。

たとえば、誰かを「フォロー」するには、ユーザーはクライアントに、既知のリレーラーにその公開キーからの投稿を問い合わせるよう指示するだけです。

起動時に、クライアントは、知っているすべてのリピーターに対して、フォローしているすべてのユーザーのデータ (たとえば、最新日のすべての更新) を照会し、そのデータを時系列でユーザーに表示します。

最初のレベルのタイトル

副題

問題 1: ユーザーの禁止、サーバーのダウン

リピーターはユーザーがリピーターに何も投稿できないようにすることができますが、ユーザーは引き続き他のリピーターにコンテンツを投稿できるため、これはユーザーには影響しません。ユーザーは公開キーによって識別されるため、禁止されてもアイデンティティやファンベースを失うことはありません。

ユーザーに新しいリピーター アドレスを手動で入力するよう求める代わりに (これもサポートされるべきですが)、フォローしている誰かがサーバーの推奨事項を投稿するたびに、クライアントはクエリするリピーターのリストにそのアドレスを自動的に追加する必要があります。

あるリレーラーを使用してデータを公開しているが、別のリレーラーに移行したい場合は、サーバーの推奨事項を前のリレーラーに投稿して、終了することができます。

誰かがあまりにも多くのリピーターから禁止されてサーバーの推奨事項をブロードキャストできなくなった場合でも、他の手段で現在どのリピーターに投稿しているかを親しい友人に知らせることができます。これらの親しい友人は、サーバーの推奨事項を新しいサーバーに投稿できるようになり、徐々に禁止されたユーザーの古いファンベースが新しいリピーターからの投稿を再び見つけ始めるようになります。

副題

問題 2: 検閲への抵抗

各ユーザーは、コンテンツの更新を任意の数のリレーラーに公開できます。

副題

問題 3: スパム

副題

問題 4: データ ストレージ

ネットワークの健全性を維持するために、何百ものアクティブなリピーターは必要ありません。実際、既存のものに障害が発生し始めた場合には、新しいものを簡単に作成してネットワーク経由で伝播できるため、うまく機能するものはほんの一握りです。したがって、必要なデータ ストレージの量は一般に、Mastodon または同様のソフトウェアよりも少なくなります。

副題

質問 5: ビデオおよびその他の重いコンテンツ

副題

質問6:表示方法

最初のレベルのタイトル

4. よくある質問

答え:

答え:わかりませんが、ソーシャル ネットワークを作成した人たちが、金儲けをしようとしている企業か、サーバーをまったく使わずに何かをしたいと考えている P2P 活動家であり、そのどちらでもないという事実と関係があるのではないかと思います。 Nostr が使用したものを参照してください。両方の世界の特定の組み合わせです。

答え:

答え:まず、それらについて知り、尋ねるか、どこかで見ることによって、何らかの方法で公開鍵を入手する必要があります。 Nostr ソーシャル ネットワークに参加すると、他のユーザーとのやり取りが表示され、フォローしたり、やり取りを開始したりすることもできます。

答え:

答え:その人とはコミュニケーションが取れなくなります。ただし、イベント ヒントを使用すると、クライアント ソフトウェア (または手動) が他の人のリピーターに接続して対話する方法を知ることができます。将来的にはこの問題を解決するための他のアイデアもありますが、完全な到達可能性を保証することはできず、どのプロトコルも同様です。

答え:

答え:いいえ、ただし、リピーターが追加のプロトコル方法で連携する場合は、ある程度の推定値を取得できます。

答え:

答え:この質問は誤解を招きます。リピーターが無料であり、人々がリピーターを介してデータを移動できることを前提としています。はい、この場合、インセンティブは存在しません。これは実際には、他のすべての p2p ネットワーク スタックの DHT ノードにも当てはまります。人々は DHT ノードを実行するどのようなインセンティブを持っているのでしょうか?

答え:

答え:現在、AWS や Azure だけでなく、世界中に何千もの VPS プロバイダーが存在します。 AWS または Azure はまさに大規模な単一集中型サービス プロバイダーが使用するものであり、小規模なリレー サーバーの場合は、どの VPS も適切に機能します。

プロトコル仕様

元のリンク

元のリンク

DeFi之道
作者文库