nostr/nips
1
0
Fork 0
mirror of https://github.com/nostr-protocol/nips.git synced 2024-12-25 17:55:51 -05:00
Code Issues Actions Packages Projects Releases Wiki Activity

Additional adjustments and further breaking down the text into paragraphs.

Browse Source
This commit is contained in:
Vitor Pamplona 2024-01-04 08:31:01 -05:00
parent 309298ac0d
commit 479561cb79
1 changed files with 20 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

32
01.md
View File

@ -79,7 +79,7 @@ Specific ranges define storage behaviors:
| Ephemeral | `20000 <= kind < 30000` | Nothing | | Ephemeral | `20000 <= kind < 30000` | Nothing |
| Parameterized | `30000 <= kind < 40000` | The newest event for each `pubkey`, `kind` and `d`-tag | | Parameterized | `30000 <= kind < 40000` | The newest event for each `pubkey`, `kind` and `d`-tag |
Parameterized Repleaceable events MUST include a `d`-tag with an identifier value to be used as reference. Tag values want to reference the newest repleceable MUST use this format: `<kind>:<32-byte lowercase hex of a pubkey>:<d-tag value>`. Parameterized Repleaceable events MUST include a `d`-tag with an identifier value to be used as reference. Tag values that reference the newest repleceable MUST use this format: `<kind>:<32-byte lowercase hex of a pubkey>:<d-tag value>`.
In case of replaceable events with the same timestamp, the event with the lowest `.id` (first in lexical order) SHOULD be retained. Older versions MAY be kept but SHOULD not be returned on queries. In case of replaceable events with the same timestamp, the event with the lowest `.id` (first in lexical order) SHOULD be retained. Older versions MAY be kept but SHOULD not be returned on queries.
@ -122,11 +122,15 @@ Subscriptions stay indefinitely open until either side closes the subscription o
### Subscription Requests ### Subscription Requests
To open, update, and close subscriptions, Clients MUST use the following formats: To open and update, and close subscriptions, Clients MUST use the following formats:
* `["REQ", <subscription_id>, <filter1>, <filter2>, ...]`, used to request events and subscribe to new updates. * `["REQ", <subscription_id>, <filter1>, <filter2>, ...]`,
* `["CLOSE", <subscription_id>]`, used to stop previous subscriptions. * `["CLOSE", <subscription_id>]`
`<subscription_id>` is a non-empty string with a maximum length of 64 chars. Relays MUST manage `<subscription_id>`s independently for each WebSocket connection. `<subscription_id>`s are not globally unique. A `REQ` message on an existing subscription overrides the previous subscription. `REQ` requests events and subscribe to new updates. A `REQ` message on an existing subscription overrides the previous subscription.
`CLOSE` stops the respective subscription.
`<subscription_id>` is a non-empty string with a maximum length of 64 chars. Relays MUST manage `<subscription_id>`s independently for each WebSocket connection. `<subscription_id>`s are not globally unique.
`<filterX>` is a JSON object that determines what events will be sent in that subscription, it can have the following attributes: `<filterX>` is a JSON object that determines what events will be sent in that subscription, it can have the following attributes:
@ -155,16 +159,20 @@ The `since` and `until` properties are used to specify the time range of events
The `limit` property informs the maximum number of events to return, sorted by created_at desc. It operates over the previously-stored events and is ignored afterward. The `limit` property informs the maximum number of events to return, sorted by created_at desc. It operates over the previously-stored events and is ignored afterward.
### Receiving Events ### Subscription Responses
Relays send 3 types of messages during a subscription: Relays send 3 types of messages during a subscription:
* `["EVENT", <subscription_id>, <JSON-serialized string of the event>]`, used to send events requested by clients. * `["EVENT", <subscription_id>, <JSON-serialized string of the event>]`
* `["EOSE", <subscription_id>]`, used to indicate the _end of stored events_ and the beginning of events newly received in real-time. * `["EOSE", <subscription_id>]`,
* `["CLOSED", <subscription_id>, <prefix>:<message>]`, used to indicate that a subscription was ended on the server side. * `["CLOSED", <subscription_id>, <prefix>:<message>]`
All messages MUST be sent with the `subscription_id` initiated by the client (using the `REQ` message above). All messages MUST be sent with the `subscription_id` initiated by the client (using the `REQ` message above).
The `EVENT` message is used to send events requested by clients.
`EOSE` indicates the _end of stored events_ and the beginning of events newly received in real-time.
`CLOSED` messages MUST be sent in response to a `REQ` when the relay refuses to fulfill it. It can also be sent when a relay decides to kill a subscription on its side before a client has disconnected or sent a `CLOSE`. The message MUST be a string formed by a machine-readable single-word prefix followed by a `:` and then a human-readable message. `CLOSED` messages MUST be sent in response to a `REQ` when the relay refuses to fulfill it. It can also be sent when a relay decides to kill a subscription on its side before a client has disconnected or sent a `CLOSE`. The message MUST be a string formed by a machine-readable single-word prefix followed by a `:` and then a human-readable message.
## Publishing ## Publishing
@ -175,7 +183,7 @@ To send an event to the Relay, Clients send a broadcast message in the format:
Relays reply with an ACK message in the format of: Relays reply with an ACK message in the format of:
* `["OK", <event_id>, <accepted>, <prefix>:<message>]`, used to indicate acceptance (true) or denial (false) of an `EVENT`. * `["OK", <event_id>, <accepted>, <prefix>:<message>]`
`OK` messages MUST be sent in response to `EVENT` messages received from clients, they must have the 3rd parameter set to `true` when an event has been accepted by the relay, `false` otherwise. The 4th parameter MUST always be present, but MAY be an empty string when the 3rd is `true`. `OK` messages MUST be sent in response to `EVENT` messages received from clients, they must have the 3rd parameter set to `true` when an event has been accepted by the relay, `false` otherwise. The 4th parameter MUST always be present, but MAY be an empty string when the 3rd is `true`.
@ -183,9 +191,9 @@ If present, the message MUST be a string formed by a machine-readable single-wor
## Notices ## Notices
Notices are warnings that might help explain or debug the behavior of a given relay or filter. Notices are human-readable warnings that might help explain or debug the behavior of a given relay or filter.
* `["NOTICE", <message>]`, used to send human-readable error messages or other things to clients. * `["NOTICE", <message>]`
## Message Prefixes ## Message Prefixes