nostr/nips
1
0
Fork 0
mirror of https://github.com/nostr-protocol/nips.git synced 2024-09-19 22:35:50 -04:00
Code Issues Actions Packages Projects Releases Wiki Activity

Rewrite, keywords renamed to search

Browse Source
This commit is contained in:
Artur Brugeman 2023-01-27 15:43:06 +03:00 committed by fiatjaf
parent 95fa5a4a5f
commit 6708a73bbc
1 changed files with 28 additions and 33 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

61
50.md
View File

@ -1,54 +1,49 @@
NIP-50 NIP-50
====== ======
Keywords Filter Keyword Search
--------------- --------------
`draft` `optional` `author:brugeman` `author:mikedilger` `draft` `optional` `author:brugeman` `author:mikedilger` `author:fiatjaf`
## Abstract ## Abstract
Many Nostr use cases require some form of search by `content` field. The meaning and format of `content` differs Many Nostr use cases require some form of general search feature, in addition to structured queries by tags or ids.
with event kind and use case. Thus, this NIP only establishes a general framework for search over `content`, Specifics of the search algorithms will differ between event kinds, this NIP only describes a general
and specifies the details for kind `0` and kind `1` events. extensible framework for performing such queries.
## `keywords` filter field ## `search` filter field
A new `keywords` field is introduced for `REQ` messages from clients: A new `search` field is introduced for `REQ` messages from clients:
```json ```json
{ {
"kinds": <an array of kind numbers> ...
"keywords": <an array of strings> "search": <string>
} }
``` ```
A filter with `keywords` field MUST also include `kinds` field. This NIP specifies the behavior for kinds `0` and `1`, `search` field is a string describing a query in a human-readable form, i.e. "best nostr apps".
if none of these kinds are provided along with `keywords`, relay SHOULD ignore the filter, and MAY send Relays SHOULD interpret the query to the best of their ability and return events that match it.
a `NOTICE` to inform the client. Future NIPs will specify behavior for other event kinds. 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.
A filter matches if one of the provided `keywords` matches. Each keyword string may contain several conditions - `words`, A query string may contain `key:value` pairs (two words separated by colon), these are extensions, relays SHOULD ignore
all the words must match for a keyword to match. The meaning of `words` depends on event kind. extensions they don't support.
Clients SHOULD use the supported_nips field to learn if a relay supports keyword filter queries. Clients MAY send keyword filter queries to any relay, if they are prepared to filter out extraneous responses from relays that do not support this NIP. Clients may specify several search filters, i.e. `["REQ", "", [{"search":"orange"},{"search":"purple"}]`. Clients may
include `kinds`, `ids` and other filter field to restrict the search results to particular event kinds.
Clients SHOULD query several relays supporting this NIP and specific kind to compensate for potentially different Clients SHOULD use the supported_nips field to learn if a relay supports `search` filter. Clients MAY send `search`
implementation details between relays (like string sanitization, etc). filter queries to any relay, if they are prepared to filter out extraneous responses from relays that do not support this NIP.
Clients SHOULD verify that events returned by a relay match the specified `keywords` in the way that suits the Clients SHOULD query several relays supporting this NIP to compensate for potentially different
implementation details between relays.
Clients MAY verify that events returned by a relay match the specified query in a way that suits the
client's use case, and MAY stop querying relays that have low precision. client's use case, and MAY stop querying relays that have low precision.
## Keyword search for kind `0` and kind `1` Relays SHOULD exclude spam from search results by default if they supports some form of spam filtering.
For kind `0` and kind `1`, each keyword is a lowercase string consisting of words separated by spaces (in most languages), punctuation/control ## Extensions
characters are ignored.
For kind `1`, an event must include all words in it's `content` field for it to match the keyword.
For kind `0`, an event must include all mentioned words in the json object stored at the `content` field. Recommended
json fields for matching are `about`, `display_name`, `name`, `nip05`, `lud06` and `lud16`.
A keyword may contain a word starting with prefix `option:` (like `option:no_spam`), such words specify additional
constraints for event matching, and are reserved for the future extensions. Relay SHOULD ignore `option:` words that it does not support.
Relay MAY support these options for kind `0` and kind `1` events:
- `option:no_spam` - only include events deemed 'high-quality' by whatever internal metric the relay adopts
Relay MAY support these extensions:
- `include:spam` - turn off spam filtering, if it was enabled by default