Last Notes
オオトリです。
https://qiita.com/conference#day3
そういえば今日 Qiita のイベントに出るんだった。
たーごいるさん、真面目な人だと思ってたのに、まさかあんな事をするなんて。
オッ
https://x.com/polymarketjapan/status/2115654918090711199
RTX 4090 で 1 時間 $0.3〜0.7 程度、H100 で $2〜3 程度。切り忘れると課金になる。
RunPod というサービスで GPU 使わせてくれるらしいので、NIPs 知ってる LLM 作ってみようかなとか、思ったり、思わなかったりしている。
西山さんたぶん女流でやってた方が儲かってるはずなんだよね。あえてプロになるの凄い。
https://x.com/UN_NERV/status/2114531471193199094
おはようございます↑
https://image.nostr.build/aaa5d8be3342f2d227f2eb1ba202ffe2f8f046c491b4056510e0edf73f77e1e1.jpg
どんな言葉遣いをすれば、あの文章を上から目線じゃない様に書けるのか教えて頂きたい。
https://image.nostr.build/af477f7b2229bf52bfef6e91e3a585215bd5846ec1b911b305b8ee4fafebe1b6.png
いろんなところで PHP が言及されててちょっと嫉妬してきた。
https://image.nostr.build/6f406fe14f3571f2be47a3346edb2a2238778566cac197d58bd77c7ad72523f7.jpg
泉さん、少しながら期待していて悲しくなった。
https://x.com/nico_nico_news/status/2112767818135752896
めっちゃまずい
https://bsky.app/profile/swtch.com/post/3mydfmedrrc2d
猫氏、寝る時はケージで寝ていたが、昨日は初めてケージから解放してみる事にした。
嬉しかったのか分からんが、大興奮、僕の最中やノート PC のキーボード上を走り回った。そうだとしても、最後はケージに自分で戻って釣り下がってるハンモックでいつも通り寝るのだと思っていた。
が、最後は僕の横で落ちる様に寝た。
Nostr のリレー速度をブラウザから測るやつを作りました。
https://clask.compile-error.net/nostr-relay-speed/
接続時間 (WebSocket が開くまで) とクエリ応答時間 (REQ を投げて EVENT/EOSE が返るまで) を別々に出します。自分の回線から測るので、どのリレーが自分にとって速いのかが分かります。
リレー選びのお役に立てれば。
https://x.com/minpou_shindan/status/2112130134866112759
TVer is Japan’s free TV catch-up. Dramas, variety & anime with ads for ~1 week. Japan only.
limit は 1 以上の整数という明確化 (SHOULD)
https://github.com/nostr-protocol/nips/pull/2512
これはひどいw
https://x.com/asciijpeditors/status/2112046089142681977
器用な寝方しとんな
https://image.nostr.build/19b69925bfa45677178e7d7a0001d7ee5f702f698cd03a4374416b1be79f44a3.jpg
ユーザが多いなか申し訳ないが、これは CLOSED にするか、0 件を返すかして、strfry の現状の動作をバグ扱いさせて貰うしかない。
とはいえ strfry には strfry の問題があって、例えば不正な REQ に strfry は NOTICE しか返さないのでクライアントは知る術がない。
こんな感じに NIPs って穴が沢山あって、今見てるだけでも、まだ数個(十数個かも？)はあるんですよね。
あざます
https://github.com/nostr-protocol/nips/pull/2511
"one or more values" との関係は、確かに文面だけ読むと引っかかるところなんですが、CLOSED で拒否するのは避けたいと考えています。理由は 2 つ。
1つ目は、CLOSED がサブスクリプション単位であることです。["REQ", "sub", {"authors": []}, {"kinds": [0], ...}] のように複数のフィルタを送ったとき、空配列のフィルタが 1 つあるだけで、正しいフィルタまで含めて購読全体が止まってしまいます。0 件扱いであれば、他のフィルタはそのまま動きます。
2つ目は、今の実装との整合性です。公開リレーを 15 か所調べたところ、12 か所(strfry 系、NFDB、primal など)はすでに空配列に対して 0 件 + EOSE を返していて、CLOSED で拒否するリレーは 1 つもありませんでした。拒否を必須にすると、ほとんどの既存実装が仕様違反になってしまいます。
"one or more values" は「クライアントは空配列を送るべきではない」という送る側への要求で、今回の追記は「それでも空配列が来たときにリレーがどう振る舞うか」という受け取る側の取り決め、という整理をしています。
あるとすれば、"Clients SHOULD NOT send empty lists" のように送る側の要求を明記するくらいだと思います。
