NIP-50 search filter should work with multiple values to use them with AND condition in the same way kinds and authors are used

This commit is contained in:
Viktor Vsk 2023-09-09 13:19:01 +02:00 committed by GitHub
parent e3504024a2
commit ebd18d5cca
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

6
50.md
View File

@ -18,10 +18,10 @@ A new `search` field is introduced for `REQ` messages from clients:
```json
{
...
"search": <string>
"search": <a list of strings>
}
```
`search` field is a string describing a query in a human-readable form, i.e. "best nostr apps".
`search` field is a list of strings 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 perform matching against `content` event field, and MAY perform
matching against other fields if that makes sense in the context of a specific kind.
@ -29,7 +29,7 @@ matching against other fields if that makes sense in the context of a specific k
A query string may contain `key:value` pairs (two words separated by colon), these are extensions, relays SHOULD ignore
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", "", { "search": ["orange"] }, { "kinds": [1, 2], "search": ["green", "purple"] }]`. Clients may
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`