diff options
| author | Artur Brugeman <brugeman.artur@gmail.com> | 2023-01-17 18:49:10 +0300 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2023-01-17 18:49:10 +0300 |
| commit | 086d224e1d75366ec45d23544159ed9c5610010a (patch) | |
| tree | 00f02f01a7744208d8925b69a3dca53cfade923d | |
| parent | 1840c5cbdf37635fcada6434e91e9a47b0251d91 (diff) | |
NIP-50: Keywords Filter
| -rw-r--r-- | 50.md | 52 |
1 files changed, 52 insertions, 0 deletions
| @@ -0,0 +1,52 @@ | |||
| 1 | NIP-50 | ||
| 2 | ====== | ||
| 3 | |||
| 4 | Keywords Filter | ||
| 5 | --------------- | ||
| 6 | |||
| 7 | `draft` `optional` `author:brugeman` | ||
| 8 | |||
| 9 | ## Abstract | ||
| 10 | |||
| 11 | Many Nostr use cases require some form of search by `content` field. The meaning and format of `content` differs | ||
| 12 | with event kind and use case. Thus, this NIP only establishes a general framework for search over `content`, | ||
| 13 | and specifies the details for kind `0` and kind `1` events. | ||
| 14 | |||
| 15 | ## `keywords` filter field | ||
| 16 | |||
| 17 | A new `keywords` field is introduced for `REQ` messages from clients: | ||
| 18 | ```json | ||
| 19 | { | ||
| 20 | "kinds": <an array of kind numbers> | ||
| 21 | "keywords": <an array of strings> | ||
| 22 | } | ||
| 23 | ``` | ||
| 24 | A filter with `keywords` field MUST also include `kinds` field. This NIP specifies the behavior for kinds `0` and `1`, | ||
| 25 | if none of these kinds are provided along with `keywords`, relay SHOULD ignore the filter, and MAY send | ||
| 26 | a `NOTICE` to inform the client. Future NIPs will specify behavior for other event kinds. | ||
| 27 | |||
| 28 | A filter matches if one of the provided `keywords` matches. Each keyword string may contain several conditions - `words`, | ||
| 29 | all the words must match for a keyword to match. The meaning of `words` depends on event kind. | ||
| 30 | |||
| 31 | Clients SHOULD query several relays supporting this NIP and specific kind to compensate for potentially different | ||
| 32 | implementation details between relays (like string sanitization, etc). | ||
| 33 | |||
| 34 | Clients SHOULD verify that events returned by a relay match the specified `keywords` in the way that suits the | ||
| 35 | client's use case, and MAY stop querying relays that have low precision. | ||
| 36 | |||
| 37 | ## Keyword search for kind `0` and kind `1` | ||
| 38 | |||
| 39 | For kind `0` and kind `1`, each keyword is a lowercase string consisting of words separated by spaces (in most languages), punctuation/control | ||
| 40 | characters are ignored. | ||
| 41 | |||
| 42 | For kind `1`, an event must include all words in it's `content` field for it to match the keyword. | ||
| 43 | |||
| 44 | For kind `0`, an event must include all mentioned words in the json object stored at the `content` field. Recommended | ||
| 45 | json fields for matching are `about`, `display_name`, `name`, `nip05`, `lud06` and `lud18`. | ||
| 46 | |||
| 47 | A keyword may contain a word starting with prefix `option:` (like `option:no_spam`), such words specify additional | ||
| 48 | constraints for event matching, and are reserved for the future extensions. Relay SHOULD ignore `option:` words that it does not support. | ||
| 49 | |||
| 50 | Relay MAY support these options for kind `0` and kind `1` events: | ||
| 51 | - `option:no_spam` - only include events deemed 'high-quality' by whatever internal metric the relay adopts | ||
| 52 | |||