1 files changed, 28 insertions, 33 deletions

diff --git a/50.md b/50.md
index 0692fd1..230b8e0 100644
--- a/50.md
+++ b/50.md
@@ -1,54 +1,49 @@
 NIP-50
 ======
 
-Keywords Filter
----------------
+Keyword Search
+--------------
 
-`draft` `optional` `author:brugeman` `author:mikedilger`
+`draft` `optional` `author:brugeman` `author:mikedilger` `author:fiatjaf`
 
 ## Abstract
 
-Many Nostr use cases require some form of search by `content` field. The meaning and format of `content` differs 
-with event kind and use case. Thus, this NIP only establishes a general framework for search over `content`,
-and specifies the details for kind `0` and kind `1` events.
+Many Nostr use cases require some form of general search feature, in addition to structured queries by tags or ids. 
+Specifics of the search algorithms will differ between event kinds, this NIP only describes a general 
+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
 {
-  "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`, 
-if none of these kinds are provided along with `keywords`, relay SHOULD ignore the filter, and MAY send
-a `NOTICE` to inform the client. Future NIPs will specify behavior for other event kinds.
+`search` field is a string 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. 
 
-A filter matches if one of the provided `keywords` matches. Each keyword string may contain several conditions - `words`, 
-all the words must match for a keyword to match. The meaning of `words` depends on event kind.
+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 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 
-implementation details between relays (like string sanitization, etc).
+Clients SHOULD use the supported_nips field to learn if a relay supports `search` filter. Clients MAY send `search` 
+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
-client's use case, and MAY stop querying relays that have low precision.
-
-## Keyword search for kind `0` and kind `1` 
-
-For kind `0` and kind `1`, each keyword is a lowercase string consisting of words separated by spaces (in most languages), punctuation/control 
-characters are ignored. 
+Clients SHOULD query several relays supporting this NIP to compensate for potentially different 
+implementation details between relays.
 
-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`.
+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.
 
-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.
+Relays SHOULD exclude spam from search results by default if they supports some form of spam filtering.
 
-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
+## Extensions
 
+Relay MAY support these extensions:
+- `include:spam` - turn off spam filtering, if it was enabled by default