新しいSNSリレープロトコルnostr protocolについて

上のロゴは Damus のものなので nostr のロゴというわけではない。

大雑把な概要

• 秘密鍵と暗号鍵を使ってやりとりする SNS プロトコル である
• プロトコルなので特定 SNS を指すわけではない (自由にいろいろ作れる)
• アカウントを作るというよりも個人識別用暗号鍵を生成する
• nostr protocol を使ったクライアントは中継サーバー経由で投稿をリレーしている
• リレーしていないサーバーへは自分の投稿は送られないしそのサーバーの人をフォローすることはできない
• 決まったクライアントは無い (現状 ios は Damus Android は Amethyst Web 版はいろいろ)
• サーバーの負担は大きくはない (しかし現状遅延は起こりうる)
• 画像アップロード機能などはクライアント次第であり課金も自由なので文字しか投稿できないクライアントもある (Damus も文字だけ)
• 仮想通貨投げ銭機能付き
• 認証済みアカウントは NIP-05 認証方式という 16 進数にした公開鍵が記載された json ファイルを自分のドメインに置くことで行う。

以下は単純に Google 日本語訳したものです。 一部修正済み。

• なぜ nostr が必要なのか?既存の SNS の問題点
  • ツイッターの問題点
  • Mastodon および類似プログラムの問題点
  • SSB (Secure Scuttlebutt) の問題点
• Nostr はどのように機能しますか?
• 上記のネットワークでは解決できない問題をどのように解決しますか?
  • ユーザーが禁止され、サーバーが閉鎖される
  • 検閲耐性
  • スパム
  • データストレージ
  • ビデオおよびその他の重いコンテンツ
  • ユーザーを騙すテクニック
• nostr protocol を使ったクライアント

なぜ nostr が必要なのか?既存の SNS の問題点

ツイッターの問題点

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

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

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

SSB (Secure Scuttlebutt) の問題点

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

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

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

上記のネットワークでは解決できない問題をどのように解決しますか?

ユーザーが禁止され、サーバーが閉鎖される

• リレーは、ユーザーがそこで何かを公開するのをブロックできますが、他のリレーに公開できるため、影響はありません。ユーザーは公開鍵によって識別されるため、禁止されても ID とフォロワーベースを失うことはありません。
• ユーザーに新しいリレー アドレスを手動で入力するよう要求する代わりに (これもサポートされている必要があります)、フォローしている誰かがサーバーの推奨事項を投稿するたびに、クライアントはクエリするリレーのリストにそれを自動的に追加する必要があります。
• 誰かがリレーを使用してデータを公開しているが、別のリレーに移行したい場合は、サーバーの推奨事項をその以前のリレーに公開して移動できます。
• サーバーの推奨事項をブロードキャストできないように多くのリレーから禁止された場合でも、現在どのリレーで公開しているかを別の方法で親しい友人に知らせることができます。次に、これらの親しい友人はサーバーの推奨事項をその新しいサーバーに公開でき、ゆっくりと、禁止されたユーザーの古いフォロワーベースが新しいリレーから投稿を再び見つけ始めます.
• 上記のすべては、リレーが動作を停止した場合にも有効です。

検閲耐性

• 各ユーザーは、更新を任意の数のリレーに発行できます。
• リレーは、そこで公開するためにユーザーから料金を請求できます (その料金の交渉は今のところプロトコルの範囲外です)。これにより、検閲に対する耐性が保証されます (投稿を提供する代わりに、喜んでお金を受け取るロシアのサーバーが常に存在します)。 ）。

スパム

• スパムがリレーの懸念事項である場合、公開のための支払い、または電子メールアドレスや電話などの他の形式の認証を要求し、これらを内部で公開鍵に関連付けて、そのリレーに公開することができます。ハッシュキャッシュやキャプチャなどのスパム技術。リレーがスパム ベクトルとして使用されている場合、クライアントによって簡単にリストから除外され、他のリレーから更新を取得し続けることができます。

データストレージ

• ネットワークの健全性を維持するために、何百ものアクティブなリレーは必要ありません。実際、既存のリレーが誤動作を開始した場合に備えて、新しいリレーを作成してネットワーク全体に簡単に拡散できるという事実を考えると、ほんの一握りで問題なく機能します。したがって、必要なデータ ストレージの量は、一般に、Mastodon や類似のソフトウェアよりも比較的少なくなります。
• または、別の結果を考えてみてください。アマチュアによって運営されている何百ものニッチなリレーが存在し、それぞれが少数のユーザー グループからの更新をリレーしている場合です。アーキテクチャも同様にスケーリングします。データはユーザーから単一のサーバーに送信され、そのサーバーからそれを消費するユーザーに直接送信されます。他の誰かが保管する必要はありません。この状況では、単一のサーバーが他のサーバーからの更新を処理することは大きな負担ではなく、アマチュア サーバーを使用しても問題ありません。

ビデオおよびその他の重いコンテンツ

• リレーが大きなコンテンツを拒否したり、大きなコンテンツの受け入れとホスティングに対して料金を請求したりするのは簡単です。情報とインセンティブが明確であれば、市場の力が問題を解決するのは簡単です。

ユーザーを騙すテクニック

• 各クライアントは、投稿をユーザーに最適に表示する方法を決定できるため、AI を使用して表示される更新の順序を決定することから、単にそれらを読むことまで、必要なものを好きな方法で消費するオプションが常にあります。年代順。

nostr protocol を使ったクライアント

以下に記載されている。 https://github.com/aljazceru/awesome-nostr