Skip to content

Latest commit

 

History

History
55 lines (41 loc) · 3.7 KB

50.md

File metadata and controls

55 lines (41 loc) · 3.7 KB
Raw

NIP-50

検索機能

draft optional

概要

多くのNostrのユースケースでは、タグやIDによる構造化されたクエリに加えて、何らかの形の一般的な検索機能が必要となる。 検索アルゴリズムの詳細はイベントのkindによって異なるはずなので、 このNIPでは、そのようなクエリを実現するための一般的で拡張可能なフレームワークのみを記述する。

search フィルタフィールド

クライアントが送信するREQメッセージに、新たにsearchフィールドが導入される:

{
  // other fields on filter object...
  "search": <string>
}

searchフィールドは、クエリを人間可読な形式で表現したものだ(例: "best nostr apps")。 リレーは、できる限り最善の方法によってクエリを解釈し、それにマッチするイベントを返すべきだ(SHOULD)。 リレーは、contentイベントフィールドに対してマッチングを実行すべきであり(SHOULD)、 その他のフィールドに対するマッチングも、特定のkindについて意味がある場合には実行してもよい(MAY)。

結果は通常の.created_atでなく、検索結果の品質 (実装によって定義される) の降順で返されるべきである (SHOULD)。 limitフィルターはマッチングスコアでソートした後に適用するべきである (SHOULD)。 クエリ文字列は、key:valueペア(コロンで区切られた2つの単語)を含むかもしれない。このようなものは拡張であり、リレーは サポートしていない拡張は無視すべきだ(SHOULD)。

クライアントは、複数の検索フィルタを指定できる。例えば、["REQ", "", { "search": "orange" }, { "kinds": [1, 2], "search": "purple" }]のようにだ。クライアントは、 kinds、idsなどの他のフィルタフィールドを含めることで、検索結果を特定のイベントに限定できる。

クライアントは、リレーがsearchフィルタをサポートしているかどうかを知るために、supported_nipsフィールドを使うべきだ(SHOULD)。 クライアントは、このNIPをサポートしていないリレーからの余分な応答をフィルタリングするつもりであれば、searchフィルタクエリをどんなリレーに送信してもよい(MAY)。

リレーごとに実装詳細には差異がありうるので、それを埋めるため、 クライアントは、このNIPをサポートしている複数のリレーをクエリするべきだ(SHOULD)。

クライアントは、リレーの返したイベントが、クライアントのユースケースにしたがって指定されたクエリにマッチするかどうかを検証してよい(MAY)。 また、精度が低いリレーに対してクエリするのを停止してもよい(MAY)。

リレーは、もし何らかのスパムフィルタをサポートしているのであれば、デフォルトでスパムを検索結果から除外すべきだ(SHOULD)。

拡張

リレーは以下のような拡張をサポートしてもよい (MAY):

  • include:spam - スパムフィルタをオフにする (デフォルトで有効な場合)
  • domain:<domain> - ドメインに一致する有効なnip05ドメインを持つユーザーのイベントのみを含める。
  • language:<two letter ISO 639-1 language code> - 特定の言語のイベントのみを含める。
  • sentiment:<negative/neutral/positive> - 特定の感情のイベントのみを含める。
  • nsfw:<true/false> - nsfwイベントを含めるか、除外するか (デフォルト：true)