月野うさぎ (TSUKINO Usagi) on Nostr: ...
(クライアント側が頑張ることで、)冗長構成になるようには設計されていますし、自身のポストを投げているリレーサーバ(3台程度を想定)が運悪く一気に皆死ぬことは稀でしょうし、それが起きてしまったとしても、秘密鍵さえ手元でちゃんと管理していれば、新たなリレーサーバにPOSTを投げるよう設定することで過去の投稿を行った人物と同一の者として、利用は継続できるはずです。
NIP-05認証をしてあればさらに良し。
(クライアントが、接続していたリレーサーバの情報やプロフィール情報などを保存していなかった場合、そこいらの情報の入力し直しは必要になるはずですが)
系全体としてリレーサーバを増やせばスケールするかというと、ある程度はするでしょうが、同時にクライアントの処理負荷や通信量が増えてしまうというのが今の仕様の課題だと認識しています。
とはいえ、グローバルのTLの受信を止めてしまえば、フォローしているユーザのPOSTやLikeの情報ぐらいしか多分流れてこないか、少なくともクライアントがリレーサーバへの最初の受信リクエストを送る際に適切にフィルタ(条件にマッチするデータのみが流れてくる)を設定すれば、通信量の問題はどうにかなるのでは?とも思っています。
(Websocket接続=リレーサーバとの接続、が大量になった場合に、通信量がさほど多くはなかったとしても、クライアントの処理負荷が増大する、といったことがあるのかもしれませんが、そのあたりはまだ私には知見がありません・・・)
NIP-05認証をしてあればさらに良し。
(クライアントが、接続していたリレーサーバの情報やプロフィール情報などを保存していなかった場合、そこいらの情報の入力し直しは必要になるはずですが)
系全体としてリレーサーバを増やせばスケールするかというと、ある程度はするでしょうが、同時にクライアントの処理負荷や通信量が増えてしまうというのが今の仕様の課題だと認識しています。
とはいえ、グローバルのTLの受信を止めてしまえば、フォローしているユーザのPOSTやLikeの情報ぐらいしか多分流れてこないか、少なくともクライアントがリレーサーバへの最初の受信リクエストを送る際に適切にフィルタ(条件にマッチするデータのみが流れてくる)を設定すれば、通信量の問題はどうにかなるのでは?とも思っています。
(Websocket接続=リレーサーバとの接続、が大量になった場合に、通信量がさほど多くはなかったとしても、クライアントの処理負荷が増大する、といったことがあるのかもしれませんが、そのあたりはまだ私には知見がありません・・・)