laantungir/nips
1
0
Fork 0
mirror of https://github.com/nostr-protocol/nips.git synced 2026-10-05 18:58:44 +00:00
Code Issues Packages Projects Releases Wiki Activity

NIP-67: "auth" hint (#2371)

Browse Source
This commit is contained in:
fiatjaf
2026-09-01 09:32:55 -03:00
committed by GitHub
parent 24b2ae9fdf
commit e65954922b
2 changed files with 12 additions and 16 deletions
Download Patch File Download Diff File Expand all files Collapse all files
42.md
+4
View File
@@ -84,6 +84,10 @@ relay: ["EVENT", "sub_1", {...}]
In this case, the `AUTH` message from the relay could be sent right as the client connects or it can be sent immediately before the `CLOSED` is sent. The only requirement is that _the client must have a stored challenge associated with that relay_ so it can act upon that in response to the `auth-required` `CLOSED` message. In this case, the `AUTH` message from the relay could be sent right as the client connects or it can be sent immediately before the `CLOSED` is sent. The only requirement is that _the client must have a stored challenge associated with that relay_ so it can act upon that in response to the `auth-required` `CLOSED` message.
### `auth` hint in `EOSE`
Relays MAY use the `"auth"` hint in an `EOSE` message (as defined in [NIP-67](67.md)) to notify the client that more results may be available if they authenticate. In this case, the relay MUST send the `AUTH` challenge before the `EOSE` message.
### `auth-required` in response to an `EVENT` message ### `auth-required` in response to an `EVENT` message
The same flow is valid for when a client wants to write an `EVENT` to the relay, except now the relay sends back an `OK` message instead of a `CLOSED` message: The same flow is valid for when a client wants to write an `EVENT` to the relay, except now the relay sends back an `OK` message instead of a `CLOSED` message:
67.md
+8 -16
View File
@@ -30,10 +30,11 @@ A relay that implements this NIP MAY append a third element to the `EOSE` messag
["EOSE", <subscription_id>, [<hint>, ...]] ["EOSE", <subscription_id>, [<hint>, ...]]
``` ```
Currently two hint values are defined: Currently three hint values are defined:
- `"finish"`: the relay has sent every stored event matching the subscription's filters. The client SHOULD NOT paginate this subscription further. - `"finish"`: the relay has sent every stored event matching the subscription's filters. The client SHOULD NOT paginate this subscription further.
- `"more"`: the relay holds more matching stored events than it has sent. The client SHOULD paginate to retrieve them. A relay MAY send this hint, but is not required to, since detecting whether more events exist is not cheap on every storage backend. - `"more"`: the relay holds more matching stored events than it has sent. The client SHOULD paginate to retrieve them. A relay MAY send this hint, but is not required to, since detecting whether more events exist is not cheap on every storage backend.
- `"auth"`: the relay may have more stored events matching the subscription's filters if the user performs `AUTH` ([NIP-42](42.md)). Relays MUST ensure an `AUTH` message (containing a challenge) is sent _before_ the `EOSE` containing an `"auth"` hint.
The array MAY carry multiple hints simultaneously, and MAY be empty. Clients MUST ignore unknown hint values without error. The array MAY carry multiple hints simultaneously, and MAY be empty. Clients MUST ignore unknown hint values without error.
@@ -55,15 +56,6 @@ Relays implementing this NIP SHOULD include `67` in the `supported_nips` field o
## Examples ## Examples
Relay has more matching events than its internal cap (legacy-shaped response, client paginates):
```
["REQ", "sub1", {"authors": ["abcd..."], "kinds": [1]}]
["EVENT", "sub1", {...}]
... (300 events total)
["EOSE", "sub1"]
```
Relay has sent every matching stored event: Relay has sent every matching stored event:
``` ```
@@ -72,7 +64,7 @@ Relay has sent every matching stored event:
["EOSE", "sub2", ["finish"]] ["EOSE", "sub2", ["finish"]]
``` ```
Relay has more matching events and says so explicitly: Relay has more matching events:
``` ```
["REQ", "sub2b", {"authors": ["abcd..."], "kinds": [1]}] ["REQ", "sub2b", {"authors": ["abcd..."], "kinds": [1]}]
@@ -81,11 +73,11 @@ Relay has more matching events and says so explicitly:
["EOSE", "sub2b", ["more"]] ["EOSE", "sub2b", ["more"]]
``` ```
Relay does not implement this NIP (legacy behavior — client falls back to heuristic): Relay has more matching events that require authentication:
``` ```
["REQ", "sub3", {"kinds": [1], "limit": 500}] ["REQ", "sub2b", {"authors": ["abcd..."], "kinds": [1]}]
["EVENT", "sub3", {...}] ["EVENT", "sub4", {...}]
... (N events) ["AUTH", "challenge..."]
["EOSE", "sub3"] ["EOSE", "sub4", ["auth", "finish"]]
``` ```