From 4d3421112d20e989a000d4392ca0077839102443 Mon Sep 17 00:00:00 2001
From: fiatjaf <fiatjaf@gmail.com>
Date: Fri, 13 Dec 2024 00:04:37 -0300
Subject: [PATCH] nip01: remove useless filter batching.

---
 01.md | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/01.md b/01.md
index d62f317..fbf156e 100644
--- a/01.md
+++ b/01.md
@@ -112,7 +112,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.
@@ -141,8 +141,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