upleb.uk

Public git repos — served from a NIP-34 GRASP relay at git.upleb.uk

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