Nostrプロトコルって何やねんという方はまず以下の記事などを参照いただけると良いかと。
さて、読者の方々がNostrプロトコルの概要は理解している前提で以下、掲題に関して。
数日前にNostr（プロトコル上で構成されたTwitterライクなマイクロブログ）で follow している、あるユーザが、Nostr（プロトコル）はリレーサーバを信頼してないという点でP2Pと同じである、リレーサーバはただのハブである、といった主旨のことを投稿していて、それを読んでハッ！っとひらめいたことがあった。
それは、Nostrプロトコルというのは、本質的にはクライアントをノードとしてpeer-to-peerでやりとりできるオーバレイネットワーク（以降、オーバレイと略記）に近いものを構成するプロトコルなのではないか、という見方である。
- オーバレイでのアドレスは公開鍵
- クライアントがオーバレイ上でのノードに対応づく
- 公開鍵を指定することでP2Pでの通信が可能
- ただし受信されるのは受信側が送信元からのメッセージを待ち受けているタイミング
- 送信時に待ち受けている状態であれば、そのタイミングで受信される
- 受信側が待ち受けしない（=要していない）送信元からのメッセージは受信されない
- 一度送信したメッセージは送信時に相手がオフラインでも、ネットワークに復帰したタイミングで受信できる
- 他のノード群に、ゴシップブロトコル*1等による他のノードとの連携を要する手法を用いずに、比較的高速にメッセージのブロードキャスト/マルチキャストが可能
- なお、この通信においても、受信側のノードは、送信時にオフラインでも、オンラインに戻った際にメッセージを受信できる
で、上のような通信特性を実現しているのが、オーバレイの下のレイヤにいるリレーサーバである。
クライアントから受信したメッセージ*2は、必要があれば他のクライアントにブロードキャスト/マルチキャスト可能であるし、メッセージングミドルウェア（なんちゃらMQといった名前を持つ類のもの）のように、あるクライアントから受け取ったメッセージは、他方のクライアントがリレーサーバに接続して、メッセージの受信をサブスクライブした時点で送信してくれる*3。
オーバレイとして見ると、明確に当てはまらないのは自身や他のノードが、メタデータ（フォローしているユーザの情報、接続しているリレーサーバの情報）を、（脚注の条件を満たすもののうちの）任意のノード*4について、ネットワークから取り出せる点。
この点は、冒頭で"オーバレイネットワークに近いもの"と書いているように、素直にオーバレイネットワークを構成するもの、と言っていない理由の一つ*5。
こう整理すると、クライアントの仕事（必要な処理の総量）がやたらと多い*6のも納得がいく。
他には、例えば、リレーサーバに保持させておいたメタデータが消えてしまったり、内容が欠けてしまったりするのも、オーバレイのレイヤから見るとネットワークが提供する謎機能を使ってる以上仕方なく、オーバレイ上のノード（自身およびその他ノード）によるフォローが必要なのでは？という話になりそうである。
実際、手動にはなるが、Webサービスとしてメタデータが飛んだ場合の復元を可能とするためのサービスが有志により提供されているが、当該サービスは内部的にNostrプロトコルを扱っており、それは一種のクライアントで、オーバレイのレイヤでいえばノードである。
*1:あくまで一例。もっと効率的なプロトコルを利用可能なアーキテクチャをとっている分散システムも多数ある
*3:メッセージングミドルウェアのように到達保証まではしてくれないが
*4:少なくとも取得対象のメタデータの持ち主が当該情報を書き込む先の1つに設定していて、取得する側も当該情報の取得先の一つとして設定しているリレーサーバが存在する
*5:他のノードの助けを借りずに、時差ありでメッセージを受信可能な点や、ブロードキャストができる点もおかしいだろうという話はあるが、それぐらいは特殊なオーバレイである、という整理にしてしまってもよいかな、と
*6:少なくともTwitterライクなマイクロブログのアプリケーションなどでは、ユーザのクライアントに対する設定にもよるが、多数のリレーサーバとWebsocketコネクションを持ち、大量のメッセージを処理する必要があるケースが多い
