js のバインディングはブラウザバインディングなので websocket サーバは書けないと思う。

ボローチェッカーが無くて GC がある Rust、みたいな感じでした。以前触った時は。

あと I/O 書けないと思う。

書けないと思う。ライブラリが少なすぎる。

moonbit は GC 付きの Rust みたいなシンタックス。

年賀状のデザインきまたので印刷係やります。

風呂の排水を綺麗に掃除するキットを買ってきてやってるけど、ぜんぜん汚いのが出なくて奥さんが「つまらんな」「もっとゲロみたいなのが出てくると思ってた」と残念がってる。

ねるにゃー

タンヤオの出現率: 約22〜23%（天鳳鳳凰卓データで22.8%前後） ピンフの出現率: 約20%（天鳳データで20.2%、他の統計で19.9〜21.5%）

groonga が使えr supabase の料金表を見てるんだけど、$25/mont で1プロジェクトあたり 8GB なんだな。nostr-relay 既に 9GB やがな。

X や Google 風の検索クエリライブラリ書いた。 PostgreSQL の tsquery や SQLite3 の FTS5 クエリ、MySQL の boolean マッチのクエリを作る関数も含む。 これでもし NIP-50 がこの形式をサポートするなら、これを使おうと思う。

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 とか、光沢液晶にはまったく興味が無い。