Last Notes
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.
器用な寝方しとんな
https://image.nostr.build/19b69925bfa45677178e7d7a0001d7ee5f702f698cd03a4374416b1be79f44a3.jpg
limit は 1 以上の整数という明確化 (SHOULD)
https://github.com/nostr-protocol/nips/pull/2512
これはひどいw
https://x.com/asciijpeditors/status/2112046089142681977
とはいえ strfry には strfry の問題があって、例えば不正な REQ に strfry は NOTICE しか返さないのでクライアントは知る術がない。
ユーザが多いなか申し訳ないが、これは CLOSED にするか、0 件を返すかして、strfry の現状の動作をバグ扱いさせて貰うしかない。
こんな感じに 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" のように送る側の要求を明記するくらいだと思います。
NIP-01 に PR がマージされました 🎉
https://github.com/nostr-protocol/nips/pull/2504
REQ のフィルタで "authors": [] のような空配列を送ったとき、「何もマッチしない」が正しい挙動として明文化されました（MUST）。✌
これまでは仕様に書かれておらず、リレーによって扱いがバラバラでした。
・strfry などは 0 件を返す
・一部のリレーは条件を無視して全件を返す
・khatru や nostr-rs-relay では、EOSE の前は大量に返るのに、EOSE の後は何も届かない
例えば、フォローが 0 人のユーザーのタイムラインを取得すると "authors": [] になり、リレーによってはグローバルの投稿が流れてきてしまいます。
クライアント開発者の方へ: 属性を省略すると「全選択」、空配列は「何も選ばない」です。意図して使い分けてください。
前回の limit: 0 に続いて、境界値シリーズ第 2 弾でした。
NIPs の曖昧な仕様を明確にしていくシリーズ。時期の OpenSats ではそんな事をやってもいいのかもしれん。
PR にも書いたんですが、これ実装によりめちゃめちゃで、どっちに倒すか決められないんですよね。
フィルタで空を指定した場合（例: "kinds": []）にどう動くかを明確にする PR を出しました。
https://github.com/nostr-protocol/nips/pull/2504
がくとさんのふぁんくらぶ、かそうつうかかわされそうで...
うちの娘の学校にスターダスト所属の子が居て、数カ月前まで同じクラスだったんですが今は転校しちゃって、奥さんと「転校する前に参観日で見たかった！ざんねん！」と言ってる。
