クライアントを作ってみてわかったこと

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

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

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

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

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

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

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

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

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

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

クライアントを作ってみてわかったこと

クライアントを作ってみてわかったこと

Segment

More Decks by Segment

Other Decks in Programming

Featured

Transcript