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

Transcript

1. Nostr Web Client のための
   (Service) Worker 活用法
   ぽーまん (@penpen_png)
   Nostr 勉強会 #0
   

   View Slide

2. JavaScript を読んで
   Webページを動かす妖精
   今回話すことをざっくり – JavaScript の妖精は 2 種類いる
   動く系のWebサイト
   エンジンとスレッドとコンテキストを混同させる
   紛らわしい比喩になってしまって反省している
   Main Thread
   (出演: ゴブリン)
   Worker Thread
   (出演: ピクシー)
   読む
   動かす
   

   View Slide

3. 今回話すことをざっくり – ほとんどの仕事はゴブリンに向いている
   「オレ、ゼンブ、ヤル。オマエ、シズカニスル。」
   「……。」
   

   View Slide

4. 今回話すことをざっくり – Nostr Web Client はピクシーの新しい活躍の場かも？
   ピクシー (Worker Thread) の数少ない仕事の例
   - 描画を阻害しうるほど高負荷の計算
   - HTTPリクエストのプロキシ
   - プッシュ通知
   - バックグラウンド同期
   - リソースのキャッシュ
   …and
   ✨ Nostr Web Client ✨
   …?
   

   View Slide

5. Nostr Web Client の Connection 事情 – Connection はリレーの数だけある
   wss://nostr.aaa wss://nostr.bbb wss://nostr.ccc
   Nostr Web Client
   WebSocket
   Connection
   

   View Slide

6. Nostr Web Client の Connection 事情 – N 個タブを開くと N 倍増える
   wss://nostr.aaa wss://nostr.bbb wss://nostr.ccc
   Nostr Web Client (複数タブ)
   

   View Slide

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 より。ブラウザあたりの値なのか、タブあたりの値なのか曖昧なのでもしかしたら見当外れかも。
   

   View Slide

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 化を見据えられてうれしい。
   

   View Slide

9. Service Worker の出番だ！ – タブが増えても妖精さんはひとり
   messaging
   WebSocket
   Connection
   Service Worker は WebSocket 通信のプロキシはできないので、
   Service Worker Thread 内で WebSocket を new している。
   

   View Slide

10. これやってること本当に新しい？
    - 同様の事例は寡聞にして存じ上げない ……
    が、WebSocket の接続をまとめあげようというだけの話
    なので、正直言うほど新しいとも思えない
    - とはいえ、これだけの本数の Connection を維持する
    必要があり、かつ Subscription の数に限りがある
    という条件は Nostr ならではと言えそう
    - Service Worker の珍しいユースケースではあるのでは 大見得を切ったかもしれない
    

    View Slide

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

    View Slide

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

    View Slide