ログイン/ 登録

Nostrプロトコルとは？なぜジャック・ドーシーは資金を提供したが、イーロン・マスクはそれを禁止したのか?

2022/12/22 09:47

従う

Nostr という名前の新しいソーシャルプロトコルは、Twitter の元 CEO である Jack Dorsey と現在の CEO である Elon Musk によって非常に異なる扱いを受けました。

12 月 14 日、元 Twitter CEO の Jack Dorsey は、Twitter ユーザーの Koty_Auditore から Nostr に資金を提供するよう勧められました。 Nostr について調査した後、Jack Dorsey は 12 月 15 日に Nostr の開発資金として 14 ビットコイン (約 245,000 ドル) の寄付を発表しました。

一方、12 月 18 日、Twitter は公式に、宣伝に Facebook、Instagram、Truth Social、Mastodon などの他のソーシャルメディアへのリンクを含むユーザーのブロックを発表し、Nostr がリストされました。

ノストルとは？

nostr は、「リレーによって送信されるメモおよびその他のもの」の略です。

Nostr の github によると、Nostr は、検閲に強いグローバルな「ソーシャル」プラットフォームを作成できる最も単純なオープンプロトコルです。ネットワークを一度に。

Nostr ソーシャルネットワークは、Twitter と同じように構築されており、投稿 (ツイートのようなもの) を作成したり、投稿のようなものを作成したり、誰かをフォローまたはフォロー解除したり、リツイート/リポストしたりできます。通常、「投稿」という用語は、または '注意' nostr ソーシャルネットワークで投稿を作成することを指すために使用されます。

ただし、信頼できる中央サーバーに依存していないため、回復力があります。暗号化キーと署名に基づいているため、改ざんが防止されます。 P2P 技術に依存しないため、機能します。

Nostr はどのように機能しますか?

次の 2 つのコンポーネントがあります。クライアント とリレー .各ユーザーがクライアントを実行します。リレーは誰でも走れます。
すべてのユーザーは、公開鍵によって識別されます。すべての投稿は署名されています。すべてのクライアントがこれらの署名を検証します。
クライアントは、選択したリレーからデータをフェッチし、選択した他のリレーにデータを公開します。リレーは別のリレーとは対話せず、直接ユーザーとのみ対話します。
たとえば、「フォロー」するには、ユーザーがクライアントに、その公開鍵からの投稿について知っているリレーを照会するように指示するだけです。
起動時に、クライアントは、フォローしているすべてのユーザーについて認識しているすべてのリレーからのデータを照会し (たとえば、最終日のすべての更新)、そのデータを時系列でユーザーに表示します。
「投稿」あらゆる種類の構造化データを含めることができますが、最も使用されているものは標準に組み込まれるため、すべてのクライアントとリレーがそれらをシームレスに処理できます。

それがどのように機能するかの簡単な要約

誰もがクライアントを実行します。ネイティブクライアント、Web クライアントなどを使用できます。何かを公開するには、投稿を作成し、キーで署名して、複数のリレー (他の誰かがホストするサーバー、または自分自身がホストするサーバー) に送信します。他の人から最新情報を入手するには、複数のリレーに他の人について何か知っているかどうか尋ねます.リレーは誰でも走れます。リレーは非常に単純で馬鹿げています。一部の人からの投稿を受け入れ、他の人に転送する以外には何もしません。リレーは信頼されている必要はありません。署名はクライアント側で検証されます。

Nostrが必要な理由

他のソリューションが壊れているため:

ツイッターの問題点

Twitter には広告があります。
Twitter は奇妙なテクニックを使って、ユーザーを夢中にさせます。
Twitter では、フォローしているユーザーからの実際の過去のフィードは表示されません。
Twitterは人々を禁止します。
Twitterは人々をシャドウバンします。
Twitterにはスパムがたくさんあります。

Mastodon および類似プログラムの問題点

ユーザー ID は、サードパーティが管理するドメイン名に関連付けられています。
Twitter と同じように、サーバー所有者はあなたを禁止できます。サーバーの所有者は、他のサーバーをブロックすることもできます。
サーバー間の移行は後付けであり、サーバーが連携している場合にのみ実行できます。敵対的な環境では機能しません (すべてのフォロワーが失われます)。
サーバーを実行する明確なインセンティブがないため、愛好家やクールなドメインに自分の名前を付けたい人によって実行される傾向があります.そして、ユーザーは一人の専制政治にさらされます。これは、Twitter のような大企業の専制政治よりも悪いことがよくあります。
サーバーはアマチュア的に実行される傾向があるため、しばらくすると放棄されることがよくあります。これは事実上、全員を禁止することと同じです。
すべてのサーバーからの更新を大量の他のサーバーにプッシュ (および保存) する必要がある場合、大量のサーバーを用意しても意味がありません。この点は、サーバーが膨大な数で存在する傾向があるという事実によって悪化します。したがって、より多くのデータをより多くの場所により頻繁に渡す必要があります。
ビデオ共有の特定の例については、ActivityPub 愛好家は、テキストノートのようにサーバーからサーバーへビデオを送信することは完全に不可能であることに気付きました。 Nostr アプローチに似ています。

SSB (Secure Scuttlebutt) の問題点

多くの問題はありません。素晴らしいと思います。本当はこれをベースに使うつもりだったのですが、
そのプロトコルは複雑すぎます。なぜなら、オープンプロトコルであるとはまったく考えられていなかったからです。おそらく特定の問題を解決するための簡単な方法でJavaScriptで書かれ、そこから成長したため、厳密にルールに従う必要があるJSON文字列に署名するなど、奇妙で不必要な癖があります。ECMA-262 第6版 ;
1 人のユーザーからの一連の更新を行うことを主張しますが、これは私には不要であり、物事に肥大化と硬直性を追加するものです。各サーバー/ユーザーは、新しい投稿が有効であることを確認するためにすべての一連の投稿を保存する必要があります。なんで？（たぶん、彼らには正当な理由があります）;
主に「pubs」との P2P 同期用に作成されたため、Nostr ほど単純ではありません。後付けです。
それでも、このカスタムプロトコルの代わりに SSB を使用し、それをクライアントリレーサーバーモデルに適応させることを検討する価値があるかもしれません。

全員が独自のサーバーを実行する必要がある他のソリューションの問題