Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Nostr Web Client のための (Service) Worker 活用法

penpenpng
February 22, 2023

Nostr Web Client のための (Service) Worker 活用法

penpenpng

February 22, 2023
Tweet

More Decks by penpenpng

Other Decks in Programming

Transcript

  1. JavaScript を読んで Webページを動かす妖精 今回話すことをざっくり – JavaScript の妖精は 2 種類いる 動く系のWebサイト

    エンジンとスレッドとコンテキストを混同させる 紛らわしい比喩になってしまって反省している Main Thread (出演: ゴブリン) Worker Thread (出演: ピクシー) 読む 動かす
  2. 今回話すことをざっくり – Nostr Web Client はピクシーの新しい活躍の場かも? ピクシー (Worker Thread) の数少ない仕事の例

    - 描画を阻害しうるほど高負荷の計算 - HTTPリクエストのプロキシ - プッシュ通知 - バックグラウンド同期 - リソースのキャッシュ …and ✨ Nostr Web Client ✨ …?
  3. Nostr Web Client の Connection 事情 – Connection はリレーの数だけある wss://nostr.aaa

    wss://nostr.bbb wss://nostr.ccc Nostr Web Client WebSocket Connection
  4. Nostr Web Client の Connection 事情 – N 個タブを開くと N

    倍増える wss://nostr.aaa wss://nostr.bbb wss://nostr.ccc Nostr Web Client (複数タブ)
  5. Nostr Web Client の Connection 事情 – それって問題なの? A. (タブを増やしがちな人にとっては)

    はい。なぜなら: - まず単純に通信量が N 倍になって、つらい - これが何を意味するかはお外ノス経験者各位には伝わろうと思う - リレー側に設定された Subscription [^1] の Rate Limit に簡単に引っかかる - Twitter で言うところの「API 制限」に近い。要するに読み込みが止まる - ブラウザの WebSocket 接続上限は 200 前後のことが多い [^2] - そもそも NIP-01 が「リレーひとつに対して Connection はひとつまで」って言ってる - クライアント側としては違反したところで困りはしないが、お行儀は悪い - リレー側としてはシンプルに迷惑 [^1]: クライアントからリレーへの「あなたが常時受け取っているすべての情報のうち、こんな種類の情報だけちょうだい」という要求。 [^2]: https://postd.cc/websockets-caution-required より。ブラウザあたりの値なのか、タブあたりの値なのか曖昧なのでもしかしたら見当外れかも。
  6. Service Worker の出番だ! – その前に Service Worker って何だったっけ Nostr Web

    Client (複数タブ) Service Worker は Worker の仲間のひとりで、"同じWebサイト" に対してひとつ存在できる [^1] [^1]: 嘘ではないがとてもアバウトな説明。 2つ以上も存在できるし、 "同じWebサイト" が示す範囲は scope の設定によって変化する。 そもそもここで触れる範囲のことなら Shared Worker にだってできる。が、 Nostr Client としては Shared Worker を使うよりは Service Worker を 使ったほうが後々の PWA 化を見据えられてうれしい。
  7. Service Worker の出番だ! – タブが増えても妖精さんはひとり messaging WebSocket Connection Service Worker

    は WebSocket 通信のプロキシはできないので、 Service Worker Thread 内で WebSocket を new している。
  8. これやってること本当に新しい? - 同様の事例は寡聞にして存じ上げない …… が、WebSocket の接続をまとめあげようというだけの話 なので、正直言うほど新しいとも思えない - とはいえ、これだけの本数の Connection

    を維持する 必要があり、かつ Subscription の数に限りがある という条件は Nostr ならではと言えそう - Service Worker の珍しいユースケースではあるのでは 大見得を切ったかもしれない
  9. (おまけ) Service Worker がついでに Nostr Web Client にもたらし得るもの - よくあるやつ

    - タブをすべて閉じていても接続を維持する - キャッシュの半永続化 - リロードに強くなれる - モバイル端末で、ホーム画面への Push 通知 - Android のみ。iOS はもうすぐ。 - Nostr に特有のやつ - Subscription の最適化 - 複数タブからの Sub 要求をうまく 束ねて Sub 数を減らせるかも - キャッシュの一元化 - ストリームに流れてきたメッセージは Service Worker に溜めてしまい、 アプリケーション側からそれらを pull して利用する - Main Thread が食うメモリが減る
  10. まとめ - Nostr Web Client で、Main Thread に WebSocket のコネクションを持たせると

    アプリケーションがタブ数に対してスケールしない。 - 代わりに、Service Worker Thread に WebSocket のコネクションを握らせる ことで、タブ数の増加に対して頑健になる。 - コネクションを Service Worker に一元化することで、複数タブ間の Subscription 管理を最適化する余地も生まれる。 - ……というのは別に Shared Worker でもできるが、 Service Worker のよくある用途は Nostr Web Client にもよくマッチするので ぜひ Service Worker を使おう。 - おつノス!