一回目はNIPsのURLだと思って読んでください
darashi
_@darashi.net
npub1q7qy...wt9c
I built
Nostrasia timeline https://darashi.github.io/nostrasia2024/
nos.today https://nos.today
searchnos https://github.com/darashi/searchnos
nostrbuzzs https://nostrbuzzs.deno.dev/
二回貼ってしまった
max_limit: the relay server will clamp each filter's limit value to this number.
> max_limit: the relay server will clamp each filter's limit value to this number.
とあるから、clampすることが想定されていそうではある
なるほど、そういうアプローチもあるのかー
切られたせいで500件なのかちょうど500件なのかはわからんけど...
いちおうNIP-11にmax_limitがあるので、それを見れば切られる可能性があることはわかる
kindsなしのリクエストには4が含まれていないとして扱って、kindsに4が明示的に含まれたときにAUTHするようにすればAUTHの問題は大丈夫かも。あまり良い仕様ではない気はする
kinds無しのざっくりした購読でkind:4を取りたいことってなさそうだし、しれっと除外してくれると助かるけど仕様の一貫性を考えるとまあ仕方ないかなという気持ち
wss://nostr.wine はkinds無しのREQを送ると4が含まれていることになってAUTHが飛んでくる
つみれ鍋わよ〜😋 
PoW計算のたびに対象のcreated_atも更新していけば狂わないか
NIP-13 PoWはidの上位を0にするのでフィンガープリントとしては下位かインターリーブしたほうがいいかも。でもどこを使っても狙えば計算できるしあんまり意味はないかも。PoWの計算してる間に時刻狂いそう
strfryの受信時刻は勘違いかも。pluginには渡ってくるんだけど、DBには保存はされてないかも
成果報酬型っぽいのがあればいいなっていうのはアンケートに書いた
strfryも内部的には受信時刻が保持されてはいるはず
リレーがタイムスタンプをつけるのと、投稿を観測した第三者がタイムスタンプをつけるのと結局は変わらない
普通のクライアントに実装してフォロワーからの要求であれば自動でタイムスタンプしてくれるとかするとWoTっぽいかも
ほどほどの信頼度だけど数がたくさんあることでなんとかできないか？っていう気持ちがちょっとある
単一イベントで検証可能にしたくてこねくったけどオラクルレスポンスをリレーに別途保持してもらう形にすればずっとシンプルになる
NIP-03 は別イベントを付与するんだな、分散で付与する場合でもそれでもいいか、そうするとプロトコルは圧倒的にシンプルになるし