nip-01: allow prefix search of id, author in request filter. (#65)

Co-authored-by: fiatjaf <fiatjaf@gmail.com>

nips/01.md

@@ -61,13 +61,13 @@ Clients can send 3 types of messages, which must be JSON arrays, according to th
 
 ```
 {
-  "ids": <a list of event ids>,
-  "kinds": <a list of kind numbers>,
+  "ids": <a list of event ids or prefixes>,
+  "kinds": <a list of a kind numbers>,
   "#e": <a list of event ids that are referenced in an "e" tag>,
   "#p": <a list of pubkeys that are referenced in a "p" tag>,
   "since": <a timestamp, events must be newer than this to pass>,
   "until": <a timestamp, events must be older than this to pass>,
-  "authors": <a list of pubkeys, the pubkey of an event must be one of these>
+  "authors": <a list of pubkeys or prefixes, the pubkey of an event must be one of these>
 }
 ```
 
@@ -75,6 +75,8 @@ Upon receiving a `REQ` message, the relay MUST query its internal database and r
 
 Filter attributes containing lists (such as `ids`, `kinds`, or `#e`) are JSON arrays with one or more values.  At least one of the array's values must match the relevant field in an event for the condition itself to be considered a match.  For scalar event attributes such as `kind`, the attribute from the event must be contained in the filter list.  For tag attributes such as `#e`, where an event may have multiple values, the event and filter condition values must have at least one item in common.
 
+The `ids` and `authors` lists contain lowercase hexadecimal strings, which may either be an exact 64-character match, or a prefix of the event value.  A prefix match is when the filter string is an exact string prefix of the event value.  The use of prefixes allows for more compact filters where a large number of values are queried, and can provide some privacy for clients that may not want to disclose the exact authors or events they are searching for.
+
 All conditions of a filter that are specified must match for an event for it to pass the filter, i.e., multiple conditions are interpreted as `&&` conditions.
 
 A `REQ` message may contain multiple filters. In this case events that match any of the filters are to be returned, i.e., multiple filters are to be interpreted as `||` conditions.