NIP-50
Search Capability
Nostrの多くのユースケースでは、タグやIDによる構造化されたクエリに加えてより一般的な検索機能が必要になる。
そのような検索を行うための汎用的で拡張可能な枠組みを記述するNIP。
クライアントからのREQメッセージのフィルタに新しくsearchというフィールドを導入する。
code:json
{
...
"search": <string>
}
searchフィールドの値は "best nostr apps" のような人間が読める形式の検索クエリとする。
リレーはこのクエリをいい感じに(to the best of their ability)解釈して、マッチするイベントを返すべき(SHOULD)。
少なくともcontentとのマッチングは行うべき(SHOULD)で、特定のkindについて意味をなすならば他のフィールドとのマッチングを行ってもよい(MAY)。
クエリ文字列にはkey:valueペアを含めてもよい。これは拡張機能であり、リレーはサポートしないならこれを無視すべき(SHOULD)。
クライアントは複数の検索フィルタを指定できる
例: ["REQ", "", { "search": "orange" }, { "kinds": [1, 2], "search": "purple" }]
kinds, idsなど他のフィールドを含めることで、検索対象を特定のkindのイベントのみに絞り込むことができる
クライアントは、リレーがsearchフィルタをサポートしているか調べるためにNIP-11のsupported_nipsを用いるべき(SHOULD)。サポートしていないリレーにsearchを含むフィルタを送ってもよい(MAY)が、不要なイベントが返ってくる点に留意すること。 クライアントはこのNIPをサポートする複数のリレーに問い合わせることで、リレー間の実装差異を埋め合わせるべき(SHOULD)。
クライアントは、リレーから返ってきたイベントが条件にマッチしてるかどうかを用途に合った方法で検証してもよく(MAY)、精度が低いリレーにクエリを投げるのをやめてもよい(MAY)。
リレーは、スパムのフィルタリングをサポートするならば、デフォルトで検索結果からスパムを除外すべき(SHOULD)。
ここに書くことなのか? jiftechnify.icon
拡張
リレーは次のような拡張クエリをサポートしてもよい(MAY)
include:spam: スパムフィルタリングを無効化して検索
-----
実装しているリレー
wss://relay.nostr.band
wss://search.nos.today
wss://nostrja-kari-nip50.heguro.com
wss://universe.nostrich.land
wss://filter.nostr.wine/REPLACE_WITH_YOUR_NPUB?broadcast=true (nostr.wine)