Nostrの多くのユースケースでは、タグやIDによる構造化されたクエリに加えてより一般的な検索機能が必要になる。

そのような検索を行うための汎用的で拡張可能な枠組みを記述するNIP。

クライアントからの REQ メッセージのフィルタに新しく search というフィールドを導入する。

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)。

ここに書くことなのか?

拡張

リレーは次のような拡張クエリをサポートしてもよい(MAY)

include:spam : スパムフィルタリングを無効化して検索

-----

実装しているリレー

wss://filter.nostr.wine/REPLACE_WITH_YOUR_NPUB?broadcast=true (nostr.wine)