laantungir/nips
1
0
Fork 0
mirror of https://github.com/nostr-protocol/nips.git synced 2026-07-22 07:48:25 +00:00
Code Issues Packages Projects Releases Wiki Activity

``jsonc -> ``yaml everywhere.

Browse Source
This commit is contained in:
fiatjaf
2026-06-13 09:19:49 -03:00
parent a6f21e3af8
commit 999f9bfbf5
45 changed files with 160 additions and 160 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
01.md
View File

@@ -58,7 +58,7 @@ To prevent implementation differences from creating a different event ID for the
Each tag is an array of one or more strings, with some conventions around them. Take a look at the example below:
```jsonc
```yaml
{
"tags": [
["e", "5c83da77af1dec6d7289834998ad7aafbd9e2191396d75ec3cc27f5a77226f36", "wss://nostr.example.com"],

2
02.md
View File

@@ -14,7 +14,7 @@ The `.content` is not used.
For example:
```jsonc
```yaml
{
"kind": 3,
"tags": [

2
05.md
View File

@@ -16,7 +16,7 @@ The result should be a JSON document object with a key `"names"` that should the
If a client sees an event like this:
```jsonc
```yaml
{
"pubkey": "b0635d6a9851d3aed0cd6c495b282167acf761729078d975fc341b22650b07b9",
"kind": 0,

2
09.md
View File

@@ -12,7 +12,7 @@ The event's `content` field MAY contain a text note describing the reason for th
For example:
```jsonc
```yaml
{
"kind": 5,
"pubkey": <32-bytes hex-encoded public key of the event creator>,

6
11.md
View File

@@ -47,7 +47,7 @@ To make nostr relay management more user friendly, an effort should be made by r
Icon is a compact visual representation of the relay for use in UI with limited real estate such as a nostr user's relay list view. Below is an example URL pointing to an image to be used as an icon for the relay. Recommended to be squared in shape.
```jsonc
```yaml
{
"icon": "https://nostr.build/i/53866b44135a27d624e99c6165cabd76ac8f72797209700acb189fce75021f47.jpg",
// other fields...
@@ -93,7 +93,7 @@ These are limitations imposed by the relay on clients. Your client
should expect that requests exceed these *practical* limitations
are rejected or fail immediately.
```jsonc
```yaml
{
"limitation": {
"max_message_length": 16384,
@@ -164,7 +164,7 @@ a specific niche kind or content. Normal anti-spam heuristics, for example, do n
Relays that require payments may want to expose their fee schedules.
```jsonc
```yaml
{
"payments_url": "https://my-relay/payments",
"fees": {

8
15.md
View File

@@ -75,7 +75,7 @@ Fields that are not self-explanatory:
**Event Tags**
```jsonc
```yaml
{
"tags": [["d", <string, id of stall]],
// other fields...
@@ -126,7 +126,7 @@ Fields that are not self-explanatory:
**Event Tags**
```jsonc
```yaml
"tags": [
["d", <string, id of product],
["t", <string (optional), product category],
@@ -239,7 +239,7 @@ Create a customized user experience using the `naddr` from [NIP-19](19.md#sharea
**Event Content**
```jsonc
```yaml
{
"name": <string (optional), market name>,
"about": <string (optional), market description>,
@@ -292,7 +292,7 @@ This event leverages naddr to enable comprehensive customization and sharing of
### Event `1021`: Bid
```jsonc
```yaml
{
"content": <int, amount of sats>,
"tags": [["e", <event ID of the auction to bid on>]],

6
17.md
View File

@@ -62,7 +62,7 @@ Clients SHOULD randomize `created_at` in up to two days in the past in both the
Kind `10050` indicates the user's preferred relays to receive DMs. The event MUST include a list of `relay` tags with relay URIs.
```jsonc
```yaml
{
"kind": 10050,
"tags": [
@@ -115,7 +115,7 @@ Since the wrapper events use random keys, relays cannot apply traditional anti-s
Kind `14` is a chat message. `p` tags identify one or more receivers of the message.
```jsonc
```yaml
{
"pubkey": "<sender-pubkey>",
"created_at": "<current-time>",
@@ -143,7 +143,7 @@ An `e` tag denotes the direct parent message this post is replying to.
## File Message
```jsonc
```yaml
{
"pubkey": "<sender-pubkey>",
"created_at": "<current-time>",

14
22.md
View File

@@ -16,7 +16,7 @@ and MUST point to the parent item with lowercase ones (e.g. `k`, `e`, `a` or `i`
Comments MUST point to the authors when one is available (i.e. tagging a nostr event). `P` for the root scope
and `p` for the author of the parent item.
```jsonc
```yaml
{
"kind": 1111,
"content": "<comment>",
@@ -62,7 +62,7 @@ Comments MUST NOT be used to reply to kind 1 notes. [NIP-10](10.md) should inste
A comment on a blog post looks like this:
```jsonc
```yaml
{
"kind": 1111,
"content": "Great blog post!",
@@ -89,7 +89,7 @@ A comment on a blog post looks like this:
A comment on a [NIP-94](94.md) file looks like this:
```jsonc
```yaml
{
"kind": 1111,
"content": "Great file!",
@@ -113,7 +113,7 @@ A comment on a [NIP-94](94.md) file looks like this:
A reply to a comment looks like this:
```jsonc
```yaml
{
"kind": 1111,
"content": "This is a reply to \"Great file!\"",
@@ -136,7 +136,7 @@ A reply to a comment looks like this:
A comment on a website's url looks like this:
```jsonc
```yaml
{
"kind": 1111,
"content": "Nice article!",
@@ -157,7 +157,7 @@ A comment on a website's url looks like this:
A podcast comment example:
```jsonc
```yaml
{
"id": "80c48d992a38f9c445b943a9c9f1010b396676013443765750431a9004bdac05",
"pubkey": "252f10c83610ebca1a059c0bae8255eba2f95be4d1d7bcfa89d7248a82d9f111",
@@ -179,7 +179,7 @@ A podcast comment example:
A reply to a podcast comment:
```jsonc
```yaml
{
"kind": 1111,
"content": "I'm replying to the above comment.",

6
25.md
View File

@@ -51,7 +51,7 @@ External Content Reactions
If the target of a reaction is not a native nostr event, the reaction MUST be a `kind 17` event and MUST include [NIP-73](73.md) external content `k` + `i` tags to properly reference the content.
_Reacting to a website:_
```jsonc
```yaml
{
"kind": 17,
"content": "⭐",
@@ -63,7 +63,7 @@ _Reacting to a website:_
```
_Reacting to a podcast episode:_
```jsonc
```yaml
{
"kind": 17,
"content": "+",
@@ -86,7 +86,7 @@ The client may specify a custom emoji ([NIP-30](30.md)) `:shortcode:` in the
reaction content. The client should refer to the emoji tag and render the
content as an emoji if shortcode is specified.
```jsonc
```yaml
{
"kind": 7,
"content": ":soapbox:",

12
28.md
View File

@@ -26,7 +26,7 @@ Create a public chat channel.
In the channel creation `content` field, Client SHOULD include basic channel metadata (`name`, `about`, `picture` and `relays` as specified in kind 41).
```jsonc
```yaml
{
"content": "{\"name\": \"Demo Channel\", \"about\": \"A test channel.\", \"picture\": \"https://placekitten.com/200/200\", \"relays\": [\"wss://nos.lol\", \"wss://nostr.mom\"]}",
// other fields...
@@ -55,7 +55,7 @@ Clients SHOULD use [NIP-10](10.md) marked "e" tags to recommend a relay.
It is also possible to set the category name using the "t" tag. This category name can be searched and filtered.
```jsonc
```yaml
{
"content": "{\"name\": \"Updated Demo Channel\", \"about\": \"Updating a test channel.\", \"picture\": \"https://placekitten.com/201/201\", \"relays\": [\"wss://nos.lol\", \"wss://nostr.mom\"]}",
"tags": [
@@ -79,7 +79,7 @@ Clients SHOULD append [NIP-10](10.md) "p" tags to replies.
Root message:
```jsonc
```yaml
{
"content": <string>,
"tags": [["e", <kind_40_event_id>, <relay-url>, "root"]],
@@ -89,7 +89,7 @@ Root message:
Reply to another message:
```jsonc
```yaml
{
"content": <string>,
"tags": [
@@ -115,7 +115,7 @@ Clients MAY hide event 42s for other users other than the user who sent the even
(For example, if three users 'hide' an event giving a reason that includes the word 'pornography', a Nostr client that is an iOS app may choose to hide that message for all iOS clients.)
```jsonc
```yaml
{
"content": "{\"reason\": \"Dick pic\"}",
"tags": [["e", <kind_42_event_id>]],
@@ -133,7 +133,7 @@ Clients SHOULD hide event 42s shown to a given user, if there is an event 44 fro
Clients MAY hide event 42s for users other than the user who sent the event 44.
```jsonc
```yaml
{
"content": "{\"reason\": \"Posting dick pics\"}",
"tags": [["p", <pubkey>]],

12
29.md
View File

@@ -109,7 +109,7 @@ These are events expected to be sent by the relay master key or by group admins
Clients can send these events to a relay in order to accomplish a moderation action. Relays must check if the pubkey sending the event is capable of performing the given action based on its role and the relay's internal policy (see also the description of `kind:39003`).
```jsonc
```yaml
{
"kind": 90xx,
"content": "optional reason",
@@ -144,7 +144,7 @@ This event defines the metadata for the group -- basically how clients should di
If the group is forked and hosted in multiple relays, there will be multiple versions of this event in each different relay and so on.
```jsonc
```yaml
{
"kind": 39000,
"content": "",
@@ -173,7 +173,7 @@ If the group is forked and hosted in multiple relays, there will be multiple ver
Each admin is listed along with one or more roles. These roles SHOULD have a correspondence with the roles supported by the relay, as advertised by the `kind:39003` event.
```jsonc
```yaml
{
"kind": 39001,
"content": "list of admins for the pizza lovers group",
@@ -193,7 +193,7 @@ It's a list of pubkeys that are members of the group. Relays might choose to not
Clients should not assume this will always be present or that it will contain a full list of members.
```jsonc
```yaml
{
"kind": 39002,
"content": "list of members for the pizza lovers group",
@@ -216,7 +216,7 @@ For example, a relay may choose to support the roles `"admin"` and `"moderator"`
The process through which the relay decides what roles to support and how to handle moderation events internally based on them is specific to each relay and not specified here.
```jsonc
```yaml
{
"kind": 39003,
"content": "list of roles supported by this group",
@@ -238,7 +238,7 @@ This should be updated whenever a new user leaves or joins a group, clients are
The event MUST contain zero or more `participant` tags with the participant's public key as lowercase hex.
```jsonc
```yaml
{
"kind": 39004,
"content": "",

12
32.md
View File

@@ -57,7 +57,7 @@ Example events
A suggestion that multiple pubkeys be associated with the `permies` topic.
```jsonc
```yaml
{
"kind": 1985,
"tags": [
@@ -72,7 +72,7 @@ A suggestion that multiple pubkeys be associated with the `permies` topic.
A report flagging violence toward a human being as defined by ontology.example.com.
```jsonc
```yaml
{
"kind": 1985,
"tags": [
@@ -87,7 +87,7 @@ A report flagging violence toward a human being as defined by ontology.example.c
A moderation suggestion for a chat event.
```jsonc
```yaml
{
"kind": 1985,
"tags": [
@@ -101,7 +101,7 @@ A moderation suggestion for a chat event.
Assignment of a license to an event.
```jsonc
```yaml
{
"kind": 1985,
"tags": [
@@ -116,7 +116,7 @@ Assignment of a license to an event.
Publishers can self-label by adding `l` tags to their own non-1985 events. In this case, the kind 1 event's author
is labeling their note as being related to Milan, Italy using ISO 3166-2.
```jsonc
```yaml
{
"kind": 1,
"tags": [
@@ -130,7 +130,7 @@ is labeling their note as being related to Milan, Italy using ISO 3166-2.
Author is labeling their note language as English using ISO-639-1.
```jsonc
```yaml
{
"kind": 1,
"tags": [

14
34.md
View File

@@ -12,7 +12,7 @@ This NIP defines all the ways code collaboration using and adjacent to [`git`](h
Git repositories are hosted in Git-enabled servers, but their existence can be announced using Nostr events. By doing so the author asserts themselves as a maintainer and expresses a willingness to receive patches, bug reports and comments in general, unless `t` tag `personal-fork` is included.
```jsonc
```yaml
{
"kind": 30617,
"content": "",
@@ -62,7 +62,7 @@ nostr://danconwaydev.com/relay.ngit.dev/ngit
An optional source of truth for the state of branches and tags in a repository.
```jsonc
```yaml
{
"kind": 30618,
"content": "",
@@ -88,7 +88,7 @@ Patches in a patch set SHOULD include a [NIP-10](10.md) `e` `reply` tag pointing
The first patch revision in a patch revision SHOULD include a [NIP-10](10.md) `e` `reply` to the original root patch.
```jsonc
```yaml
{
"kind": 1617,
"content": "<patch>", // contents of <git format-patch>
@@ -125,7 +125,7 @@ An attempt SHOULD be made to push this ref to all repositories listed in the rep
Clients MAY fallback to creating a 'personal-fork' `repository announcement` listing other grasp servers, e.g. from the `User grasp list`, for the purpose of serving the specified commit(s).
```jsonc
```yaml
{
"kind": 1618,
"content": "<markdown text>",
@@ -153,7 +153,7 @@ Clients MAY fallback to creating a 'personal-fork' `repository announcement` lis
A PR Update changes the tip of a referenced PR event.
```jsonc
```yaml
{
"kind": 1619,
"content": "",
@@ -202,7 +202,7 @@ Replies to either a `kind:1621` (_issue_), `kind:1617` (_patch_) or `kind:1618`
Root Patches, PRs and Issues have a Status that defaults to 'Open' and can be set by issuing Status events.
```jsonc
```yaml
{
"kind": 1630, // Open
"kind": 1631, // Applied / Merged for Patches; Resolved for Issues
@@ -242,7 +242,7 @@ List of [grasp servers](https://njump.me/naddr1qvzqqqrhnypzpgqgmmc409hm4xsdd74sf
The event SHOULD include a list of `g` tags with grasp service websocket URLs in order of preference.
```jsonc
```yaml
{
"kind": 10317,
"content": "",

2
39.md
View File

@@ -10,7 +10,7 @@ Linking Profiles to Other Platforms
Users can declare their control over one or more online identities such as usernames, profile pages, keypairs in kind `10011` using `i` tags.
```jsonc
```yaml
{
"kind": 10011,
"tags": [

2
42.md
View File

@@ -40,7 +40,7 @@ Clients MAY provide signed events from multiple pubkeys in a sequence of `AUTH`
The signed event is an ephemeral event not meant to be published or queried, it must be of `kind: 22242` and it should have at least two tags, one for the relay URL and one for the challenge string as received from the relay. Relays MUST exclude `kind: 22242` events from being broadcasted to any client. `created_at` should be the current time. Example:
```jsonc
```yaml
{
"kind": 22242,
"tags": [

12
43.md
View File

@@ -21,7 +21,7 @@ This list should not be considered exhaustive or authoritative. To determine mem
Example:
```jsonc
```yaml
{
"kind": 13534,
"pubkey": "<nip11.self>",
@@ -45,7 +45,7 @@ The following tags are required:
Example:
```jsonc
```yaml
{
"kind": 8000,
"pubkey": "<nip11.self>",
@@ -68,7 +68,7 @@ The following tags are required:
Example:
```jsonc
```yaml
{
"kind": 8001,
"pubkey": "<nip11.self>",
@@ -84,7 +84,7 @@ Example:
A user MAY send a `kind 28934` to a relay in order to request admission. It MUST have a `claim` tag containing an invite code. The event's `created_at` MUST be now, plus or minus a few minutes.
```jsonc
```yaml
{
"kind": 28934,
"pubkey": "<user pubkey>",
@@ -113,7 +113,7 @@ Some examples:
Users may request a claim string from a relay by making a request for `kind 28935` events. This event MUST be signed by the pubkey specified in the `self` field of the relay's [NIP 11](./11.md) document.
```jsonc
```yaml
{
"kind": 28935,
"pubkey": "<nip11.self>",
@@ -131,7 +131,7 @@ Note that these events are in the `ephemeral` range, which means relays must exp
A user MAY send a `kind 28936` to a relay in order to request that their access be revoked. The event's `created_at` MUST be now, plus or minus a few minutes. This event MUST include a [NIP 70](./70.md) `-` tag.
```jsonc
```yaml
{
"kind": 28936,
"tags": [["-"]],

10
46.md
View File

@@ -68,7 +68,7 @@ _user_ passes this token to _remote-signer_, which then sends `connect` *respons
## Request Events `kind: 24133`
```jsonc
```yaml
{
"kind": 24133,
"pubkey": <local_keypair_pubkey>,
@@ -79,7 +79,7 @@ _user_ passes this token to _remote-signer_, which then sends `connect` *respons
The `content` field is a JSON-RPC-like message that is [NIP-44](44.md) encrypted and has the following structure:
```jsonc
```yaml
{
"id": <random_string>,
"method": <method_name>,
@@ -152,7 +152,7 @@ The `content` field is a JSON-RPC-like message that is [NIP-44](44.md) encrypted
### Signature request
```jsonc
```yaml
{
"kind": 24133,
"pubkey": "eff37350d839ce3707332348af4549a96051bd695d3223af4aabce4993531d86",
@@ -172,7 +172,7 @@ The `content` field is a JSON-RPC-like message that is [NIP-44](44.md) encrypted
### Response event
```jsonc
```yaml
{
"kind": 24133,
"pubkey": "fa984bd7dbb282f07e16e7ae87b26a2a7b9b90b7246a44771f0cf5ae58018f52",
@@ -212,7 +212,7 @@ _client_ should display (in a popup or new tab) the URL from the `error` field a
### Announcing _remote-signer_ metadata
_remote-signer_ MAY publish its metadata by using [NIP-05](05.md) and [NIP-89](89.md). With NIP-05, a request to `<remote-signer>/.well-known/nostr.json?name=_` MAY return this:
```jsonc
```yaml
{
"names":{
"_": <remote-signer-app-pubkey>,

56
47.md
View File

@@ -49,7 +49,7 @@ If the **wallet service** supports notifications, the info event SHOULD contain
It should also contain supported encryption modes as described in the [Encryption](#encryption) section. For example:
```jsonc
```yaml
{
"kind": 13194,
"tags": [
@@ -125,7 +125,7 @@ The notification event is a kind 23197 event SHOULD contain one `p` tag, the pub
The content of notifications is encrypted with [NIP44](44.md) (or NIP-04 for legacy client apps), and is a JSON-RPCish object with a semi-fixed structure:
```jsonc
```yaml
{
"notification_type": "payment_received", //indicates the structure of the notification field
"notification": {
@@ -180,7 +180,7 @@ nostr+walletconnect://b889ff5b1513b641e2a139f661a661364979c5beee91842f8f0ef42ab5
Description: Requests payment of an invoice.
Request:
```jsonc
```yaml
{
"method": "pay_invoice",
"params": {
@@ -192,7 +192,7 @@ Request:
```
Response:
```jsonc
```yaml
{
"result_type": "pay_invoice",
"result": {
@@ -208,7 +208,7 @@ Errors:
### `pay_keysend`
Request:
```jsonc
```yaml
{
"method": "pay_keysend",
"params": {
@@ -226,7 +226,7 @@ Request:
```
Response:
```jsonc
```yaml
{
"result_type": "pay_keysend",
"result": {
@@ -242,7 +242,7 @@ Errors:
### `make_invoice`
Request:
```jsonc
```yaml
{
"method": "make_invoice",
"params": {
@@ -256,7 +256,7 @@ Request:
```
Response:
```jsonc
```yaml
{
"result_type": "make_invoice",
"result": {
@@ -279,7 +279,7 @@ Response:
### `lookup_invoice`
Request:
```jsonc
```yaml
{
"method": "lookup_invoice",
"params": {
@@ -290,7 +290,7 @@ Request:
```
Response:
```jsonc
```yaml
{
"result_type": "lookup_invoice",
"result": {
@@ -322,7 +322,7 @@ If `until` is not specified, it defaults to the current time. Transactions are r
time.
Request:
```jsonc
```yaml
{
"method": "list_transactions",
"params": {
@@ -337,7 +337,7 @@ Request:
```
Response:
```jsonc
```yaml
{
"result_type": "list_transactions",
"result": {
@@ -365,7 +365,7 @@ Response:
### `get_balance`
Request:
```jsonc
```yaml
{
"method": "get_balance",
"params": {}
@@ -373,7 +373,7 @@ Request:
```
Response:
```jsonc
```yaml
{
"result_type": "get_balance",
"result": {
@@ -385,7 +385,7 @@ Response:
### `get_info`
Request:
```jsonc
```yaml
{
"method": "get_info",
"params": {}
@@ -393,7 +393,7 @@ Request:
```
Response:
```jsonc
```yaml
{
"result_type": "get_info",
"result": {
@@ -414,7 +414,7 @@ Response:
Creates a hold invoice using a pre-generated preimage.
Request:
```jsonc
```yaml
{
"method": "make_hold_invoice",
"params": {
@@ -429,7 +429,7 @@ Request:
```
Response:
```jsonc
```yaml
{
"result_type": "make_hold_invoice",
"result": {
@@ -451,7 +451,7 @@ Response:
Cancels a hold invoice using the payment hash
Request:
```jsonc
```yaml
{
"method": "cancel_hold_invoice",
"params": {
@@ -461,7 +461,7 @@ Request:
```
Response:
```jsonc
```yaml
{
"result_type": "cancel_hold_invoice",
"result": {}
@@ -474,7 +474,7 @@ Settles a hold invoice using the preimage
Request:
```jsonc
```yaml
{
"method": "settle_hold_invoice",
"params": {
@@ -484,7 +484,7 @@ Request:
```
Response:
```jsonc
```yaml
{
"result_type": "settle_hold_invoice",
"result": {}
@@ -499,7 +499,7 @@ Response:
Description: A payment was successfully received by the wallet.
Notification:
```jsonc
```yaml
{
"notification_type": "payment_received",
"notification": {
@@ -525,7 +525,7 @@ Notification:
Description: A payment was successfully sent by the wallet.
Notification:
```jsonc
```yaml
{
"notification_type": "payment_sent",
"notification": {
@@ -551,7 +551,7 @@ Notification:
Description: Sent when a payer accepts (locks in) a hold invoice. To avoid locking up funds in channels the hold invoice SHOULD be settled or canceled within a few minutes of receiving this event.
Notification:
```jsonc
```yaml
{
"notification_type": "hold_invoice_accepted",
"notification": {
@@ -606,7 +606,7 @@ If the `encryption` tag is present, the **client application** will choose optim
When a **client application** sends a request event, it should include a `encryption` tag with the encryption scheme it is using. The scheme MUST be supported by the **wallet service** as indicated by the info event.
For example, if the client application supports nip44, the request event might look like:
```jsonc
```yaml
{
"kind": 23194,
"tags": [
@@ -635,7 +635,7 @@ NWC relays SHOULD allow at least a payload size of 64KB and **clients** SHOULD f
Here are some properties that are recognized by some NWC clients:
```jsonc
```yaml
{
"comment": "string", // LUD-12 comment
"payer_data": {
@@ -664,7 +664,7 @@ Here are some properties that are recognized by some NWC clients:
### Example NIP-47 info event
```jsonc
```yaml
{
"id": "df467db0a9f9ec77ffe6f561811714ccaa2e26051c20f58f33c3d66d6c2b4d1c",
"pubkey": "c04ccd5c82fc1ea3499b9c6a5c0a7ab627fbe00a0116110d4c750faeaecba1e2",

2
50.md
View File

@@ -15,7 +15,7 @@ extensible framework for performing such queries.
## `search` filter field
A new `search` field is introduced for `REQ` messages from clients:
```jsonc
```yaml
{
// other fields on filter object...
"search": <string>

4
51.md
View File

@@ -128,7 +128,7 @@ Some clients have used these lists in the past, but they should work on transiti
### A _release artifact set_ of an Example App
```jsonc
```yaml
{
"id": "567b41fc9060c758c4216fe5f8d3df7c57daad7ae757fa4606f0c39d4dd220ef",
"pubkey": "d6dc95542e18b8b7aec2f14610f55c335abebec76f3db9e58c254661d0593a0c",
@@ -149,7 +149,7 @@ Some clients have used these lists in the past, but they should work on transiti
### An _app curation set_
```jsonc
```yaml
{
"id": "d8037fa866eb5acd2159960b3ada7284172f7d687b5289cc72a96ca2b431b611",
"pubkey": "78ce6faa72264387284e647ba6938995735ec8c7d5c5a65737e55130f026307d",

12
53.md
View File

@@ -16,7 +16,7 @@ Each `p` tag SHOULD have a **displayable** marker name for the current role (e.g
For example:
```jsonc
```yaml
{
"kind": 30311,
"tags": [
@@ -65,7 +65,7 @@ This feature is important to avoid malicious event owners adding large account h
Event `kind:1311` is live chat's channel message. Clients MUST include the `a` tag of the activity. An `e` tag denotes the direct parent message this post is replying to.
```jsonc
```yaml
{
"kind": 1311,
"tags": [
@@ -134,7 +134,7 @@ Meeting spaces contain one or more video/audio rooms where users can join and pa
A special event with `kind:30312` "Space Host" defines the configuration and properties of a virtual interactive space. Each space has a unique identifier and can host multiple events/meetings.
```jsonc
```yaml
{
"kind": 30312,
"tags": [
@@ -170,7 +170,7 @@ Provider roles (p tags):
A special event with kind:30313 represents a scheduled or ongoing meeting within a room. It MUST reference its parent room using the d tag.
```jsonc
```yaml
{
"kind": 30313,
"tags": [
@@ -206,7 +206,7 @@ Event management:
#### Meeting Space (kind:30312)
```jsonc
```yaml
{
"kind": 30312,
"tags": [
@@ -228,7 +228,7 @@ Event management:
#### Meeting room (kind:30313)
```jsonc
```yaml
{
"kind": 30313,
"tags": [

8
56.md
View File

@@ -43,7 +43,7 @@ further qualification and querying.
Example events
--------------
```jsonc
```yaml
{
"kind": 1984,
"tags": [
@@ -56,7 +56,7 @@ Example events
}
```
```jsonc
```yaml
{
"kind": 1984,
"tags": [
@@ -68,7 +68,7 @@ Example events
}
```
```jsonc
```yaml
{
"kind": 1984,
"tags": [
@@ -79,7 +79,7 @@ Example events
}
```
```jsonc
```yaml
{
"kind": 1984,
"tags": [

2
57.md
View File

@@ -174,7 +174,7 @@ A client can retrieve `zap receipt`s on events and pubkeys using a NIP-01 filter
When an event includes one or more `zap` tags, clients wishing to zap it SHOULD calculate the lnurl pay request based on the tags value instead of the event author's profile field. The tag's second argument is the `hex` string of the receiver's pub key and the third argument is the relay to download the receiver's metadata (Kind-0). An optional fourth parameter specifies the weight (a generalization of a percentage) assigned to the respective receiver. Clients should parse all weights, calculate a sum, and then a percentage to each receiver. If weights are not present, CLIENTS should equally divide the zap amount to all receivers. If weights are only partially present, receivers without a weight should not be zapped (`weight = 0`).
```jsonc
```yaml
{
"tags": [
[ "zap", "82341f882b6eabcd2ba7f1ef90aad961cf074af15b9ef44a09f9d2a8fbfbe6a2", "wss://nostr.oxtr.dev", "1" ], // 25%

6
58.md
View File

@@ -72,7 +72,7 @@ Clients SHOULD attempt to render the most appropriate badge thumbnail according
### Example of a Badge Definition event
```jsonc
```yaml
{
"pubkey": "alice",
"kind": 30009,
@@ -89,7 +89,7 @@ Clients SHOULD attempt to render the most appropriate badge thumbnail according
### Example of Badge Award event
```jsonc
```yaml
{
"id": "<badge award event id>",
"kind": 8,
@@ -106,7 +106,7 @@ Clients SHOULD attempt to render the most appropriate badge thumbnail according
### Example of a Profile Badges event
Honorable Bob The Brave:
```jsonc
```yaml
{
"kind": 10008,
"pubkey": "bob",

6
5A.md
View File

@@ -30,7 +30,7 @@ The site icon SHOULD be provided by setting the `/favicon.ico` path in the manif
For example, a root site manifest:
```jsonc
```yaml
{
"content": "",
"created_at": 1727373475,
@@ -56,7 +56,7 @@ For example, a root site manifest:
And a named site manifest:
```jsonc
```yaml
{
"content": "",
"created_at": 1727373475,
@@ -125,7 +125,7 @@ If parsing fails, the host server MUST treat the site as not found.
The host server should query for the site manifest event:
```jsonc
```yaml
// For root site (kind 15128, no d tag)
{ "kinds": [15128], "authors": [<pubkey>] }

6
61.md
View File

@@ -21,7 +21,7 @@ Alice wants to nutzap 1 sat to Bob because of an event `event-id-1` she liked.
2. Bob's client swaps the token into his wallet.
## Nutzap informational event
```jsonc
```yaml
{
"kind": 10019,
"tags": [
@@ -44,7 +44,7 @@ Event `kind:9321` is a nutzap event published by the sender, p-tagging the recip
Clients MUST prefix the public key they P2PK-lock with `"02"` (for nostr<>cashu compatibility).
```jsonc
```yaml
{
"kind": 9321,
"content": "Thanks for this great idea.",
@@ -91,7 +91,7 @@ When claiming a token the client SHOULD create a `kind:7376` event and `e` tag t
Multiple `kind:9321` events can be tagged in the same `kind:7376` event.
```jsonc
```yaml
{
"kind": 7376,
"content": nip44_encrypt([

4
62.md
View File

@@ -12,7 +12,7 @@ This NIP offers a Nostr-native way to request a complete reset of a key's finger
Kind `62` requests a specific relay to delete everything, including [NIP-09](09.md) Deletion Events, from the `.pubkey` until its `.created_at`.
```jsonc
```yaml
{
"kind": 62,
"pubkey": <32-byte hex-encoded public key of the event creator>,
@@ -46,7 +46,7 @@ Clients SHOULD send this event to the target relays only.
To request ALL relays to delete everything, the event MUST include a `relay` tag with the value `ALL_RELAYS` in uppercase.
```jsonc
```yaml
{
"kind": 62,
"pubkey": <32-byte hex-encoded public key of the event creator>,

4
64.md
View File

@@ -16,7 +16,7 @@ The `.content` of these notes is a string representing a [PGN-database][pgn_form
### Notes
```jsonc
```yaml
{
"kind": 64,
"content": "1. e4 *",
@@ -24,7 +24,7 @@ The `.content` of these notes is a string representing a [PGN-database][pgn_form
}
```
```jsonc
```yaml
{
"kind": 64,
"tags": [

2
65.md
View File

@@ -10,7 +10,7 @@ Defines a replaceable event using `kind:10002` to advertise relays where the use
The event MUST include a list of `r` tags with relay URLs as value and an optional `read` or `write` marker. If the marker is omitted, the relay is both **read** and **write**.
```jsonc
```yaml
{
"kind": 10002,
"tags": [

2
68.md
View File

@@ -16,7 +16,7 @@ Picture events contain a `title` tag and description in the `.content`.
They may contain multiple images to be displayed as a single post.
```jsonc
```yaml
{
"id": <32-bytes lowercase hex-encoded SHA-256 of the the serialized event data>,
"pubkey": <32-bytes lowercase hex-encoded public key of the event creator>,

2
70.md
View File

@@ -24,7 +24,7 @@ The tag is a simple tag with a single item: `["-"]`. It may be added to any even
- User `79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798` connects to relay `wss://example.com`:
```jsonc
```yaml
/* client: */
["EVENT",{"id":"cb8feca582979d91fe90455867b34dbf4d65e4b86e86b3c68c368ca9f9eef6f2","pubkey":"79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798","created_at":1707409439,"kind":1,"tags":[["-"]],"content":"hello members of the secret group","sig":"fa163f5cfb75d77d9b6269011872ee22b34fb48d23251e9879bb1e4ccbdd8aaaf4b6dc5f5084a65ef42c52fbcde8f3178bac3ba207de827ec513a6aa39fa684c"}]
/* relay: */

4
71.md
View File

@@ -128,7 +128,7 @@ Additionally `service nip96` may be included to allow clients to search the auth
### Optional tags for imported content:
* `origin` - Track original platform and ID: `["origin", "<platform>", "<external-id>", "<original-url>", "<optional-metadata>"]`
```jsonc
```yaml
{
"id": "<32-bytes lowercase hex-encoded SHA-256 of the the serialized event data>",
"pubkey": "<32-bytes lowercase hex-encoded public key of the event creator>",
@@ -174,7 +174,7 @@ Additionally `service nip96` may be included to allow clients to search the auth
## Addressable Event Example
```jsonc
```yaml
{
"id": <32-bytes lowercase hex-encoded SHA-256 of the the serialized event data>,
"pubkey": <32-bytes lowercase hex-encoded public key of the event creator>,

8
72.md
View File

@@ -14,7 +14,7 @@ The goal of this NIP is to enable public communities. It defines the replaceable
`Kind:34550` SHOULD include any field that helps define the community and the set of moderators. `relay` tags MAY be used to describe the preferred relay to download requests and approvals. A community definition event's `d` tag MAY double as its name, but if a `name` tag is provided, it SHOULD be displayed instead of the `d` tag.
```jsonc
```yaml
{
"created_at": <Unix timestamp in seconds>,
"kind": 34550,
@@ -49,7 +49,7 @@ The goal of this NIP is to enable public communities. It defines the replaceable
For top-level posts, the uppercase and lowercase NIP-22 tags should both refer to the community definition itself.
```jsonc
```yaml
{
"kind": 1111,
"tags": [
@@ -69,7 +69,7 @@ For top-level posts, the uppercase and lowercase NIP-22 tags should both refer t
For nested replies, the uppercase tags should still refer to the community definition, while the lowercase tags should refer to the parent post or reply.
```jsonc
```yaml
{
"kind": 1111,
"tags": [
@@ -102,7 +102,7 @@ The event SHOULD also include the JSON-stringified `post request` event inside t
Moderators MAY request deletion of their approval of a post at any time using [NIP-09 event deletion requests](09.md).
```jsonc
```yaml
{
"pubkey": "<32-bytes lowercase hex-encoded public key of the event creator>",
"kind": 4550,

10
73.md
View File

@@ -37,7 +37,7 @@ There are certain established global content identifiers such as [Book ISBNs](ht
For the webpage "https://myblog.example.com/post/2012-03-27/hello-world" the "i" and "k" tags are:
```jsonc
```yaml
[
["i", "https://myblog.example.com/post/2012-03-27/hello-world"],
["k", "web"]
@@ -90,7 +90,7 @@ bitcoin:tx:<txid, hex, lowercase>
E.g. https://blockstream.info/tx/a1075db55d416d3ca199f55b6084e2115b9345e16c5cf302fc80e9d5fbf5d48d
```jsonc
```yaml
[
["i", "bitcoin:tx:a1075db55d416d3ca199f55b6084e2115b9345e16c5cf302fc80e9d5fbf5d48d"],
["k", "bitcoin:tx"]
@@ -99,7 +99,7 @@ E.g. https://blockstream.info/tx/a1075db55d416d3ca199f55b6084e2115b9345e16c5cf30
E.g. https://blockstream.info/address/1HQ3Go3ggs8pFnXuHVHRytPCq5fGG8Hbhx
```jsonc
```yaml
[
["i", "bitcoin:address:1HQ3Go3ggs8pFnXuHVHRytPCq5fGG8Hbhx"],
["k", "bitcoin:address"]
@@ -115,7 +115,7 @@ ethereum:<chainId, integer>:address:<hex, lowercase>
E.g. https://etherscan.io/address/0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045
```jsonc
```yaml
[
["i", "ethereum:1:address:0xd8da6bf26964af9d7eed9e03e53415d37aa96045"],
["k", "ethereum:address"]
@@ -124,7 +124,7 @@ E.g. https://etherscan.io/address/0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045
E.g. https://gnosisscan.io/tx/0x98f7812be496f97f80e2e98d66358d1fc733cf34176a8356d171ea7fbbe97ccd
```jsonc
```yaml
[
["i", "ethereum:100:tx:0x98f7812be496f97f80e2e98d66358d1fc733cf34176a8356d171ea7fbbe97ccd"],
["k", "ethereum:tx"]

6
75.md
View File

@@ -21,7 +21,7 @@ The following tags are defined as REQUIRED.
Example event:
```jsonc
```yaml
{
"kind": 9041,
"tags": [
@@ -39,7 +39,7 @@ The following tags are OPTIONAL.
- `image` - an image for the goal
- `summary` - a brief description
```jsonc
```yaml
{
"kind": 9041,
"tags": [
@@ -60,7 +60,7 @@ The goal MAY include multiple beneficiary pubkeys by specifying [`zap` tags](57.
Addressable events can link to a goal by using a `goal` tag specifying the event id and an optional relay hint.
```jsonc
```yaml
{
"kind": 3xxxx,
"tags": [

8
77.md
View File

@@ -30,7 +30,7 @@ The above protocol only results in the client learning about IDs it has/needs, a
### Initial message (client to relay):
```jsonc
```yaml
[
"NEG-OPEN",
<subscription ID string>,
@@ -47,7 +47,7 @@ The above protocol only results in the client learning about IDs it has/needs, a
If a request cannot be serviced by the relay, an error is returned to the client:
```jsonc
```yaml
[
"NEG-ERR",
<subscription ID string>,
@@ -73,7 +73,7 @@ After a `NEG-ERR` is issued, the subscription is considered to be closed.
Relay and client alternate sending each other `NEG-MSG`s:
```jsonc
```yaml
[
"NEG-MSG",
<subscription ID string>,
@@ -87,7 +87,7 @@ Relay and client alternate sending each other `NEG-MSG`s:
When finished, the client should tell the relay it can release its resources with a `NEG-CLOSE`:
```jsonc
```yaml
[
"NEG-CLOSE",
<subscription ID string>

2
84.md
View File

@@ -26,7 +26,7 @@ useful when highlighting non-nostr content for which the client might be able to
(e.g. prompting the user or reading a `<link rel="me" href="nostr:nprofile1..." />` tag on the document). A role MAY be included as the
last value of the tag.
```jsonc
```yaml
{
"tags": [
["p", "<pubkey-hex>", "<relay-url>", "author"],

4
85.md
View File

@@ -23,7 +23,7 @@ Calculation results are saved in pre-defined tags whose syntax and semantics are
Example of ranking a pubkey with a web of trust score of `89`:
```jsonc
```yaml
{
"kind": 30382,
"pubkey": "<service pubkey>",
@@ -144,7 +144,7 @@ In TAs, `p`, `e`, and `a` tags with the same value as the `d` tag MAY be used to
Service Providers SHOULD sign a kind `0` of each service key that explains who controls the key and what the current version of the algorithm is about.
```jsonc
```yaml
{
"kind": 0,
"pubkey": "<service pubkey>",

8
89.md
View File

@@ -27,7 +27,7 @@ There are three actors to this workflow:
## Events
### Recommendation event
```jsonc
```yaml
{
"kind": 31989,
"pubkey": <recommender-user-pubkey>,
@@ -48,7 +48,7 @@ The second value of the tag SHOULD be a relay hint.
The third value of the tag SHOULD be the platform where this recommendation might apply.
### Handler information
```jsonc
```yaml
{
"kind": 31990,
"pubkey": "<application-pubkey>",
@@ -79,7 +79,7 @@ A tag without a second value in the array SHOULD be considered a generic handler
## Client tag
When publishing events, clients MAY include a `client` tag. Identifying the client that published the note. This tag is a tuple of `name`, `address` identifying a handler event and, a relay `hint` for finding the handler event. This has privacy implications for users, so clients SHOULD allow users to opt-out of using this tag.
```jsonc
```yaml
{
"kind": 1,
"tags": [
@@ -101,7 +101,7 @@ The client MIGHT query for the user's and the user's follows handler.
### User A recommends a `kind:31337`-handler
User A might be a user of Zapstr, a `kind:31337`-centric client (tracks). Using Zapstr, user A publishes an event recommending Zapstr as a `kind:31337`-handler.
```jsonc
```yaml
{
"kind": 31989,
"tags": [

12
90.md
View File

@@ -38,7 +38,7 @@ There are two actors in the workflow described in this NIP:
## Job request (`kind:5000-5999`)
A request to process data, published by a customer. This event signals that a customer is interested in receiving the result of some kind of compute.
```jsonc
```yaml
{
"kind": 5xxx, // kind in 5000-5999 range
"content": "",
@@ -88,7 +88,7 @@ If the user wants to keep the input parameters a secret, they can encrypt the `i
This param data will be encrypted and added to the `content` field and `p` tag should be present
```jsonc
```yaml
{
"content": "BE2Y4xvS6HIY7TozIgbEl3sAHkdZoXyLRRkZv4fLPh3R7LtviLKAJM5qpkC7D6VtMbgIt4iNcMpLtpo...",
"tags": [
@@ -104,7 +104,7 @@ This param data will be encrypted and added to the `content` field and `p` tag s
Service providers publish job results, providing the output of the job result. They should tag the original job request event id as well as the customer's pubkey.
```jsonc
```yaml
{
"pubkey": "<service-provider pubkey>",
"content": "<payload>",
@@ -129,7 +129,7 @@ Service providers publish job results, providing the output of the job result. T
If the request has encrypted params, then output should be encrypted and placed in `content` field. If the output is encrypted, then avoid including `i` tag with input-data as clear text.
Add a tag encrypted to mark the output content as `encrypted`
```jsonc
```yaml
{
"pubkey": "<service-provider pubkey>",
"content": "<encrypted payload>",
@@ -149,7 +149,7 @@ Add a tag encrypted to mark the output content as `encrypted`
Service providers can give feedback about a job back to the customer.
```jsonc
```yaml
{
"kind": 7000,
"content": "<empty-or-payload>",
@@ -213,7 +213,7 @@ This gives a higher level of flexibility to service providers (which sophisticat
## Appendix 2: Service provider discoverability
Service Providers MAY use NIP-89 announcements to advertise their support for job kinds:
```jsonc
```yaml
{
"kind": 31990,
"pubkey": "<pubkey>",

2
94.md
View File

@@ -28,7 +28,7 @@ This NIP specifies the use of the `1063` event kind, having in `content` a descr
* `fallback` (optional) zero or more fallback file sources in case `url` fails
* `service` (optional) service type which is serving the file (eg. [NIP-96](96.md))
```jsonc
```yaml
{
"kind": 1063,
"tags": [

10
96.md
View File

@@ -21,7 +21,7 @@ will not have to learn anything about nostr relays.
File storage servers wishing to be accessible by nostr users should opt-in by making available an https route at `/.well-known/nostr/nip96.json` with `api_url`:
```jsonc
```yaml
{
// Required
// File upload and deletion are served from this url
@@ -129,7 +129,7 @@ The `server` MUST link the user's `pubkey` string as the owner of the file so to
The upload response is a json object as follows:
```jsonc
```yaml
{
// "success" if successful or "error" if not
"status": "success",
@@ -204,7 +204,7 @@ the file processing is done.
If the processing isn't done, the server should reply at the `processing_url` url with **200 OK** and the following JSON:
```jsonc
```yaml
{
// It should be "processing". If "error" it would mean the processing failed.
"status": "processing",
@@ -289,7 +289,7 @@ Returns a list of files linked to the authenticated users pubkey.
Example Response:
```jsonc
```yaml
{
"count": 1, // server page size, eg. max(1, min(server_max_page_size, arg_count))
"total": 1, // total number of files
@@ -325,7 +325,7 @@ Note: HTTP File Storage Server developers may skip this section. This is meant f
A File Server Preference event is a kind 10096 replaceable event meant to select one or more servers the user wants
to upload files to. Servers are listed as `server` tags:
```jsonc
```yaml
{
"kind": 10096,
"content": "",

2
99.md
View File

@@ -54,7 +54,7 @@ Other common tags that might be useful.
## Example Event
```jsonc
```yaml
{
"kind": 30402,
"created_at": 1675642635,

2
A4.md
View File

@@ -10,7 +10,7 @@ This NIP defines kind `24` as a simple plaintext message to one or more Nostr us
The `.content` contains the message. `p` tags identify one or more receivers.
```jsonc
```yaml
{
"pubkey": "<sender-pubkey>",
"kind": 24,

2
B0.md
View File

@@ -28,7 +28,7 @@ Metadata fields can be added as tags to the event as necessary.
## Example event
```jsonc
```yaml
{
"kind": 39701,
"id": "d7a92714f81d0f712e715556aee69ea6da6bfb287e6baf794a095d301d603ec7",