（クライアント側が頑張ることで、）冗長構成になるようには設計されていますし、自身のポストを投げているリレーサーバ（3台程度を想定）が運悪く一気に皆死ぬことは稀でしょうし、それが起きてしまったとしても、秘密鍵さえ手元でちゃんと管理していれば、新たなリレーサーバにPOSTを投げるよう設定することで過去の投稿を行った人物と同一の者として、利用は継続できるはずです。

NIP-05認証をしてあればさらに良し。

（クライアントが、接続していたリレーサーバの情報やプロフィール情報などを保存していなかった場合、そこいらの情報の入力し直しは必要になるはずですが）

系全体としてリレーサーバを増やせばスケールするかというと、ある程度はするでしょうが、同時にクライアントの処理負荷や通信量が増えてしまうというのが今の仕様の課題だと認識しています。

とはいえ、グローバルのTLの受信を止めてしまえば、フォローしているユーザのPOSTやLikeの情報ぐらいしか多分流れてこないか、少なくともクライアントがリレーサーバへの最初の受信リクエストを送る際に適切にフィルタ（条件にマッチするデータのみが流れてくる）を設定すれば、通信量の問題はどうにかなるのでは？とも思っています。

（Websocket接続=リレーサーバとの接続、が大量になった場合に、通信量がさほど多くはなかったとしても、クライアントの処理負荷が増大する、といったことがあるのかもしれませんが、そのあたりはまだ私には知見がありません・・・）

nips_changes は古の技術「シェルスクリプト」で動いております。

“If a platform is a silo, a protocol is a river: no one owns it, and everyone is free to swim.”

— #[0] on #nostr

IPFSもそうだけれど、非中央集権的なアーキテクチャで何等かのアプリケーションを実現しようとした場合、計算資源なり、ストレージ資源なり、ネットワーク資源なり、オペレーションコストなりを提供しないといけない者を必ず要するはずで、その者に対するインセンティブ設計が難しい。

技術的なところでのアーキはそこの設計の後に考えれば良いぐらい。

Bitcoinだのの暗号通貨や、Winnyなんかで知られるファイル共有ソフトなんかはそこらへんがうまくいっているので、システムとして存続している。

ちなみに、Winnyに関しては、Poenyという、実装が公開されているWinnyのプロトコルを実装したポエム共有ソフトがあって、それを用いて少し前にWinnyのネットワークに接続してみたが、今でもネットワークは存続していて、アレげなファイルの情報などが行き交っていたいた。。。

知り合いとのD,、

スポットで→単発的に、って意味か。

分散型SNSとして成り立ってるから、災害で1つのリレー止まってもほかで書き込めるってことに気づきました。災害メッセージを残すサービスがるように、専用のハッシュタグで動いてるリレーサーバーに投稿が残せて、それらを確認する専用アプリがあればと。

アプリあればハッシュタグなくてもどうにかなりますかね

リレーサーバーを登録してなくても動いてるところへ自動で書き込めるって仕組みが作られないと行けないことにはなります

地震速報を受ける際には2つ方法があって、1つは XML のポーリング、もう1つは webhook (こちらは試験的だった記憶) があって、前者だとおそらく NERV には勝てない。