upleb.uk

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

summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--50.md54
1 files changed, 54 insertions, 0 deletions
diff --git a/50.md b/50.md
new file mode 100644
index 0000000..0692fd1
--- /dev/null
+++ b/50.md
@@ -0,0 +1,54 @@
1NIP-50
2======
3
4Keywords Filter
5---------------
6
7`draft` `optional` `author:brugeman` `author:mikedilger`
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 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.
32
33Clients SHOULD query several relays supporting this NIP and specific kind to compensate for potentially different
34implementation details between relays (like string sanitization, etc).
35
36Clients SHOULD verify that events returned by a relay match the specified `keywords` in the way that suits the
37client's use case, and MAY stop querying relays that have low precision.
38
39## Keyword search for kind `0` and kind `1`
40
41For kind `0` and kind `1`, each keyword is a lowercase string consisting of words separated by spaces (in most languages), punctuation/control
42characters are ignored.
43
44For kind `1`, an event must include all words in it's `content` field for it to match the keyword.
45
46For kind `0`, an event must include all mentioned words in the json object stored at the `content` field. Recommended
47json fields for matching are `about`, `display_name`, `name`, `nip05`, `lud06` and `lud16`.
48
49A keyword may contain a word starting with prefix `option:` (like `option:no_spam`), such words specify additional
50constraints for event matching, and are reserved for the future extensions. Relay SHOULD ignore `option:` words that it does not support.
51
52Relay MAY support these options for kind `0` and kind `1` events:
53- `option:no_spam` - only include events deemed 'high-quality' by whatever internal metric the relay adopts
54