クライアントを作って みてわかったこと Nostr勉強会 #3 

あれ、前に作ってませんでしたっけ 

基本構成 クライアント リレー REQ EVENT 要求すると、それまでのイベントと、以降のイベントが ぞろぞろと飛んでくる これだけなら簡単 

得られるデータは色々足りない 投稿者の公開鍵(=プロフィール) 返信先 返信相手の公開鍵 → 逐次、得られた情報に対する追加情報を取りに行く必要がある 

ごちゃごちゃ クライアント リレー Kind 1REQ EVENT Kind 0REQ Kind 1REQ Kind 7REQ 

いろんなリレーから五月雨に クライアント REQ EVENT 要求すると、それまでのイベントと、以降のイベントがぞろぞろと飛んでくる。 気ままに。あるいは飛んでこないかも。時間かかるかも。 指定してないやつ返してくるリレーすらいる。 リレー リレー リレー EOSE 数値カウントがゆっく り上昇したり、投稿や 名前が少し経ってから 読み込まれる理由 

結局どうかというと • つまりこう、HTTPリクエスト投げたらきれいに応答が返ってくるのとは 違う処理を書くことになります。 (ある意味、パイプラインを自前で実装するのに近い。) • さらにリレーごとに購読数には制限があります。 • WebSocketが切れてることもあります。 • 購読しっぱなしのものと、単発で取得したら終わりのものとを 混ざらないようにする必要があります。 • すべてのリレーから返ってくるのを待つと遅すぎます。 

• どのリレーに何をリクエストしたか • 帰ってきてるものは適切か (フィルタ外、すでに登録解除したものでないか) • タイムアウトの管理 • お片付け(購読解除) • キャッシュ • 再接続時の再購読処理 • 一番最初に帰ってきたリレーの結果が正しいとは限らないが、 全部のリレーの回答を待つと遅い。(重要度別に処理を分ける必要) 管理すること 

• とにかくUIを非同期にしておく戦略が必要そう • リアルタイム性を重視するのか、 レスポンス性を重視するのか、 安全性を重視するのか、シチュエーションに 合わせた取得方法の選定が必要そう (ミスると → フォロー吹っ飛び) • 通信が安定しない環境(モバイル等)ではよりしんどさが増す → 旧来のWebサービスみたいに、責任持って安定して 応答するサーバーを設置してそこで処理したくなる… さらには 

クロスプラットフォームクライアント Nemesia for nostr 開発中 (完成時期未定)