-
@ YakiHonne
2023-11-23 02:33:28YakiHonne コミュニティはノストラシアに興奮しており、ノストラシアの感動的なスピーチを熱心に文字に起こしています。 追加のスピーチトランスクリプトは、今後公開される予定です。 日本語版とスペイン語版は、最初にコミュニティ メンバーによって AI ツールの助けを借りて翻訳および校正されます。 YakiHonneユーザーの皆様はぜひレビューにご参加ください。 無事にレビューを完了した方には特別報酬として3000Satが付与されます。 まずはご連絡ください (ここにコメントしてください、DM、または TG)。 連絡してレビューを送信した人が、幸運な特典の受け取り者となります。 もしよろしければ、これらのスピーチをさらに多くの言語に翻訳していただければ幸いです。 参加しませんか！
🌟English: The Gossip Model 🌟中文版: The Gossip Model 🌟Español: El modelo del chisme
わかった。私はマイケル・ディルガーです。私はゴシップクライアントで働いています。これは「ゴシップ モデル」というタイトルの講演ですが、「リレー ランデブー」に変更したいと思います。そのほうが、私たちが話していることをよりよく説明していると思うからです。なぜなら、ゴシップのモデル、つまりゴシップはクライアントの名前だったからです。
「リレーランデブー」を行うには、受信箱モデル、送信箱モデルのいくつかの方法があります。そういった用語を使うことになると思います。そこで、「ゴシップ モデル」のアイデア全体を削除し、代わりにそれらについて話します。そして、私たちが話そうとしていることは、「リレー・ランデブー」の方がよく説明されていると思います。
つまり、nostr について考えてみると、それはリレーによって送信されるメモやその他のものです。何が起こるかというと、クライアントがリレーにイベントを配置し、目的のためにそこにイベントを配置します。リレーに行ってイベントを開催して、それを衰退させるだけではありません。重要なのは、誰かが最終的にそのリレーに参加し、その恩恵を受けるためにそのイベントを中止することになるということです。
したがって、どのリレーが何の目的で使用されるかという問題があります。私はnostrで約300のリレーに遭遇しました。また、自分のイベントをリレーに載せて、他の人がそれを見つけてくれることを期待している場合、実際に同じリレーを使用していなければ、あまりうまく機能しません。したがって、いくつかのモデルが考えられます。
そのうちの 1 つは受信トレイ モデルと呼ばれるもので、電子メールによく似ています。電子メールを使用すると、たとえばニュースレターを購読し、ニュースレターの発行者があなたの電子メールにニュースレターをたとえば毎週送信します。イベントの作成者が中継に載せているところです。彼らは特定の人に宛てられたリレーにそれを載せているのです。
outbox と呼ばれる別のモデルもあり、これは Web サイトに似ています。それは特定の誰かに宛てられたものではありません。それは誰のためでもあります。
私が関わった Nostr の最初の使用法は、多くの人にとって、Twitter クローン、マイクロブログのようなものだと思います。その意味で、人々に見てもらうために何かを公開したい場合、どのリレーでそれを公開すべきかを人々が知る必要があります。彼らが私をフォローしたとしても、私がフィンランドのリレーに公開し、他の誰かがドイツのリレーを使用しているとしても、彼らはそれを見つけることができません。
リレーは互いに通信しません。実際には相互に中継しているわけではありません。したがって、私のコンテンツをフォローしたい人には、「私はフィンランドのこのリレーに投稿しているんだ」とわかるような何らかの方法が必要です。 NIP 65 というものがあります。これは基本的に、「これは、どのリレーをどのような目的で使用しているかを人々に伝えることができる方法です」と述べています。私たちが始めたいくつかの目的は、「ここは私の作品を公開する場所です。入手したい場合はここに来てください。」という送信ボックスでした。もう 1 つは受信箱で、「何か読んでほしいなら、受信箱に入れてください。私はその中にタグ付けされるものを探しているからです。」
パブロがこれほど多くのパネルに登場するとは知らなかったことをお詫びしたい。でも、もっと詳しく話す前に、何か言いたいことがありますか？」
この講演で私が話したいテーマは、メモを保存したりリレーからメモを取得したりする方法は実際にはたくさんあり、それはユースケースに大きく依存するということです。
最初にクライアントを作成したとき、私がやったことは、Fiat-Jaf のコードのようなものを調べたことだったと思います。彼にはリレー プールと呼ばれる概念がありました。これは Nostr で実行できる最もばかげた行為のようなものですが、実際には始めたばかりなら大丈夫です。これにより、ノートをプッシュおよび取得する非常に簡単な方法についての良いアイデアが得られます。つまり、単にリレーの配列があり、公開先のリレーのセットだけを用意し、その後で小さな部分を書くことができます。これらのノートをリレーにプッシュするだけのコードです。さて、この時点では、これが分散化やその類のものにどのように役立つかについて考えても、開発を始めるときの簡単な方法のようなものでした。
これが私がダマスを始めたきっかけであり、今でもこのモデルをダマスに持っています。それが分散化にとって最善の方法であるというわけではありません。あなたが今言及したように、これには多くの問題がありますが、ソーシャル メディア ネットワークを構築しようとしているだけであれば、それらのリレーをプロフィールに置くだけで、他の人があなたのプロフィールを読むことができます。彼らが最初にそれを入手でき、その後メモにアクセスできると仮定すると、検閲への耐性が得られます。
したがって、このアイデアを試してみたい場合は、これが nostr で始めるのに最も簡単なモデルであると思います。しかし、他にもたくさんのゴシップがあります。インボックス、アウトボックスモデルと考えられていると思います。しかし、私が話したいのは、データやさまざまなモデルをフェッチして取得する別の方法が実際に存在するということですが、現時点では誰もあまり話題にしていません。
そこで私がやりたいのは、nostr 上で非同期通信を構築することです。つまり、電子メールと同じように、電子メールはもう使いたくないのです。すべてに nostr を使用したいだけです。そこで、私が考えていたことの 1 つは、メーリング リストを実行していて、メーリング リストを表すリレーがあると想像してみてください。したがって、人々はそのリレーにメモを送りたがります。
それは一種のことで、リレー自体がメーリング リストそのものであると考えられるかもしれません。唯一の問題は、人々がそれをリレープールに追加するだけで、会費モデルのようなモデルを使用している場合、ランダムな人々から大量のランダムなメッセージを受け取るだけになるため、これがコミュニティのような理由ですベースのリレーや、非常に特殊な目的のリレーのようなものは、単にメモを送信するだけなので、実際には効果的ではありません。
この問題を解決するために、私はこれを解決する方法を考えてきました。やりたいことの 1 つは、メモに Like to や CC、さまざまな種類のメタデータを追加して、メーリング リストのリレーがメモを受信したときに実際にメモを受信できるようにすることです。それがその特定のリレーに送信されることを意図していることを確認します。
全体的にはいろいろあると思います。 nostr でメモを送受信するにはさまざまな方法がありますが、私が伝えたいテーマは、最良の方法が 1 つあるわけではないということです。ご存知のとおり、おそらく Goss モデルが素晴らしいモデルだとは言えませんが、ソーシャル メディア環境における分散化にはおそらくこれが最適でしょう。しかし、おそらく、電子メール、同期通信、メーリング リストなどの他の種類のプロトコルを構築したい場合は、メモを送受信する別の方法があるかもしれません。とにかく、これを行うためのさまざまな方法を模索し始めたばかりだと思います。視点。
そこで私が言いたかったのは、これらのさまざまなモデルは基本的に、あなたが解決しようとしている問題は何なのか、そしてどのモデルが適切に解決するのかを考える必要があるということです。マイクロブログというものはアウトボックスで解決できると思っていましたが、Pub というアクティビティを知って驚きました。受信トレイ モデルでマイクロブログを行うのとはまったく逆の方法で、これも同様に機能します。受信トレイ モデルとは異なるプロパティがあります。
ご存知のとおり、別のアクティビティ パブ サーバーにフェデレートを送信している人は、フェデレーションを切断して、その情報のフィードを続行できなくなる可能性があります。したがって、RSS フィードを公開して誰でも入手できるようなものではありません。そして、チャット サーバー モデルや中継に参加するライブ イベントなど、他のモデルもあります。全員が同じリレーに集合しなければなりません。そして、私たちが考えていないモデルがさらにあるかもしれません。
だからこそフィアヤフは、おそらく数週間か1か月前に、この機能がどのように機能するかを仕様化するために文書化するのは興味深いだろうと書いたと述べた。そして、私はそのアイデアに激しく反対しました。なぜなら、私たちはこれを探求し始めていると思うし、何がうまくいくのかまったくわからないからです。そして、これは、何をしようとしているかに応じて、さまざまな方法で機能すると思うことに完全に同意します。
話題のリレーについて皆さんはどう思いますか？なぜなら、あなたがリレーに対して CC や BCC などと言っていることは、クライアントが CCC と言うのを妨げるものではなく、私はすべてのリレーに CC を送り、プールを行うつもりですが、私はすべてを CC するつもりです。
しかし、その時点で、そのようなクライアントは、ある種迷惑で悪意のあるものになるように構築されています。そうすると、あなたは基本的にスパムメールを作成していることになりますよね？しかし、デフォルトの状態では、この新しい電子メール タイプのランデブー プロトコルを使用するクライアントの構築を開始したい場合、全員を CC するだけではないと思います。それがすべてではないように。
メタデータを追加する最大のポイントは、メッセージを特定の場所に到達させることと同様です。そして、これは実際には遠ざかりつつありますが、これらのことをやり始めると、検閲への耐性が低くなります。リレーを終了するために送信するのではなく、特定のリレーに送信することになり、検閲される可能性があります。
この件について人々の考え方を変えるために私が考えていることの 1 つは、実際には検閲済みのモデルがいても大丈夫だということです。みんながとても集中しているように、私はヴェラーがこのことについてよく話していることを知っています、彼のモデレートされたコミュニティで、彼はそれが検閲に耐えられるように、さまざまな中継で機能することを本当に望んでいます。それで大丈夫です。しかし、簡単に検閲できる方法でこのプロトコルを使用することはまったく問題ないと思います。あなたが本当に望んでいることは...社内にリレーがある場合、そこには従業員からのメモのみが含まれるようにしたいと考えています。技術的に全員を検閲しているようなものです。それで、おそらく私たちは、それは…人々は考え方を変える必要があると思います。
同様に、完全に分散化されない他のタイプのモデルも登場するでしょう。 6 つの異なるリレーに送信する必要があるようにプロトコルを設計する必要はありません。特定のリレーに送信してもまったく問題ありません。特定のリレーでランダムなメモが得られるだけではないように、メモ上でそれを伝えるためのより良い方法が必要です。
検閲への抵抗について私が考えるのは、いくつかの点で検閲への抵抗が必要だということです。検閲耐性は非常に高価であり、検閲耐性を高めようと思えば望むほど、プロトコルの構造とアーキテクチャの観点からコストが高くなりますが、私たちが実際に望んでいるのは、検閲耐性が終わりに達することです。パーミッションレスのイノベーションであり、パーミッションレスのものを実現できると思います。あなたが説明しているようなことについては、リレーレベルで局地的な検閲を行うことができ、コミュニティに参加している場合は検閲される可能性があり、検閲を受けていてコミュニティに参加したくない場合は、参加することができますどこか別の場所ですよね？
そして、このようなコミュニティについて話しているのであれば、それを正しく行うためのさまざまな方法があると思います ビクターには彼のやり方があり、それは検閲への抵抗というよりも、コミュニティベースのリレーがどのように行われるかに焦点が当てられています、このリレーはこの特定のコミュニティに関するものですそして、私たちはあらゆる方法でそれを行うつもりだと思います、そして、それがアイデアの市場のようなものになることを知っているでしょう、そしてそれらのいくつかは最終的に他のものよりもうまくいくでしょう、なぜなら私たちが今座っている場所から私たちはたくさんの探求をしているからですすること。
そう、完全にその通りです。それが私がNIP 65が好きな理由です。リレーベースのコミュニティの一員であり、そのリレーによって検閲を受けるというモデルに到達している場合でも、ディスカッションに参加している人々は選択できるからです。そのコミュニティによって検閲を受けている場合は、どこかにメモを取りに行く必要があるため、コミュニティのリーダーに暴露される可能性がありますが、人々はオプトインして他の場所からメモを取りに行くこともできるため、コミュニティの分岐点のようなものになります。
そうですね、他に何が言いたいですか？
話題のリレーに関して、リレーには入ってくるコンテンツから身を守る方法が必要だと思いますか。その規模は機能しますか?
何を言っているのか分かりませんが、ある種のコンテンツのモデレーションです。
たとえば、通常の哲学リレーを実行したいのですが、哲学についてのディスカッションのみが必要です。私が望んでいるのは、gbobal に行ってエアドロップではないようになりたいということです。私は哲学的な議論だけをしたいのです。たとえば、私が philosophicalrelay.com を作成し、人々がそれを Damus、primal、gossip に追加し、フットボールについて話し始めたとすると、それも philosophicalrelay に公開され、ああ、これはと言って公開キーをホワイトリストに登録できます。男は哲学について話す時間の 25% を話しますが、私は残りの 75% をまだすべて取得しているので、個々のノードを検査する必要があります。モデルが存在することで機能すると思いますか?
そうですね、すべては私に訪れるのです。コンテンツのように、これは哲学のためであるというノード上の何かをマークする必要があるということが常に表示されます。つまり、彼がこの 2 つのアイデアを使用して哲学リレーに具体的に明示的に送信しているようなものなのか、それともハッシュタグではないかもしれない、あるいはハッシュタグを使用できるかもしれないというようなトピックを売り込む方法があるのかもしれません。ハッシュタグと重複します。ハッシュタグと重なったり、あらゆる種類の重なりが重なったりします。これらのアイデアはどれも完全に支離滅裂ではありません。そうですね、リレーは哲学のハッシュタグを持たないものをすべて拒否したり、すべて哲学に基づいたアカウントからの公開鍵をホワイトリストに登録したりすることもできるので、それが最善の方法かどうかはわかりません。
ノストラ、ワイン関係者は努力していると思います。彼らはハッシュタグに基づいた話題のリレーのように試みましたが、うまくいかなかったようです。
はい、最大の問題は、人々がたわごとをスパム送信することです。だから、Damus に付け加えようと考えていたことが 1 つあります。今、話が脱線しているかどうかはわかりませんが、次のようなハッシュタグについて話しています。それは単純なもので、おそらくノード上の最初のハッシュタグがトピックとしてカウントされるので、単にスパムを送信することはできないということです。
申し訳ありませんが、私は自分のプロジェクトを正当にシリングしています。先ほどその話をしました。情報トリプルと呼ばれるものを使用してメタデータに関する作業を行っていたので、まさにそれを解決することに取り組んでいます。それでは、カンファレンスに少しだけ参加しましょう。いいですね。
いいえ、はい、私たちは間違いなくあなたが知っているすべてのアイデアが必要ですこれはコミュニティ、トピック、そしてそれらを実装する方法のようなものだと思いますが、管理されたコミュニティであればコミュニティベースであるべきです、これらはすべて私たちがまだ持っているアイデアです私たちは今、なんとなく考えているところだけど、ご存知の通り、マイクが言ったように、あらゆることを試して、どのコミュニティが最もうまく機能するかを確認するつもりだと思います。
あなたのモデルでは、電子メールのようなアイデアがとても気に入っています。リレーが npub のような ID を持っている場合はどうなるでしょうか?ほとんどの場合、それはあなたが望むようなものです私にはわかりませんが、あなたが具体的に特定の場所に送りたいかどうかはわかりません。だから、それがあるだけでIDが得られるのは良いことですが、それでもメモが特定の場所に届くことを望んでいます。なぜメモ自体にリレーが必要になることを知っていると思うのですか。
リレーにはアイデンティティがあり、アイデンティティと通信するか、URLの代わりにアイデンティティを参照することは間接的なものであると思います。そのため、これをこの公開キーリレーに送信していると言うことになり、それは現在あるマッピングのようなものです。このDNSですが、私たちはDNSを管理していないので、変更される可能性があります。再マップすることはできますが、それでも同じ公開鍵であるため、異なるDNSアドレスを移動できるリレーへのIDを持っているようなものです。これは昨日私がこのことについて聞いたばかりです。昨日この話をしたのは、ヒントについて考えていたからで、URL がすべて破壊され、10 年後に何が起こるか考えていたからです。PA があれば、もう少し移動できます。簡単に切り替えてすべてのヒントを維持できるようなものですが、URL は難しいです。正しくコントロールすること。
ダムスでは狩りの多くを行うことも、狩りに関わる作業もできないと思います。なぜなら、私は固定リレーを持っているからです。ランダムなリレーからプルしたくありませんし、それらはいずれにせよ時間の経過とともに死ぬでしょうから、つまり元に戻ることを意味しますDamus の初期の頃は署名検証をまったく行っていなかったので、ゴシップ モデルを使用すると、人々があなたを送信するだけで大惨事になるだけですが、今では署名をチェックしていますが、これが大きな理由の 1 つでしたが、ご存知のとおりです。初期の頃、人々はダマスを完全に壊すような恐ろしいバグの多いリレーのようなものを構築していましたが、その中には悪意のあるものも含まれていました。ダマスはまだそれらのリレーに対して本当に強化されていないと思います。そのため、プロフィールに何かを入れてもリレーから読み取られたままにすることができますユーザーエクスペリエンスを壊すこともできます。
そうですね、私はそれについて考えていました。これが私がどのように考えるかの一例です。Web サイトにアクセスし、その Web サイトが Web ブラウザーにこの Google フォントをロードするように指示し、その後、ブラウザーが次のようになったとします。グーグル、そして今、グーグルは私がどのウェブサイトであったかを知っています。私はこれらのことを Google に知られたくないので、基本的に私のブラウザに ublock Origin と呼ばれるものを入れています。これにより、ページがロードできる正確なリソースを制御できます。 Google からフォントを読み込もうとしていることはわかっています。フォントのデザインがどのようなものかは気にしません。ただ、Google に自分が常にどこにいるかを知られたくないだけです。だから私はそれをブロックしますよね？ Web クライアントは常にこれを実行し、何をロードするかを指示しなかったものを自動的にロードするだけです。それを繰り返すべきではないと思います。アウトボックス モデルを引き続き使用できる、よりスマートなクライアントを用意すべきだと思いますが、ユーザーにホワイトリストの制御を与え、私がそこから引き出すつもりであると言うか、このリレーが不正行為をしているとたまたま知っていると言うためにブラックリストを作成する必要があります。私たちはそこには行かないよ。誰かの送信ボックスリレーがそこにリストされていても気にしません。そこでは使用しません。
そうですね、私はより分散化されたものに移行し、ランダムなリレーからの取得をよりオープンにして、ブラックリストを気に入る方法を考えていました。したがって、リレーが誤動作していることに気付いた場合に実行できる特定のテストのようなものがあります。おそらく、クライアント内でそれをコード化することができます。「ああ、何か悪いことが起こっていることを検出して、それを自動的にブラックリストに登録するだけです。そのようなテクニックを使用できます。」
そうですね、同じコミットで ndk に送信トレイを実装したとき、ブラックリストに登録しました。そう、それは絶対に 100% 基本的なものだからです。
ダモスエクスペリエンスのようなものを打破することに関しては、ユーザーが騙されてアクセスできる邪悪なリレーを追加する可能性があるため、邪悪なリレーを処理する必要があります。誰かのプロフィールはわかりませんが、リレーがリストされているのが表示されますが、大丈夫ですそれは自動的ではありませんが、そうです。
私がいつも気に入っているのは、それは常にユーザーの決定権であり、コンピューターの決定権であるというものです。
また、実際の悪の限界は、実際にできることはそれほど多くないということです。できることはイベントを送信することだけです。イベントには特定のフィールドが含まれているだけです。本質的には非常に単純な文字列であり、署名されているかどうか、検証が機能したかどうか、そうでないことによる攻撃対象領域はそれほど多くないと思います。私が言及できること。私には自分のことがたくさんありますが、まだしっかりしていないので、たとえば、広告やなりすましを返すリレーを作成することもできます。つまり、そこには信頼の網があり、それを見ることができますが、親切にすることができます時々奇妙になることがあるので、快適になる前にダムスを強化する必要があるように感じます。
このバフィーをクエリするのと同じように、リレーからの結果についてダムスをチェックしますか？他のパブキーからのリターンが必要なので、そのようなこともあります。実際には厳密なチェックは行っていないので、いくつかのことを除いては基本的に好きですそれは似ていますが、必ずしも正しいわけではありません、はい、やはり最も古い Nostr クライアントの 1 つであるため、これは一種の風変わりであり、ゆっくりと試して、すべてを修正しようとしています。そして、nostr DB で私の計画を次のようにします。 nostr DB はネイティブ NDK のようなものなので、そのロジックの一部をそこに構築し始めることができ、Damas Android とモノの間でそのロジックを再利用できます。
それで、私がこのアウトボックスモデルに取り組み始めたのは、約1年前の昨年11月にクライアントについて書き始めたとき、よく考えたのですが、これらのさまざまな人々をフォローしたいのですが、彼らのメモがどこにあるかわからない、どうやって見つけることができますか？アストラルとダムスが一種のコンテンツでリレーリストを共有していたことは知っているので、ある意味明らかではありませんでしたが、それを選択するだけで済みました。 つまり、あなたはそれを使用して独自のクライアントを設定していましたが、私はそれを選択することができましたそれを覗いて、ああ、ここが彼らの物が置かれている場所だ、私が彼らをフォローするためのメモを取得する場所だ、と言うだけです。彼らはまた、あなたが時々見ることができる推奨リレー URL ヒントでもありました。私は人々にリレーを nip 5 と Fiatjaf に置くよう提案しました。実際、それが nip への私の最初の貢献だったと思います。そして、Fiatjaf はそれを受け入れて、あなたがあなたのリレーをリストできるようにしました人が物を置いている場所を見つける方法もいろいろあるのですが、それが私が最初にやろうとしたことの一つだったので知りませんでした。ただ、人々はこうやってやっているに違いないと思って、調べたこともありました他のクライアントは、単にリレーをリレー プールとして選択しているだけであることに気づきました。
そう、Damus の場合は、ちょうど分散型ソーシャル ネットワークの概念実証を構築しようとしていたようなもので、すべて異なる人が所有する少数のリレーがあったのです。私にとってはそれで十分だと思っていましたし、リレーに送信するだけでリレーから取得するだけだと思っていました。明らかに、全体として、長期的なスケールで、より大規模でより分散化されたものを考えている場合、それは機能しません。だからこそ、Damus はおそらく、最近では何と呼ばれていようと、よりアウトボックス モデルに移行することになるでしょう。 、でもそれはうまくいきます、そしてそれはかなりうまくいきます、そして今のように私たちはめちゃくちゃ速い炒め物リレーを持っています、それでそれは私が好きにしているものの一つのようです、まあ、procr on私はまだ到達する必要がありますが、ええ、それは重要です。
そうですね、これは技術的に難しいので、実行するのが難しい作業です。非常に曖昧で、人々があなたがやっていることに気付かないほど光沢がまったくなく、アプリケーションのパフォーマンスを悪化させると主張することもできます。
そうですね、実装中に多くのバグに遭遇したとおっしゃっていましたが、これは単純な実装ではありません。
私はそこにほぼ 1 年バグを抱えていました。それは、フォローしている 150 人をいくつかのリレーがカバーしていると思っていたのですが、そうではなく、実際には 15 個のリレーであり、実際にはクライアントがデータベース接続があるリレーに公開鍵を割り当てていたことが判明しました。その割り当てのスコアは非常に低く、場合によってはゼロであったため、その割り当てを行うべきではありませんでした。はい、いいえ、接続を最小限に抑えたいと言う意味で最適化したい場合は難しいかもしれません。冗長性のために少なくとも2回フォローしているすべての人をカバーするために可能な限りリレーし、実際の人とその人の間の関連性が高いこと、つまり、それが彼らが指定した送信ボックスであるか、または何らかの理由で彼らが常に投稿している場所であることを知っていますそして、そのセットを計算するには、そのアルゴリズムについて考えるさまざまな方法があります。いくつかのスコアを作成してからそれを並べ替え、リレーを選択するために最適なスコアを選択しようとして、リレーを選択したら、そこで機能する可能性のあるすべてのパブキーを調べて、次のように割り当てようとするという、一種のアドホックなものを思いつきました。できるだけ多くのリレーを選択し、すべてのリレーがカバーされるまでそれを繰り返すだけです。最も賢いアルゴリズムではないかもしれませんが、考えて書くのはかなり簡単でした。
このモデルで私が気に入っている点は、これを実装したいと思う主な理由のようなものです。家にリレーがあるのと同じように、人々が自分のリレーを実行できるように、パブリックにアドレス指定可能であれば、実際に便利であるだけではないということです。バックアップが必要だ それが私にとって重要なことだ 現時点ではリレーを実行するためのあまり説得力のある議論がないという事実 個人リレーを実行する唯一の説得力のある議論はバックアップであるようなものだが、それは実際には十分ではないこれは議論としては十分な説得力がありませんが、多くのクライアントがこのモデルを実行していて、あなたを悩ませているすべてのイベントがリレーに書き込まれている場合、バックアップはバックアップとしてより完全なものになります。自分が書いた内容だけでなく、自分に宛てた内容も含まれているため、より説得力が増します。
これが興味深いと思うもう 1 つの理由は、リレーのプライバシーの問題について少し考えているからです。Nostr 内のすべての情報は確かに公開されていますが、リレーに送信するリクエストのほとんどすべては、そのリレーにのみ固有であるためです。現時点では、すべてのクライアントは基本的に、接続されているすべてのリレーに対して必要なものすべてをクエリします。したがって、あなたが接続しているすべてのリレーは、あなたが何をしているのか、どんなものをリクエストしているのかを正確に見ることができます。つまり、誰かのプロフィールにアクセスしてスクロールしていると、あなたが毎朝大丈夫であること、この人のプロフィールをチェックしていること、この人をストーキングしていることを彼らは本当に知ることができますよね？ゴシップ プロトコルも役立つと思います。よし、このリレーにいくつかのリクエストを送信します。これら 3 つのリレーは、実行されるイベントの点で非常に似ていることはわかっています。そのため、すべてのリレーのすべてではなく、すべてのリレーを同時にページインするのではなく、ページを表示することにします。ここにいくつかを送るつもりですが、あなたが何をしているのかの地図を入手するのは少し難しいです。
全体がより分散されます。分散できるので、スケーラビリティにとっては良いことになります。 1 秒前に忘れていたことの 1 つは、スケーリングできることと、検閲などになった中心的なものから抜け出すことができることと、実際に不必要にスケーリングすることとの間には違いがあるということです。必要なのは 50 個のリレーだけである可能性がありますが、それはわかりません。つまり、50 個のリレーというのは、私にとっては大変な競争のように思えますが、どのリレーも気に入らない、自分のリレーが欲しい、別のリレーを追加したいなど、常にノーと言える能力が必要です。それを行う自由があること。必ずしも全員が個人リレーを持つ必要があるわけではありませんが、そうする人もいます。
Nostr が死ぬか、Nostr が 10,000 人か 100,000 人だけが 50 個のリレーを使用するようなニッチなものにならない限り、50 個のリレーが機能するかどうかは、リレーするビジネス モデルがあるかどうかにかかっていると思います。ユーザー。私はその数字を自分の考えから引き出しているだけです。リレーが何個必要かわかりません。つまり、いいえ。
しかし、それは興味深い疑問を引き起こします。なぜなら、リレーは、リレーを実行することの経済的側面がまだほとんど解明されていない部分の一部であると私は思うからです。そして、私たちがノストルの胎児期の前段階にいるのと同じように、これが非常に重要であるかどうかはわかりません。重要な問題はまだ解明されていません。50 が実数である可能性もありますが、それは 50 個ほどあるということを意味します。
実際、今ではそれ以上のものがあります。そう、メリン・カルバロスはリレーや持続可能性などについて話しており、私は彼の言うことを信じるつもりです。私はこれらの数字を見ていないので、検証しないでください。しかし、彼はリレーの数が減少していると述べました。私にとって、それは理にかなっています。なぜなら、今なぜあなたはリレーを実行するのでしょうか、バックアップとして何でもOKですが、ええ、ノストラワインやエデンのようなプロのリレーを実行できるように実行するのですが、Dがどれだけあなたを好きかどうかはわかりません。」再、それは大きなリレーですが、どれくらい投資しているかわかりません。そうですね、月額300円くらいですかね。そうですね、それは大したことではありませんが、Nostr が 100 倍に成長すれば、それはそうです。 Whiz は、多額の価値のあるサーバーをたくさん接続してくれたので、すぐに実行される大きなリレーがたくさんあります。それで、これが私に与えました、あなたたちが送信箱モデルについて話していました、それをどのように私のアイデアと電子メールを備えた非同期モデルと組み合わせることができるかについて考えさせられました、そして私はそれらが非常に互換性のあるアイデアであることに気づきました。それで、想像してみてください、それらがあなたの正しいリレーであり、あなたが読んだり読んだりするリレーであることがわかったら、具体的に私のクライアント、もし私が電子メールクライアントを持っているなら、私はその 2 つを入力すると、あなたのメッセージを受け取ることができるでしょう。私はそれらのリレーを取得し、CC の 2 つに入れて、それをメモに含めるだけです。これは、このメモの目的が実際に非常に興味深いものであることをリレーに知らせるもう 1 つの方法です。
DMリレーの話はまだしてないですよね？なぜなら、私とビクターにはさらに多くのものがあったからです。つまり、彼が他の4人と同じようにリストされている中で、そのうちのいくつかはおそらくアーカイブリレーのように暫定的に通過していると思います。物事をアーカイブする場所を人に教える必要はありませんが、一部のリレーを受信トレイとして使用したい場合もありますが、一部のリレーは特に、イベントを受け入れるだけで送信しないため、より優れています。彼らは後退します。したがって、すべての DM をその DM に入れて、たとえ復号化できなくても、他の人が DM のコピーを入手できないようにしたいと考えていますが、できればコピーを持たせたくありません。したがって、リレーランデブーの使用法など、追加のタイプがある可能性があります。
私が興味を持っていることの 1 つは、これを処理する方法がありませんが、種類固有のリレーです。私が実行している紫色のページは、種類 0 と 1002 を提供し、次に nip 65 を提供するページです。人々はそのリレーを使用し、常に種類のページを公開しようとします。これはリレー リストに含まれているため、クライアントはそこに送信することになり、常にそれを拒否するつもりです。これは実際、Damus にまだ追加していない主な理由の 1 つであり、プロファイルアップのみがそこに送信されるようなコードを追加する必要があったためであり、それは私が書かなければならない余分なコードでしたが、ご存知のとおり、それで私は気づきました私のリレーリストには、「これはプロファイルリレーです。そこにプロファイルの種類を送信するだけなので、追加する必要があるものはすべて」というようなメタデータが必要であるようなものです。
はい、それを仕様化する必要があります。しかし、nip 11 は、リレーがどのような nip を行うかを知っていると言っていますが、これらの一部は nip ではありませんよね?そういうことですよね？これはニップではありません。これは一種です。そうですね、種類 1 を受け入れないわけがありません。私のクライアントも含めて、人々が自分でリレーを選択する場合について、クライアントはもっと改善する必要があります。そのリレーが意図していること、または正しく動作するように設計されていることと実際に一致すること。このリレーをアウトとして設定します。紫色のページを送信トレイとして設定します。私のものを受け入れてくれないからうまくいきませんよね？したがって、プロトコルでこれを指定した場合に、クライアントがここに送信ボックスに適していると宣伝するリレーがあると言えるようにする何らかの方法が必要です。これらは受信箱としてうまく機能すると言っているリレーです。これらは DM として設計されたものです。これらは広告用に設計されたもので、パープル ページは広告とディスカバリーです。
つまり、コマンドの結果を使用できるかもしれないので、Nostr にコマンドの結果を追加しました。以前は、リレーにメモを書いても、それが書かれたかどうかを教えてくれなかったようで、多くの場合、あなたが好きだったからです。何もかもが空洞になってしまうので、コマンドの結果はこのアイデアで、応答コードを送信するのと同じように、正常に書き込まれたようなものですが、正常に書き込まれなかった場合は、実際には小さなエラーメッセージをイベント内なので、「ああ、種類 x しか受け入れられないことがわかっている」のような場合には、これを使用できるかもしれません。おそらく、コマンドの結果からヒントを受け取り、リレーを自動的に構成することができます。これは興味深いことかもしれませんが、
分かった、分かった、分かった、ここでやめておこうか分かった分かった、分かった、分かった、ありがとう ありがとう！
About YakiHonne:
YakiHonne is a Nostr-based decentralized content media protocol, which supports free curation, creation, publishing, and reporting by various media. Try YakiHonne.com Now!
Follow us
- Telegram: http://t.me/YakiHonne_Daily_Featured
- Twitter: @YakiHonne
- Nostr pubkey: npub1yzvxlwp7wawed5vgefwfmugvumtp8c8t0etk3g8sky4n0ndvyxesnxrf8q
- Facebook Profile: https://www.facebook.com/profile.php?id=61551715056704
- Facebook Page: https://www.facebook.com/profile.php?id=61552076811240
- Facebook Group: https://www.facebook.com/groups/720824539860115
- Youtube: https://www.youtube.com/channel/UCyjDDtWFCntGvf4EyFJ7BlA