From c4cc963abc98eac7e89beeff6e01a4dc776f3e77 Mon Sep 17 00:00:00 2001 From: Vitor Pamplona Date: Wed, 3 Jan 2024 11:51:02 -0500 Subject: [PATCH] header formats --- 01.md | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/01.md b/01.md index 9ed3ca9..335c9e8 100644 --- a/01.md +++ b/01.md @@ -8,7 +8,7 @@ Nostr Protocol This NIP defines the complete protocol that MUST be implemented by everybody. New NIPs may add new optional (or mandatory) fields, messages and features to the structures and flows described here. -## Events +# Events Event is only object type available. It is a hashed and signed payload with the following format: @@ -57,7 +57,7 @@ To verify an event: 1. Recalculate the hash and check against the `.id` 2. Verify if the signature is valid for the `.id`. -### Kinds +## Kinds The `.kind` property specifies the meaning of an event and its tags. @@ -77,7 +77,7 @@ This NIP defines two kinds: - `kind:0`: **User Metadata**: the `content` is set to a stringified JSON object `{name: , about: , picture: }` describing the user who created the event. A relay may delete older events once it gets a new one for the same pubkey. - `kind:1`: **Text Note**: the `content` is set to the **plaintext** content of a note (anything the user wants to say). Content that must be parsed, such as Markdown and HTML, should not be used. Clients should also not parse content as those. -### Tags +## Tags Each tag is an array of strings of arbitrary size. Their meaning is determined by the event `.kind` and defined in NIPs in this repository. Tags with the same name might have entirely different meanings in diferent kinds. @@ -107,17 +107,17 @@ This NIP defines the format of 3 standard tags that can be used across all event All single-letter (only english alphabet letters: a-z, A-Z) key tags indexed by relays for faster queries. -## Relay Protocol +# Relay Protocol Nostr has two main components: Clients & Relays. Users run a client to fetch/subscribe to events from one or more Relays via websockets. Relays are not expected to communicate with one another. It's the Client's responsibility to discover which relay has the event set their user wants to see. Both sides SHOULD verify the hash and the signature of each event upon receipt. Clients SHOULD open a single websocket connection to each relay and use it for all their subscriptions. Relays MAY limit number of connections from specific IP/client/etc. All messages are defined as JSON arrays. -### Subscriptions +## Subscriptions Clients send a **subscription** message with one or more filters. The Relay MUST query its database, return all events that match the filter and keep applying the filter to all connections, returning new events as they arrive. Subscriptions stay indefinatelly open until either side closes the subscription or the connection. -#### Subscription Requests +### Subscription Requests To open, update and close subscriptions, Clients MUST use the following formats: * `["REQ", , , , ...]`, used to request events and subscribe to new updates. @@ -151,7 +151,7 @@ The `since` and `until` properties are used to specify the time range of events The `limit` property operates over the stored events and is ignored afterwards. -#### Receiving Events +### Receiving Events Relays send 3 types of messages during a subscription: @@ -163,7 +163,7 @@ All messages MUST be sent with the subscription_id initiated by the client (usin `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. -### Broadcasting an Event +## Broadcasting an Event To send an event to the Relay, Clients send a broadcast message in the format: @@ -177,13 +177,13 @@ Relays reply with an ACK message in the format of: If present, the message MUST be a string formed by a machine-readable single-word prefix followed by a `:` and then a human-readable message. -### Notices +## Notices Notices are warnings that might help explain or debug the behaviour of a given relay. * `["NOTICE", ]`, used to send human-readable error messages or other things to clients. -### Error Codes +## Error Codes The standardized machine-readable prefixes for `OK` and `CLOSED` are: `duplicate`, `pow`, `blocked`, `rate-limited`, `invalid`, and `error` for when none of that fits.