nostr/nips
1
0
Fork 0
mirror of https://github.com/nostr-protocol/nips.git synced 2024-12-26 10:15:52 -05:00
Code Issues Actions Packages Projects Releases Wiki Activity

Improve formatting

Browse Source
This commit is contained in:
Vitor Pamplona 2024-01-03 11:31:14 -05:00
parent 0c37bd1738
commit 8f739d0b16
1 changed files with 27 additions and 25 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

52
01.md
View File

@ -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. 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.
## User and Events ## Events
Each user has a keypair and is identified by their public key. Each user has a keypair and is identified by their public key.
@ -29,8 +29,6 @@ Event is only object type available. It is a hashed and signed payload with the
} }
``` ```
### Signature
Signatures and encodings are done according to the [Schnorr signatures standard for the curve `secp256k1`](https://bips.xyz/340). Signatures and encodings are done according to the [Schnorr signatures standard for the curve `secp256k1`](https://bips.xyz/340).
To obtain the hash `.id`, we `sha256` the UTF-8 bytearray of a JSON-serialized string with the following structure: To obtain the hash `.id`, we `sha256` the UTF-8 bytearray of a JSON-serialized string with the following structure:
@ -57,9 +55,33 @@ The JSON serialization MUST follow this rules:
- backspace, `0x08`, as `\b` - backspace, `0x08`, as `\b`
- form feed, `0x0C`, as `\f` - form feed, `0x0C`, as `\f`
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 specify the meaning of an event and its tags.
Kind ranges define storage behaviours. The current ranges are:
| Name | Range | SHOULD retain |
| ------------- | --------------------------------- | ------------------------------------------------------ |
| Regular | ` 1000 <= kind < 10000` | All events |
| Replaceable | `10000 <= kind < 20000` OR `0, 3` | The newest event for each `pubkey` and `kind` |
| Ephemeral | `20000 <= kind < 30000` | Nothing |
| Parameterized | `30000 <= kind < 40000` | The newest event for each `pubkey`, `kind` and `d`-tag |
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 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: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. 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.
```json ```json
{ {
@ -68,7 +90,7 @@ Each tag is an array of strings of arbitrary size. Their meaning is determined b
["e", "5c83da77af1dec6d7289834998ad7aafbd9e2191396d75ec3cc27f5a77226f36", "wss://nostr.example.com"], ["e", "5c83da77af1dec6d7289834998ad7aafbd9e2191396d75ec3cc27f5a77226f36", "wss://nostr.example.com"],
["p", "f7234bd4c1394dda46d09f35bd384dd30cc552ad5541990f98844fb06676e9ca"], ["p", "f7234bd4c1394dda46d09f35bd384dd30cc552ad5541990f98844fb06676e9ca"],
["a", "30023:f7234bd4c1394dda46d09f35bd384dd30cc552ad5541990f98844fb06676e9ca:abcd", "wss://nostr.example.com"], ["a", "30023:f7234bd4c1394dda46d09f35bd384dd30cc552ad5541990f98844fb06676e9ca:abcd", "wss://nostr.example.com"],
["alt", "reply"], ["alt", "a description of this event"],
... ...
], ],
... ...
@ -87,26 +109,6 @@ 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. All single-letter (only english alphabet letters: a-z, A-Z) key tags indexed by relays for faster queries.
### Kinds
Kinds specify the meaning of an event and its tags. Tags with the same name might have entirely different meanings in diferent kinds.
This NIP defines two kinds:
- `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.
- `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 ranges define storage behaviours. The current ranges are:
| Name | Range | SHOULD retain |
| ------------- | --------------------------------- | ------------------------------------------------------ |
| Regular | ` 1000 <= kind < 10000` | All events |
| Replaceable | `10000 <= kind < 20000` OR `0, 3` | The newest event for each `pubkey` and `kind` |
| Ephemeral | `20000 <= kind < 30000` | Nothing |
| Parameterized | `30000 <= kind < 40000` | The newest event for each `pubkey`, `kind` and `d`-tag |
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.
## 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. 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.