remove it from nip50 example too.

01.md

@@ -113,7 +113,7 @@ Relays expose a websocket endpoint to which clients can connect. Clients SHOULD
 Clients can send 3 types of messages, which must be JSON arrays, according to the following patterns:
 
   * `["EVENT", <event JSON as defined above>]`, used to publish events.
-  * `["REQ", <subscription_id>, <filters1>, <filters2>, ...]`, used to request events and subscribe to new updates.
+  * `["REQ", <subscription_id>, <filter>]`, used to request events and subscribe to new updates.
   * `["CLOSE", <subscription_id>]`, used to stop previous subscriptions.
 
 `<subscription_id>` is an arbitrary, non-empty string of max length 64 chars. It represents a subscription per connection. Relays MUST manage `<subscription_id>`s independently for each WebSocket connection. `<subscription_id>`s are not guaranteed to be globally unique.
@@ -142,8 +142,6 @@ The `since` and `until` properties can be used to specify the time range of even
 
 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.
-
 The `limit` property of a filter is only valid for the initial query and MUST be ignored afterwards. When `limit: n` is present it is assumed that the events returned in the initial query will be the last `n` events ordered by the `created_at`. Newer events should appear first, and in the case of ties the event with the lowest id (first in lexical order) should be first. It is safe to return less events than `limit` specifies, but it is expected that relays do not return (much) more events than requested so clients don't get unnecessarily overwhelmed by data.
 
 ### From relay to client: sending events and notices

50.md

@@ -31,7 +31,7 @@ not by the usual `.created_at`. The `limit` filter SHOULD be applied after sorti
 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", "_", {"kinds": [1], "search": "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`