From f85d60f49e77875598433b698d16093bcd3b857f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ricardo=20Arturo=20Cabral=20Mej=C3=ADa?= Date: Sun, 23 Jun 2024 18:37:51 -0400 Subject: [PATCH] address comments and improve clarifications --- 122.md | 24 +++++++++++++++--------- 1 file changed, 15 insertions(+), 9 deletions(-) diff --git a/122.md b/122.md index 022b066..c6fe6b7 100644 --- a/122.md +++ b/122.md @@ -18,14 +18,17 @@ A mechanism to request other clients for missing events will help interested cli #### Specification -**Direct Request For Events** are ephemeral events with `kind:21122` used to ask for events from specific users. The `content` field is a NIP-44 encrypted list of `e` tags referring to the requested events. +**Direct Request For Events** are ephemeral events with `kind:21122` used to ask for events from specific users. The `content` field is a NIP-44 encrypted list of `e` and `a` tags referring to the requested events by ID or addresses, respectively. -**Public Request For Events** are ephemeral events with `kind:21122` used to ask for missing events from any user. One or more `e` tags refer to the requested events. The `content` field is unused and left as an empty string. +**Public Request For Events** are ephemeral events with `kind:21122` used to ask for missing events from any user. One or more `e` or `a` tags refer to the requested events by ID or address. The `content` field is unused and left as an empty string. ##### Example (Direct Request): ```js -const events = JSON.stringify([['e',''], ['e', '']]) +const events = JSON.stringify([ + ['e','', ''], + ['a', '', ''] +]); const encrypted_content = nip44_encrypt(events, ...); ``` @@ -42,8 +45,8 @@ const encrypted_content = nip44_encrypt(events, ...); { "kind": 21122, "tags": [ - ["e", ""], - ["e", ""] + ["e", "", ""], + ["a", "", ""] ], "content": "", "sig": "" @@ -58,13 +61,16 @@ const encrypted_content = nip44_encrypt(events, ...); ### Guidelines for Responding Clients -- Clients receiving a `kind:21122` event SHOULD send back the actual requested events to the relay from which it received the request. +- Clients SHOULD send back the actual requested events to the relay from which it received the request when relay URL hints are missing or when publishing to the relay hint is not possible. - Clients SHOULD NOT respond with any ephemeral events they may have in store. - Clients SHOULD NOT resend the original Request For Events or issue a new Request For Events for the same event IDs. -- Clients MAY respond to requests from users they follow/trust. -- Clients MAY respond to a fraction of requests (e.g. 10% sample rate) and/or adhere to data caps if they have limited resources (i.e. mobile clients). +- Clients MAY respond to requests from users they follow or that belong to their Web of Trust. +- Clients MAY respond to a fraction of requests (e.g. 5% sample rate) and/or adhere to data caps if they have limited resources (i.e. mobile clients). +- Clients MAY reject requests without sufficient Proof-of-Work. (e.g. [NIP-13](13.md)) ### Guidelines for Relays -- Relays MAY reject public request for events if at least one of the requested events is already in their store. +- Relays SHOULD forward public requests to a fraction of connected clients (e.g. 10% sample rate). - Relays SHOULD implement rate limits to prevent denial-of-service (DoS) attacks. +- Relays MAY reject public request for events if at least one of the requested events is already in their store. +- Relays MAY reject request for events that have insufficient Proof-of-Work. \ No newline at end of file