mirror of
https://github.com/nostr-protocol/nips.git
synced 2025-07-27 23:58:27 -04:00
remove it from nip50 example too.
This commit is contained in:
20
50.md
20
50.md
@@ -8,11 +8,11 @@ Search Capability
|
|||||||
|
|
||||||
## Abstract
|
## Abstract
|
||||||
|
|
||||||
Many Nostr use cases require some form of general search feature, in addition to structured queries by tags or ids.
|
Many Nostr use cases require some form of general search feature, in addition to structured queries by tags or ids.
|
||||||
Specifics of the search algorithms will differ between event kinds, this NIP only describes a general
|
Specifics of the search algorithms will differ between event kinds, this NIP only describes a general
|
||||||
extensible framework for performing such queries.
|
extensible framework for performing such queries.
|
||||||
|
|
||||||
## `search` filter field
|
## `search` filter field
|
||||||
|
|
||||||
A new `search` field is introduced for `REQ` messages from clients:
|
A new `search` field is introduced for `REQ` messages from clients:
|
||||||
```jsonc
|
```jsonc
|
||||||
@@ -21,23 +21,23 @@ A new `search` field is introduced for `REQ` messages from clients:
|
|||||||
"search": <string>
|
"search": <string>
|
||||||
}
|
}
|
||||||
```
|
```
|
||||||
`search` field is a string describing a query in a human-readable form, i.e. "best nostr apps".
|
`search` field is a string describing a query in a human-readable form, i.e. "best nostr apps".
|
||||||
Relays SHOULD interpret the query to the best of their ability and return events that match it.
|
Relays SHOULD interpret the query to the best of their ability and return events that match it.
|
||||||
Relays SHOULD perform matching against `content` event field, and MAY perform
|
Relays SHOULD perform matching against `content` event field, and MAY perform
|
||||||
matching against other fields if that makes sense in the context of a specific kind.
|
matching against other fields if that makes sense in the context of a specific kind.
|
||||||
|
|
||||||
Results SHOULD be returned in descending order by quality of search result (as defined by the implementation),
|
Results SHOULD be returned in descending order by quality of search result (as defined by the implementation),
|
||||||
not by the usual `.created_at`. The `limit` filter SHOULD be applied after sorting by matching score.
|
not by the usual `.created_at`. The `limit` filter SHOULD be applied after sorting by matching score.
|
||||||
A query string may contain `key:value` pairs (two words separated by colon), these are extensions, relays SHOULD ignore
|
A query string may contain `key:value` pairs (two words separated by colon), these are extensions, relays SHOULD ignore
|
||||||
extensions they don't support.
|
extensions they don't support.
|
||||||
|
|
||||||
Clients may specify several search filters, i.e. `["REQ", "", { "search": "orange" }, { "kinds": [1, 2], "search": "purple" }]`. Clients may
|
Clients may specify several search filters, i.e. `["REQ", "_", {"kinds": [1], "search": "purple"}]`. Clients may
|
||||||
include `kinds`, `ids` and other filter field to restrict the search results to particular event kinds.
|
include `kinds`, `ids` and other filter field to restrict the search results to particular event kinds.
|
||||||
|
|
||||||
Clients SHOULD use the supported_nips field to learn if a relay supports `search` filter. Clients MAY send `search`
|
Clients SHOULD use the supported_nips field to learn if a relay supports `search` filter. Clients MAY send `search`
|
||||||
filter queries to any relay, if they are prepared to filter out extraneous responses from relays that do not support this NIP.
|
filter queries to any relay, if they are prepared to filter out extraneous responses from relays that do not support this NIP.
|
||||||
|
|
||||||
Clients SHOULD query several relays supporting this NIP to compensate for potentially different
|
Clients SHOULD query several relays supporting this NIP to compensate for potentially different
|
||||||
implementation details between relays.
|
implementation details between relays.
|
||||||
|
|
||||||
Clients MAY verify that events returned by a relay match the specified query in a way that suits the
|
Clients MAY verify that events returned by a relay match the specified query in a way that suits the
|
||||||
|
Reference in New Issue
Block a user