diff --git a/01.md b/01.md index 622e4a23..6f26a3a8 100644 --- a/01.md +++ b/01.md @@ -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"], diff --git a/02.md b/02.md index 8354bf0b..01e0be60 100644 --- a/02.md +++ b/02.md @@ -14,7 +14,7 @@ The `.content` is not used. For example: -```jsonc +```yaml { "kind": 3, "tags": [ diff --git a/05.md b/05.md index 57a39365..2694ce61 100644 --- a/05.md +++ b/05.md @@ -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, diff --git a/09.md b/09.md index f061464c..ab91af54 100644 --- a/09.md +++ b/09.md @@ -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>, diff --git a/11.md b/11.md index d1acab7b..5caaccc7 100644 --- a/11.md +++ b/11.md @@ -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": { diff --git a/15.md b/15.md index a316b390..80ad6ca4 100644 --- a/15.md +++ b/15.md @@ -75,7 +75,7 @@ Fields that are not self-explanatory: **Event Tags** -```jsonc +```yaml { "tags": [["d", , "about": , @@ -292,7 +292,7 @@ This event leverages naddr to enable comprehensive customization and sharing of ### Event `1021`: Bid -```jsonc +```yaml { "content": , "tags": [["e", ]], diff --git a/17.md b/17.md index ebf36f06..23fde73a 100644 --- a/17.md +++ b/17.md @@ -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": "", "created_at": "", @@ -143,7 +143,7 @@ An `e` tag denotes the direct parent message this post is replying to. ## File Message -```jsonc +```yaml { "pubkey": "", "created_at": "", diff --git a/22.md b/22.md index daad6eac..d4cd0e55 100644 --- a/22.md +++ b/22.md @@ -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": "", @@ -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.", diff --git a/25.md b/25.md index 7ac4fb18..fbe3c15c 100644 --- a/25.md +++ b/25.md @@ -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:", diff --git a/28.md b/28.md index 9ec2335a..d1acc810 100644 --- a/28.md +++ b/28.md @@ -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": , "tags": [["e", , , "root"]], @@ -89,7 +89,7 @@ Root message: Reply to another message: -```jsonc +```yaml { "content": , "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", ]], @@ -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", ]], diff --git a/29.md b/29.md index 3593c1f8..d3acd6a0 100644 --- a/29.md +++ b/29.md @@ -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": "", diff --git a/32.md b/32.md index 202200af..84670c97 100644 --- a/32.md +++ b/32.md @@ -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": [ diff --git a/34.md b/34.md index f3d41e42..3d85541a 100644 --- a/34.md +++ b/34.md @@ -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": "", // contents of @@ -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": "", @@ -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": "", diff --git a/39.md b/39.md index 29c08fea..37ffa4a8 100644 --- a/39.md +++ b/39.md @@ -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": [ diff --git a/42.md b/42.md index c2b6ded0..d7bde647 100644 --- a/42.md +++ b/42.md @@ -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": [ diff --git a/43.md b/43.md index d0742b47..3b77d6c5 100644 --- a/43.md +++ b/43.md @@ -21,7 +21,7 @@ This list should not be considered exhaustive or authoritative. To determine mem Example: -```jsonc +```yaml { "kind": 13534, "pubkey": "", @@ -45,7 +45,7 @@ The following tags are required: Example: -```jsonc +```yaml { "kind": 8000, "pubkey": "", @@ -68,7 +68,7 @@ The following tags are required: Example: -```jsonc +```yaml { "kind": 8001, "pubkey": "", @@ -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": "", @@ -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": "", @@ -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": [["-"]], diff --git a/46.md b/46.md index cdc1118d..8bad3db8 100644 --- a/46.md +++ b/46.md @@ -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": , @@ -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": , "method": , @@ -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 `/.well-known/nostr.json?name=_` MAY return this: -```jsonc +```yaml { "names":{ "_": , diff --git a/47.md b/47.md index 6830820a..708fb469 100644 --- a/47.md +++ b/47.md @@ -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", diff --git a/50.md b/50.md index 08ce4fd2..f421c270 100644 --- a/50.md +++ b/50.md @@ -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": diff --git a/51.md b/51.md index 91ade811..8b86403f 100644 --- a/51.md +++ b/51.md @@ -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", diff --git a/53.md b/53.md index fec1df28..dc0d943e 100644 --- a/53.md +++ b/53.md @@ -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": [ diff --git a/56.md b/56.md index dc6f0983..7f86de15 100644 --- a/56.md +++ b/56.md @@ -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": [ diff --git a/57.md b/57.md index 91eac306..bba24bf9 100644 --- a/57.md +++ b/57.md @@ -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% diff --git a/58.md b/58.md index 69bb110d..ab81936e 100644 --- a/58.md +++ b/58.md @@ -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": "", "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", diff --git a/5A.md b/5A.md index dd7e46ea..df91a015 100644 --- a/5A.md +++ b/5A.md @@ -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": [] } diff --git a/61.md b/61.md index 5842d6b3..bd2d8e6e 100644 --- a/61.md +++ b/61.md @@ -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([ diff --git a/62.md b/62.md index e0398d8c..9e7cd185 100644 --- a/62.md +++ b/62.md @@ -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>, diff --git a/64.md b/64.md index 318ea87c..ecbc8385 100644 --- a/64.md +++ b/64.md @@ -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": [ diff --git a/65.md b/65.md index 36f0d122..15d0e7e9 100644 --- a/65.md +++ b/65.md @@ -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": [ diff --git a/68.md b/68.md index 89b95894..60fc99eb 100644 --- a/68.md +++ b/68.md @@ -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>, diff --git a/70.md b/70.md index 0b4857e4..0a49b2ae 100644 --- a/70.md +++ b/70.md @@ -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: */ diff --git a/71.md b/71.md index 904efaa2..e55e470d 100644 --- a/71.md +++ b/71.md @@ -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", "", "", "", ""]` -```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>, diff --git a/72.md b/72.md index 2b4e7b8c..913679bb 100644 --- a/72.md +++ b/72.md @@ -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": , "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, diff --git a/73.md b/73.md index 3e975aed..8725acb6 100644 --- a/73.md +++ b/73.md @@ -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: 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::address: 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"] diff --git a/75.md b/75.md index ad933d5f..b335afb8 100644 --- a/75.md +++ b/75.md @@ -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": [ diff --git a/77.md b/77.md index ff4eba73..518f4328 100644 --- a/77.md +++ b/77.md @@ -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", , @@ -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", , @@ -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", , @@ -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", diff --git a/84.md b/84.md index 1094f555..998559dd 100644 --- a/84.md +++ b/84.md @@ -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 `` tag on the document). A role MAY be included as the last value of the tag. -```jsonc +```yaml { "tags": [ ["p", "", "", "author"], diff --git a/85.md b/85.md index fe5ff693..5c431bff 100644 --- a/85.md +++ b/85.md @@ -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": "", @@ -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": "", diff --git a/89.md b/89.md index dff4ea1d..fc1b4ed0 100644 --- a/89.md +++ b/89.md @@ -27,7 +27,7 @@ There are three actors to this workflow: ## Events ### Recommendation event -```jsonc +```yaml { "kind": 31989, "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": "", @@ -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": [ diff --git a/90.md b/90.md index 7746d534..a6ea3bcd 100644 --- a/90.md +++ b/90.md @@ -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": "", "content": "", @@ -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": "", "content": "", @@ -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": "", @@ -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": "", diff --git a/94.md b/94.md index 4cd7c826..6f277f60 100644 --- a/94.md +++ b/94.md @@ -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": [ diff --git a/96.md b/96.md index d2fbf304..8eb6a68f 100644 --- a/96.md +++ b/96.md @@ -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": "", diff --git a/99.md b/99.md index 2b6a97af..08b04cd0 100644 --- a/99.md +++ b/99.md @@ -54,7 +54,7 @@ Other common tags that might be useful. ## Example Event -```jsonc +```yaml { "kind": 30402, "created_at": 1675642635, diff --git a/A4.md b/A4.md index 36751c14..6b961509 100644 --- a/A4.md +++ b/A4.md @@ -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": "", "kind": 24, diff --git a/B0.md b/B0.md index 22ed9105..6f5359b3 100644 --- a/B0.md +++ b/B0.md @@ -28,7 +28,7 @@ Metadata fields can be added as tags to the event as necessary. ## Example event -```jsonc +```yaml { "kind": 39701, "id": "d7a92714f81d0f712e715556aee69ea6da6bfb287e6baf794a095d301d603ec7",