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

Transcript

1. Nostr Web Client のための (Service) Worker 活用法 ぽーまん (@penpen_png) Nostr 勉強会 #0
2. JavaScript を読んで Webページを動かす妖精 今回話すことをざっくり – JavaScript の妖精は 2 種類いる 動く系のWebサイト エンジンとスレッドとコンテキストを混同させる 紛らわしい比喩になってしまって反省している Main Thread (出演: ゴブリン) Worker Thread (出演: ピクシー) 読む 動かす
3. 今回話すことをざっくり – ほとんどの仕事はゴブリンに向いている 「オレ、ゼンブ、ヤル。オマエ、シズカニスル。」 「……。」
4. 今回話すことをざっくり – Nostr Web Client はピクシーの新しい活躍の場かも？ ピクシー (Worker Thread) の数少ない仕事の例 - 描画を阻害しうるほど高負荷の計算 - HTTPリクエストのプロキシ - プッシュ通知 - バックグラウンド同期 - リソースのキャッシュ …and ✨ Nostr Web Client ✨ …?
5. Nostr Web Client の Connection 事情 – Connection はリレーの数だけある wss://nostr.aaa wss://nostr.bbb wss://nostr.ccc Nostr Web Client WebSocket Connection
6. Nostr Web Client の Connection 事情 – N 個タブを開くと N 倍増える wss://nostr.aaa wss://nostr.bbb wss://nostr.ccc Nostr Web Client (複数タブ)
7. 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 より。ブラウザあたりの値なのか、タブあたりの値なのか曖昧なのでもしかしたら見当外れかも。
8. 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 化を見据えられてうれしい。
9. Service Worker の出番だ！ – タブが増えても妖精さんはひとり messaging WebSocket Connection Service Worker は WebSocket 通信のプロキシはできないので、 Service Worker Thread 内で WebSocket を new している。
10. これやってること本当に新しい？ - 同様の事例は寡聞にして存じ上げない …… が、WebSocket の接続をまとめあげようというだけの話 なので、正直言うほど新しいとも思えない - とはいえ、これだけの本数の Connection を維持する 必要があり、かつ Subscription の数に限りがある という条件は Nostr ならではと言えそう - Service Worker の珍しいユースケースではあるのでは 大見得を切ったかもしれない
11. (おまけ) Service Worker がついでに Nostr Web Client にもたらし得るもの - よくあるやつ - タブをすべて閉じていても接続を維持する - キャッシュの半永続化 - リロードに強くなれる - モバイル端末で、ホーム画面への Push 通知 - Android のみ。iOS はもうすぐ。 - Nostr に特有のやつ - Subscription の最適化 - 複数タブからの Sub 要求をうまく 束ねて Sub 数を減らせるかも - キャッシュの一元化 - ストリームに流れてきたメッセージは Service Worker に溜めてしまい、 アプリケーション側からそれらを pull して利用する - Main Thread が食うメモリが減る
12. まとめ - Nostr Web Client で、Main Thread に WebSocket のコネクションを持たせると アプリケーションがタブ数に対してスケールしない。 - 代わりに、Service Worker Thread に WebSocket のコネクションを握らせる ことで、タブ数の増加に対して頑健になる。 - コネクションを Service Worker に一元化することで、複数タブ間の Subscription 管理を最適化する余地も生まれる。 - ……というのは別に Shared Worker でもできるが、 Service Worker のよくある用途は Nostr Web Client にもよくマッチするので ぜひ Service Worker を使おう。 - おつノス！