X や Google 風の検索クエリライブラリ書いた。
PostgreSQL の tsquery や SQLite3 の FTS5 クエリ、MySQL の boolean マッチのクエリを作る関数も含む。
これでもし NIP-50 がこの形式をサポートするなら、これを使おうと思う。
mattn
_@compile-error.net
npub1937v...haj6
Long-time #Golang user&contributor, #GoogleDevExpert Go, #Vim, #Windows hacker, ex-#GitHubStars, #runner.
vscode のぺろん?
問題は「おれにはそれ実装できねぇ」というリレー開発者を救う必要があるという点で、その場合 hello AND world を "hello" AND "AND" AND "world" として処理する選択肢を用意してあげんといかん。
そうなんですよね。僕もここ数日思っていて、検索だけ別に切り出した方がいいんじゃないかと。
ひとまず構想中の物としては、filter.search は単語リストを取る。クオート可能、カッコでのグルーピング可能。
hello world は "hello" AND "world"
"hello world" は "hello world"
"hello" "world" は "hello" AND "world"
hello OR world は "hello" OR "world"
AND は OR よりも結合が強いので
hello AND world OR greeting
は
(hello AND world) OR greeting
この仕様を NIP-11 で自分で定義させる。
"nip50_search": {
"boolean_operators": true,
"parentheses": true,
"phrase_search": true
}
こんな感じ。
挙動不審者絵文字やん :eyes:
NIP-50 の検索はクエリの仕様が決められてないのがキツいな。
「おっぱい いっぱい」で検索した際に「"おっぱい" OR "いっぱい"」なのか、「"おっぱい" AND "いっぱい"」なのか「"おっぱい いっぱい"」なのか決められてない。
EOSE まではデータベースの検索に依存するし、EOSE より後はメモリ操作になるだろうから、せめて統一して欲しい。(お前が提案しろ)
漏らしたら漏らした時
GitHub に blossom-server という名前のリポジトリが2つあり、どちらにも pull-req してるので fork リポジトリに 2 とか付けた。
ゲームしないので GPU とか、光沢液晶にはまったく興味が無い。
開発関連の執筆業をしてるけど、ある程度マシな PC 使ってないと読者と差が出るので、これは必要経費。
メモリ32GB、AMD Ryzen 7 7735HS、1TB ストレージなら数年は戦えるでしょ。
しんくぱっよです
新しいノート PC買っていい?
大掃除せなあかんので、お昼の準備した。カネテツの野菜天いりの木の葉丼。
那月さんに手加減しない Nostr 雀士たち
atasinti さんも X 歴長いなぁ。
REQ の filter で kind 3 みたいに ["p", "..."] みたいな tags がある event の id を指定できたらクライアントからフォローID全部送らんでいいし、サーバも JSON パースしなくていいんや。
おぱ吸ってるの?