adjustments

This commit is contained in:
Vitor Pamplona 2024-01-03 13:35:24 -05:00
parent 2b6edc0f71
commit f2e016fadd

28
01.md
View File

@ -19,11 +19,12 @@ Event is the only object type available. It is a hashed and signed payload in th
"created_at": <unix timestamp in seconds>, "created_at": <unix timestamp in seconds>,
"kind": <integer between 0 and 65535>, "kind": <integer between 0 and 65535>,
"tags": [ "tags": [
[<arbitrary string>...], [<tag1-name>, <tag1-value>, ...],
[<tag2-name>, <tag2-value>, ...],
... ...
], ],
"content": <arbitrary string>, "content": <arbitrary string>,
"sig": <64-byte lowercase hex of the signature of the "id" field> "sig": <64-byte lowercase hex of the signature of the id>
} }
``` ```
@ -65,7 +66,7 @@ To verify an event:
## Kinds ## Kinds
The `.kind` property specifies the meaning of an event and its tags. The `.kind` property specifies the meaning of an event, its tags and it is further defined in the various NIPs in this repository
Specific ranges define storage behaviors: Specific ranges define storage behaviors:
@ -80,14 +81,14 @@ In case of replaceable events with the same timestamp, the event with the lowest
This NIP defines two kinds: This NIP defines two kinds:
- `kind:0`: **User Metadata**: the `content` is set to a stringified JSON object `{name: <username>, about: <string>, picture: <url, string>}` describing the user who created the event. A relay may delete older events once it gets a new one for the same pubkey. - `kind:0`: **User Metadata**: An event kind to add name and other information to the pubkey. The `content` is set to a stringified JSON object `{name: <user's name, string>, about: <string>, picture: <url, string>}`
- `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. - `kind:1`: **Text Note**: An event kind to transfer **plaintext** content in it's `.content` property. Markup language such as markdown and HTML SHOULD not be used.
## 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 different kinds. Each tag is an array of strings of arbitrary size. Their meaning is determined by the event `.kind`. Tags with the same name might have entirely different meanings in different kinds.
The first element of the tag array is referred to as the tag _name_ or _key_ and the second as the tag _value_. All elements after the second do not have a conventional name. The first element of the tag array is referred to as the tag _name_ and the second as the tag _value_. All elements after the second do not have a conventional name.
All single-letter (only English alphabet letters: a-z, A-Z) key tags are indexed by relays for faster queries. All single-letter (only English alphabet letters: a-z, A-Z) key tags are indexed by relays for faster queries.
@ -102,9 +103,7 @@ This NIP defines the format of 3 standard tags: `e`, `p`, and `a`. `e`, `p` can
# Relay Protocol # Relay Protocol
Nostr has two main components: Clients & Relays. Nostr has two main components: Clients & Relays. Users run a client to fetch/subscribe to events from one or more Relays via WebSockets.
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. 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.
@ -112,7 +111,7 @@ 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 the number of connections from specific IP/client/etc. Clients SHOULD open a single WebSocket connection to each relay and use it for all their subscriptions. Relays MAY limit the number of connections from specific IP/client/etc.
All messages are defined as JSON arrays. All messages are defined as JSON arrays, where the first item determines the message type.
## Subscriptions ## Subscriptions
@ -135,10 +134,11 @@ To open, update, and close subscriptions, Clients MUST use the following formats
"ids": [<id1>, <id2>, ...], "ids": [<id1>, <id2>, ...],
"authors": [<pubkey1>, <pubkey2>, ...], "authors": [<pubkey1>, <pubkey2>, ...],
"kinds": [<kind1>, <kind2>, ...], "kinds": [<kind1>, <kind2>, ...],
"#<single-letter-tag-key (a-zA-Z)>": [tag value1, tag value2, ...], "#<tag-key1 (single-letter a-zA-Z)>": [<tag value1>, <tag value2>, ...],
"#<tag-key2 (single-letter a-zA-Z)>": [<tag value1>, <tag value2>, ...],
"since": <an integer unix timestamp in seconds, events must be newer than this to pass>, "since": <an integer unix timestamp in seconds, events must be newer than this to pass>,
"until": <an integer unix timestamp in seconds, events must be older than this to pass>, "until": <an integer unix timestamp in seconds, events must be older than this to pass>,
"limit": <maximum number of events to return, ordered by created_at> "limit": <maximum number of events to return, sorted by created_at>
} }
``` ```
@ -182,7 +182,7 @@ 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. Notices are 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>]`, used to send human-readable error messages or other things to clients.