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

Typos

Browse Source
This commit is contained in:
Vitor Pamplona 2024-01-04 10:15:49 -05:00
parent 3a06859967
commit b36336b937
1 changed files with 16 additions and 16 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

32
01.md
View File

@ -28,7 +28,7 @@ Event is the only object type available. It is a hashed and signed payload in th
}
```
Each user has a keypair and is identified by their public key.
Each user has a keypair and is identified by their public key (`.pubkey`).
## Signing
@ -62,8 +62,8 @@ Then proceed to sign the `.id` with the user's private key.
## Verifying
To verify an event:
1. Recalculate the hash and check against the `.id`
To verify the authenticity of an event:
1. Recalculate the `.id` and check against the incoming `.id`
2. Verify if the signature is valid for the `.id` and `.pubkey`.
## Kinds
@ -79,11 +79,11 @@ Specific ranges define storage behaviors:
| Ephemeral | `20000 <= kind < 30000` | Nothing |
| 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 that reference the newest repleceable MUST use this format: `<kind>:<32-byte lowercase hex of a pubkey>:<d-tag value>`.
Parameterized Replaceable events MUST include a `d`-tag with an identifier value to be used as a reference. Tag values that reference the newest replaceable 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.
This NIP defines the `kind:0` as **User Metadata**. The `.content` is set to a stringified JSON object `{name: <user's name, string>, about: <string>, picture: <url, string>}`. Since other attributes might exist, Clients SHOULD preseve any unsupported attribute when updating this event.
This NIP defines the `kind:0` as **User Metadata**. The `.content` is set to a stringified JSON object `{name: <user's name, string>, about: <string>, picture: <url, string>}`. Since other attributes might exist, Clients SHOULD preserve any unsupported attribute when updating this event.
## Tags
@ -91,9 +91,9 @@ Each tag is an array of strings of arbitrary size. Their meaning is determined b
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) tag names are indexed by relays for faster queries.
This NIP defines the format of 3 standard tags: `e`, `p`, and `a`. `e`, `p` can be used to reference events and pubkeys respectivelly, and `a` references the latest version of a replaceable event. Clients MAY `a`- and `e`-tag parameterized replaceables simultaneously.
This NIP defines the format of 3 standard tags: `e`, `p`, and `a`. Tags `e`, `p` can be used to reference events and pubkeys respectively, and tag `a` references the latest version of a replaceable event. Clients MAY `a`- and `e`-tag parameterized replaceables simultaneously.
| Name | Value | Other Params |
| ---- | ---------------------------------------------------------- | ----------------------- |
@ -102,15 +102,15 @@ This NIP defines the format of 3 standard tags: `e`, `p`, and `a`. `e`, `p` can
| `a` | `<kind>:<32-byte lowercase hex of a pubkey>:` | `<relay URL, optional>` |
| `a` | `<kind>:<32-byte lowercase hex of a pubkey>:<d-tag value>` | `<relay URL, optional>` |
The `d`-tag is equivalent to empty string (`""`) when referencing non-parameterized but replaceable events.
The `<d-tag value>` component of the `a` tag is an empty string (`""`) when referencing non-parameterized but replaceable events.
# 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.
Nostr has two main components: Clients & Relays. Users run a client to publish and fetch 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 relays have the event set their user wants to see.
Both sides SHOULD verify the hash and the signature of each event upon receipt.
Both sides SHOULD verify the `.id` 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.
@ -118,7 +118,7 @@ All messages are defined as JSON arrays, where the first item determines the mes
## 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.
Clients fetch events using a **subscription** message with one or more filters. Upon receipt, the Relay MUST query its database, return all events that match the filter and keep applying the filter to all connections, returning new events in real-time as they arrive.
Subscriptions stay indefinitely open until either side closes the subscription or the connection.
@ -128,7 +128,7 @@ To open and update, and close subscriptions, Clients MUST use the following form
* `["REQ", <subscription_id>, <filter1>, <filter2>, ...]`,
* `["CLOSE", <subscription_id>]`
`REQ` requests events and subscribe to new updates. A `REQ` message on an existing subscription overrides the previous subscription.
`REQ` requests events and subscribes to new updates. A `REQ` message on an existing subscription overrides the previous subscription.
`CLOSE` stops the respective subscription.
@ -141,8 +141,8 @@ To open and update, and close subscriptions, Clients MUST use the following form
"ids": [<id1>, <id2>, ...],
"authors": [<pubkey1>, <pubkey2>, ...],
"kinds": [<kind1>, <kind2>, ...],
"#<tag-key1 (single-letter a-zA-Z)>": [<tag value1>, <tag value2>, ...],
"#<tag-key2 (single-letter a-zA-Z)>": [<tag value1>, <tag value2>, ...],
"#<tag-name1 (single-letter a-zA-Z)>": [<tag value1>, <tag value2>, ...],
"#<tag-name2 (single-letter a-zA-Z)>": [<tag value1>, <tag value2>, ...],
"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>,
"limit": <maximum number of events to return, sorted by created_at desc>
@ -159,7 +159,7 @@ The `ids`, `authors`, `#e`, and `#p` filter lists MUST contain exact 64-characte
The `since` and `until` properties are used to specify the time range of events returned in the subscription. An event matches the filter if `since <= created_at <= until` holds.
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.
### Subscription Responses