Android Nostr クライアント [検索]

クソクライアントの排除のために nostr-filter が機能的に充実していくｗ (OpenAI Codex CLIのおかげ) https://github.com/imksoo/nostr-filter/tree/main

大昔にビデオストリームをepheremeral eventsでストリーミングしてたのよりもタチが悪すぎる。ユーザー数が多いから。yu-za-suugaooikara.

思想的にリレー薩摩守するつもりのクライアントはさすがにUA付けてきたら狙い撃ちでブロックする。

2月ぐらいから顕著に増えてるから多分そう。

Nostr運営も同時翻訳とかやればいいのに(妄想

okhttpは赦してる

Ephemeral Eventsの流入がほぼ0になったのでどっかの馬鹿クライアント側でこのリレーを使わないように修正されたっぽいな。ただ他のリレーの帯域をイナゴのように食い尽くしに移動しただけだろうけど。

strfry の前段に置いてる nostr-filter で、kind:1984 の REQ を変形するようにしてみた。 https://github.com/imksoo/nostr-filter/commit/e2255c9173963247d85adc74c6f38f76f74cf8c4 kind:1984 に複数の #p を付けた検索は、strfry が #p 側の index から広く候補を拾って、そこから authors や kind 条件で大量に落とす形になっているらしく、結果は少ないのに途中の仕事量だけ大きくなって数十秒かかってた。 なので前段でいったん #p/#e を外して authors + kind だけで upstream に投げ、返ってきた event を前段で #p 条件に照らして絞り直すように、「重い絞り込みを strfry にやらせず、取りやすい形で取ってから前段で仕上げる」感じに REQ を部分変形することで、kind:1984 の REQ だと直近では数 ms から数十 ms までかなり性能向上することが出来た。

Mirror,MirrorのYouTubeに上がってるライブ動画ってめっちゃ画質いいの凄いよな。

nostr-filterで重たいREQをバラしてstrfryでも処理しやすい形にクエリを変形する機構を仮実装し始めている。

nostr-filterで動的フィルタを充実させたものの、ずっと機械的にアクセスし続ける行儀が悪いいくつかのIPアドレス群は永久denyするようにしました。

現状のリレーの状況です。 -- まず全体として、通常の WebSocket 利用は普通に通っています。nginx の直近 2000 行では 101 が 1555 件で主流です。UA もかなり多様です。 - Amethyst - Wisp - damus - bitchat - fiatjaf.com/nostr - go-nostr - node - ブラウザ系 - okhttp/4.9.2 一方で、問題のある傾向は大きく 4 系統です。 1. Cloudflare Worker 系 - 主犯は 2a06:: - cf-worker: xxxxxxx.pages.dev - too many concurrent REQs を繰り返し、3回で Ban、解除後に再発 - activeSubscriptionCountForIP が 49 まで膨らむ 2. ephemeral / blocked kind の書き込み - 149.xxx.xxx.xxx が代表的 - blocked kind: 20001 や 22668 - それ以外の ephemeral kind は静かに破棄 3. 重い kind 1984 の REQ - 185.xxx.xxx.xxx - 192.xxx.xxx.xxx - などが processing cost block に到達 - authors と #p を大量に組み合わせた問い合わせが重い 4. nginx レイヤの 429 - まだ完全には消えていない - 直近では - 39.xxx.xxx.xxx → 181 - 14.xxx.xxx.xxx → 17 - 2a06:: → 12 - ただし以前よりはかなり偏在化していて、一般クライアント全体が踏んでいる感じではない 通常利用寄りの傾向も見えます。 - Amethyst, damus, bitchat, Wisp は普通に 101 - bitchat は継続的に来ているが、今のところ block 主体ではない - okhttp/4.9.2 も通っている例があり、一律悪性ではない 要するに今の構図は、 - 大多数の通常クライアントは通っている - 問題は少数の noisy source に集中 - 特に cf-worker 系、多重 REQ、重い 1984 検索、ephemeral/blocked kind 書き込みが主な負荷源です なので、現状の nostr-filter はかなり目的に合っています。次に手を入れるなら優先順位は 1. cf-worker を接続時点で落とすか 2. kind 1984 重負荷 REQ をさらに絞るか のどちらかです。

https://nym-4ae.pages.dev/ このチャットの裏側でCloudflare Workersが動くのは良いけど、何十個も並列でREQ出してくるのは止めて欲しいなぁ。。。

テスト的にokhttpを通してみるか。(Amethyst, FreeFromなどのAndroid系クライアントが軒並みBLOCKされてた)

AndroidでNostrクライアント作る人たち、ちゃんとユーザーエージェント名を出して。