Compare commits

...

29 Commits

Author SHA1 Message Date
fiatjaf_
a68553cce0 author
Co-authored-by: Râu Cao <842+raucao@users.noreply.github.com>
2025-04-30 10:10:42 -03:00
fiatjaf_
fc358c8eee blergh
Co-authored-by: hodlbod <jstaab@protonmail.com>
2025-04-29 16:31:33 -03:00
fiatjaf
31ace26aa2 <link> 2025-04-29 15:58:37 -03:00
Alexander Lopatin
85f3282e46 Fix JSON format (#1896) 2025-04-29 08:28:46 -07:00
Vitor Pamplona
77fdeeb6f1 Deprecates NIP-26 (#1051) 2025-04-29 09:31:22 -03:00
Sepehr Safari
b96b72b488 Add NIP-B0 Standardized Tags to README.md (#1895) 2025-04-29 21:21:27 +09:00
Sebastian Hagens
507830c5c4 Add kind 39701 web bookmarks to list of kinds in readme (#1891) 2025-04-25 12:32:49 -03:00
fiatjaf
473f651b3e uppercase B7 and B0. 2025-04-24 13:53:56 -03:00
fiatjaf
257e8700ea add B0 to index. 2025-04-24 13:52:59 -03:00
Sebastian Hagens
121258a611 adding more info / requirements for using kind 39701 for web bookmarks (NIP-B0) (#1849)
Co-authored-by: fiatjaf <fiatjaf@gmail.com>
2025-04-24 13:52:29 -03:00
fiatjaf_
5a371a5b92 add B7 NIP for Blossom interaction (#1822) 2025-04-24 13:47:04 -03:00
Awiteb
4f09333ab5 Fix nips titles and descriptions (#1888)
Signed-off-by: Awiteb <a@4rs.nl>
2025-04-23 11:57:55 -07:00
Awiteb
8cdfe98e74 fix: Fix NIP-66 title and description format (#1886) 2025-04-23 09:31:08 -07:00
alltheseas
4ba28112e6 Update 11.md with privacy policy and terms of service (#1882) 2025-04-21 15:56:43 -03:00
fiatjaf_
951aaa8ba1 nip7D: subject -> title (#1874) 2025-04-17 17:15:37 -03:00
William Casarin
c076437282 Quoted highlights (#1438)
Signed-off-by: William Casarin <jb55@jb55.com>
2025-04-17 12:55:17 -03:00
fiatjaf_
45f6d598a1 Shrink NIP-65 so it is clearer (#1879)
Co-authored-by: Vitor Pamplona <vitor@vitorpamplona.com>
2025-04-15 18:07:49 -03:00
k.
611b635186 nip-11: remove max filters, add max/default query limit, update example. (#1821) 2025-04-13 14:15:24 -03:00
Vitor Pamplona
55f96bbeef Fixes C0 links (#1870) 2025-04-08 07:56:38 -07:00
hodlbod
d5907d094b Add note about re-publishing kind 10002 (#1801)
Co-authored-by: Jon Staab <shtaab@gmail.com>
2025-04-07 09:43:01 -07:00
Awiteb
3e8c33ee79 NIP-C0: Add NIP-C0 tags to standardized tags table (#1865)
Co-authored-by: AsaiToshiya <to.asai.60@gmail.com>
2025-04-03 20:07:46 +09:00
fiatjaf
8f676dc0a5 nip73: bring back previous ordering. 2025-04-02 10:11:54 -03:00
Xavier Damman
67145a72b2 added blockchain transactions and addresses to NIP-73 (#1846) 2025-04-02 10:09:54 -03:00
AsaiToshiya
9821b0e999 Update README.md 2025-03-30 10:03:27 +09:00
mono
ca9904f042 Add birth field to NIP-24 for birth date representation (#1793) 2025-03-30 09:31:03 +09:00
fiatjaf
f901014065 rename 95 to C0. 2025-03-29 16:29:58 -03:00
Christian Chiarulli
7dad42c1cf NIP-C0: Code snippets (#1852) 2025-03-29 16:29:33 -03:00
Vitor Pamplona
86fc82ce4a Deprecates git replies in favor of NIP-22 (#1744) 2025-03-26 09:38:47 -03:00
Vitor Pamplona
0619f370bc NIP-17 Typos and grammar improvements (#1840) 2025-03-13 10:23:35 -03:00
19 changed files with 441 additions and 162 deletions

129
11.md
View File

@@ -21,6 +21,10 @@ When a relay receives an HTTP(s) request with an `Accept` header of `application
"supported_nips": <a list of NIP numbers supported by the relay>,
"software": <string identifying relay software URL>,
"version": <string version identifier>
"privacy_policy": <a link to a text file describing the relay's privacy policy>,
"terms_of_service": <a link to a text file describing the relay's term of service>,
}
```
@@ -74,21 +78,30 @@ The relay server implementation MAY be provided in the `software` attribute. If
The relay MAY choose to publish its software version as a string attribute. The string format is defined by the relay implementation. It is recommended this be a version number or commit identifier.
### Privacy Policy
The relay owner/admin MAY choose to link to a privacy policy document, which describes how the relay utilizes user data. Data collection, data usage, data retention, monetization of data, and third party data sharing SHOULD be included.
### Terms of Service
The relay owner/admin MAY choose to link to a terms of service document.
Extra Fields
------------
### Server Limitations
These are limitations imposed by the relay on clients. Your client
should expect that requests which exceed these *practical* limitations
should expect that requests exceed these *practical* limitations
are rejected or fail immediately.
```jsonc
{
"limitation": {
"max_message_length": 16384,
"max_subscriptions": 20,
"max_filters": 100,
"max_subscriptions": 300,
"max_limit": 5000,
"max_subid_length": 100,
"max_event_tags": 100,
@@ -98,33 +111,30 @@ are rejected or fail immediately.
"payment_required": true,
"restricted_writes": true,
"created_at_lower_limit": 31536000,
"created_at_upper_limit": 3
"created_at_upper_limit": 3,
"default_limit": 500
},
// other fields...
}
```
- `max_message_length`: this is the maximum number of bytes for incoming JSON that the relay
- `max_message_length`: the maximum number of bytes for incoming JSON that the relay
will attempt to decode and act upon. When you send large subscriptions, you will be
limited by this value. It also effectively limits the maximum size of any event. Value is
calculated from `[` to `]` and is after UTF-8 serialization (so some unicode characters
calculated from `[` to `]` after UTF-8 serialization (so some unicode characters
will cost 2-3 bytes). It is equal to the maximum size of the WebSocket message frame.
- `max_subscriptions`: total number of subscriptions that may be
active on a single websocket connection to this relay. It's possible
that authenticated clients with a (paid) relationship to the relay
active on a single websocket connection to this relay. Authenticated clients with a (paid) relationship to the relay
may have higher limits.
- `max_filters`: maximum number of filter values in each subscription.
Must be one or higher.
- `max_subid_length`: maximum length of subscription id as a string.
- `max_limit`: the relay server will clamp each filter's `limit` value to this number.
This means the client won't be able to get more than this number
of events from a single subscription filter. This clamping is typically done silently
by the relay, but with this number, you can know that there are additional results
if you narrowed your filter's time range or other parameters.
if you narrow your filter's time range or other parameters.
- `max_event_tags`: in any event, this is the maximum number of elements in the `tags` list.
@@ -142,7 +152,7 @@ Even if set to False, authentication may be required for specific actions.
- `payment_required`: this relay requires payment before a new connection may perform any action.
- `restricted_writes`: this relay requires some kind of condition to be fulfilled in order to
- `restricted_writes`: this relay requires some kind of condition to be fulfilled to
accept events (not necessarily, but including `payment_required` and `min_pow_difficulty`).
This should only be set to `true` when users are expected to know the relay policy before trying
to write to it -- like belonging to a special pubkey-based whitelist or writing only events of
@@ -152,6 +162,8 @@ a specific niche kind or content. Normal anti-spam heuristics, for example, do n
- `created_at_upper_limit`: 'created_at' upper limit
- `default_limit`: The maximum returned events if you send a filter with the limit set to 0.
### Event Retention
There may be a cost associated with storing data forever, so relays
@@ -212,7 +224,7 @@ flexibility is up to the client software.
```
- `relay_countries`: a list of two-level ISO country codes (ISO 3166-1 alpha-2) whose
laws and policies may affect this relay. `EU` may be used for European Union countries.
laws and policies may affect this relay. `EU` may be used for European Union countries. A `*` can be used for global relays.
Remember that a relay may be hosted in a country which is not the
country of the legal entities who own the relay, so it's very
@@ -237,7 +249,7 @@ To support this goal, relays MAY specify some of the following values.
- `language_tags` is an ordered list
of [IETF language tags](https://en.wikipedia.org/wiki/IETF_language_tag) indicating
the major languages spoken on the relay.
the major languages spoken on the relay. A `*` can be used for global relays.
- `tags` is a list of limitations on the topics to be discussed.
For example `sfw-only` indicates that only "Safe For Work" content
@@ -276,49 +288,82 @@ Relays that require payments may want to expose their fee schedules.
### Examples
As of 2 May 2023 the following command provided these results:
As of 25 March 2025 the following command provided these results:
```bash
$ curl -H "Accept: application/nostr+json" https://eden.nostr.land | jq
curl -H "Accept: application/nostr+json" https://jellyfish.land | jq
```
```json
{
"description": "nostr.land family of relays (us-or-01)",
"name": "nostr.land",
"pubkey": "52b4a076bcbbbdc3a1aefa3735816cf74993b1b8db202b01c883c58be7fad8bd",
"software": "custom",
"name": "JellyFish",
"description": "Stay Immortal!",
"banner": "https://image.nostr.build/7fdefea2dec1f1ec25b8ce69362566c13b2b7f13f1726c2e4584f05f64f62496.jpg",
"pubkey": "bf2bee5281149c7c350f5d12ae32f514c7864ff10805182f4178538c2c421007",
"contact": "hi@dezh.tech",
"software": "https://github.com/dezh-tech/immortal",
"supported_nips": [
1,
2,
4,
9,
11,
12,
16,
20,
22,
28,
33,
40
13,
17,
40,
42,
59,
62,
70
],
"version": "1.0.1",
"limitation": {
"payment_required": true,
"max_message_length": 65535,
"max_event_tags": 2000,
"max_subscriptions": 20,
"auth_required": false
},
"payments_url": "https://eden.nostr.land",
"version": "immortal - 0.0.9",
"relay_countries": [
"*"
],
"language_tags": [
"*"
],
"tags": [],
"posting_policy": "https://jellyfish.land/tos.txt",
"payments_url": "https://jellyfish.land/relay",
"icon": "https://image.nostr.build/2547e9ec4b23589e09bc7071e0806c3d4293f76284c58ff331a64bce978aaee8.jpg",
"retention": [],
"fees": {
"subscription": [
{
"amount": 2500000,
"unit": "msats",
"period": 2592000
"amount": 3000,
"period": 2628003,
"unit": "sats"
},
{
"amount": 8000,
"period": 7884009,
"unit": "sats"
},
{
"amount": 15000,
"period": 15768018,
"unit": "sats"
},
{
"amount": 28000,
"period": 31536036,
"unit": "sats"
}
]
},
"limitation": {
"auth_required": false,
"max_message_length": 70000,
"max_subid_length": 256,
"max_subscriptions": 350,
"min_pow_difficulty": 0,
"payment_required": true,
"restricted_writes": true,
"max_event_tags": 2000,
"max_content_length": 70000,
"created_at_lower_limit": 0,
"created_at_upper_limit": 2147483647,
"default_limit": 500,
"max_limit": 5000
}
}
```

14
17.md
View File

@@ -57,7 +57,7 @@ Kind `14`s MUST never be signed. If it is signed, the message might leak to rela
["file-type", "<file-mime-type>"],
["encryption-algorithm", "<encryption-algorithm>"],
["decryption-key", "<decryption-key>"],
["decryptiion-nonce", "<decryption-nonce>"],
["decryption-nonce", "<decryption-nonce>"],
["x", "<the SHA-256 hexencoded string of the file>"],
// rest of tags...
],
@@ -74,16 +74,16 @@ Kind 15 is used for sending encrypted file event messages:
- `content`: The URL of the file (`<file-url>`).
- `x` containing the SHA-256 hexencoded string of the file.
- `size` (optional) size of file in bytes
- `dim` (optional) size of file in pixels in the form `<width>x<height>`
- `blurhash`(optional) the [blurhash](https://github.com/woltapp/blurhash) to show while the file is being loaded by the client
- `thumb` (optional) url of thumbnail with same aspect ratio
- `dim` (optional) size of the file in pixels in the form `<width>x<height>`
- `blurhash`(optional) the [blurhash](https://github.com/woltapp/blurhash) to show while the client is loading the file
- `thumb` (optional) URL of thumbnail with same aspect ratio (encrypted with the same key, nonce)
- `fallback` (optional) zero or more fallback file sources in case `url` fails
Just like kind 14, kind `15`s MUST never be signed.
## Chat Rooms
The set of `pubkey` + `p` tags defines a chat room. If a new `p` tag is added or a current one is removed, a new room is created with clean message history.
The set of `pubkey` + `p` tags defines a chat room. If a new `p` tag is added or a current one is removed, a new room is created with a clean message history.
Clients SHOULD render messages of the same room in a continuous thread.
@@ -91,7 +91,7 @@ An optional `subject` tag defines the current name/topic of the conversation. An
## Encrypting
Following [NIP-59](59.md), the **unsigned** `kind:14` & `kind:15` chat message must be sealed (`kind:13`) and then gift-wrapped (`kind:1059`) to each receiver and the sender individually.
Following [NIP-59](59.md), the **unsigned** `kind:14` & `kind:15` chat messages must be sealed (`kind:13`) and then gift-wrapped (`kind:1059`) to each receiver and the sender individually.
```jsonc
{
@@ -173,7 +173,7 @@ The main limitation of this approach is having to send a separate encrypted even
Clients implementing this NIP should by default only connect to the set of relays found in their `kind:10050` list. From that they should be able to load all messages both sent and received as well as get new live updates, making it for a very simple and lightweight implementation that should be fast.
When sending a message to anyone, clients must then connect to the relays in the receiver's `kind:10050` and send the events there, but can disconnect right after unless more messages are expected to be sent (e.g. the chat tab is still selected). Clients should also send a copy of their outgoing messages to their own `kind:10050` relay set.
When sending a message to anyone, clients must then connect to the relays in the receiver's `kind:10050` and send the events there but can disconnect right after unless more messages are expected to be sent (e.g. the chat tab is still selected). Clients should also send a copy of their outgoing messages to their own `kind:10050` relay set.
## Examples

20
21.md
View File

@@ -12,9 +12,27 @@ The scheme is `nostr:`.
The identifiers that come after are expected to be the same as those defined in [NIP-19](19.md) (except `nsec`).
## Examples
#### Examples
- `nostr:npub1sn0wdenkukak0d9dfczzeacvhkrgz92ak56egt7vdgzn8pv2wfqqhrjdv9`
- `nostr:nprofile1qqsrhuxx8l9ex335q7he0f09aej04zpazpl0ne2cgukyawd24mayt8gpp4mhxue69uhhytnc9e3k7mgpz4mhxue69uhkg6nzv9ejuumpv34kytnrdaksjlyr9p`
- `nostr:note1fntxtkcy9pjwucqwa9mddn7v03wwwsu9j330jj350nvhpky2tuaspk6nqc`
- `nostr:nevent1qqstna2yrezu5wghjvswqqculvvwxsrcvu7uc0f78gan4xqhvz49d9spr3mhxue69uhkummnw3ez6un9d3shjtn4de6x2argwghx6egpr4mhxue69uhkummnw3ez6ur4vgh8wetvd3hhyer9wghxuet5nxnepm`
### Linking HTML pages to Nostr entities
`<link>` tags with `rel="alternate"` can be used to associate webpages to Nostr events, in cases where the same content is served via the two mediums (for example, a web server that exposes Markdown articles both as HTML pages and as `kind:30023' events served under itself as a relay or through some other relay). For example:
```
<head>
<link rel="alternate" href="nostr:naddr1qqyrzwrxvc6ngvfkqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cph95ag" />
</head>
```
Likewise, `<link>` tags with `rel="me"` or `rel="author"` can be used to assign authorship of webpages to Nostr profiles. For example:
```
<head>
<link rel="me" href="nostr:nprofile1qyxhwumn8ghj7mn0wvhxcmmvqyd8wumn8ghj7un9d3shjtnhv4ehgetjde38gcewvdhk6qpq80cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwswpnfsn" />
</head>
```

46
22.md
View File

@@ -18,9 +18,9 @@ and `p` for the author of the parent item.
```jsonc
{
kind: 1111,
content: '<comment>',
tags: [
"kind": 1111,
"content": "<comment>",
"tags": [
// root scope: event addresses, event ids, or I-tags.
["<A, E, I>", "<address, id or I-value>", "<relay or web page hint>", "<root event's pubkey, if an E tag>"],
// the root item kind
@@ -64,9 +64,9 @@ A comment on a blog post looks like this:
```jsonc
{
kind: 1111,
content: 'Great blog post!',
tags: [
"kind": 1111,
"content": "Great blog post!",
"tags": [
// top-level comments scope to event addresses or ids
["A", "30023:3c9849383bdea883b0bd16fece1ed36d37e37cdde3ce43b17ea4e9192ec11289:f9347ca7", "wss://example.relay"],
// the root kind
@@ -91,9 +91,9 @@ A comment on a [NIP-94](94.md) file looks like this:
```jsonc
{
kind: 1111,
content: 'Great file!',
tags: [
"kind": 1111,
"content": "Great file!",
"tags": [
// top-level comments have the same scope and reply to addresses or ids
["E", "768ac8720cdeb59227cf95e98b66560ef03d8bc9a90d721779e76e68fb42f5e6", "wss://example.relay", "3721e07b079525289877c366ccab47112bdff3d1b44758ca333feb2dbbbbe5bb"],
// the root kind
@@ -115,9 +115,9 @@ A reply to a comment looks like this:
```jsonc
{
kind: 1111,
content: 'This is a reply to "Great file!"',
tags: [
"kind": 1111,
"content": "This is a reply to \"Great file!\"",
"tags": [
// nip-94 file event id
["E", "768ac8720cdeb59227cf95e98b66560ef03d8bc9a90d721779e76e68fb42f5e6", "wss://example.relay", "fd913cd6fa9edb8405750cd02a8bbe16e158b8676c0e69fdc27436cc4a54cc9a"],
// the root kind
@@ -138,9 +138,9 @@ A comment on a website's url looks like this:
```jsonc
{
kind: 1111,
content: 'Nice article!',
tags: [
"kind": 1111,
"content": "Nice article!",
"tags": [
// referencing the root url
["I", "https://abc.com/articles/1"],
// the root "kind": for an url, the kind is its domain
@@ -159,11 +159,11 @@ A podcast comment example:
```jsonc
{
id: "80c48d992a38f9c445b943a9c9f1010b396676013443765750431a9004bdac05",
pubkey: "252f10c83610ebca1a059c0bae8255eba2f95be4d1d7bcfa89d7248a82d9f111",
kind: 1111,
content: "This was a great episode!",
tags: [
"id": "80c48d992a38f9c445b943a9c9f1010b396676013443765750431a9004bdac05",
"pubkey": "252f10c83610ebca1a059c0bae8255eba2f95be4d1d7bcfa89d7248a82d9f111",
"kind": 1111,
"content": "This was a great episode!",
"tags": [
// podcast episode reference
["I", "podcast:item:guid:d98d189b-dc7b-45b1-8720-d4b98690f31f", "https://fountain.fm/episode/z1y9TMQRuqXl2awyrQxg"],
// podcast episode type
@@ -181,9 +181,9 @@ A reply to a podcast comment:
```jsonc
{
kind: 1111,
content: "I'm replying to the above comment.",
tags: [
"kind": 1111,
"content": "I'm replying to the above comment.",
"tags": [
// podcast episode reference
["I", "podcast:item:guid:d98d189b-dc7b-45b1-8720-d4b98690f31f", "https://fountain.fm/episode/z1y9TMQRuqXl2awyrQxg"],
// podcast episode type

1
24.md
View File

@@ -17,6 +17,7 @@ These are extra fields not specified in NIP-01 that may be present in the string
- `website`: a web URL related in any way to the event author.
- `banner`: an URL to a wide (~1024x768) picture to be optionally displayed in the background of a profile screen.
- `bot`: a boolean to clarify that the content is entirely or partially the result of automation, such as with chatbots or newsfeeds.
- `birthday`: an object representing the author's birth date. The format is { "year": number, "month": number, "day": number }. Each field MAY be omitted.
### Deprecated fields

2
26.md
View File

@@ -1,3 +1,5 @@
> __Warning__ `unrecommended`: adds unecessary burden for little gain
NIP-26
=======

19
34.md
View File

@@ -125,24 +125,7 @@ Issues may have a `subject` tag, which clients can utilize to display a header.
## Replies
Replies are also Markdown text. The difference is that they MUST be issued as replies to either a `kind:1621` _issue_ or a `kind:1617` _patch_ event. The threading of replies and patches should follow NIP-10 rules.
```jsonc
{
"kind": 1622,
"content": "<markdown text>",
"tags": [
["a", "30617:<base-repo-owner-pubkey>:<base-repo-id>", "<relay-url>"],
["e", "<issue-or-patch-id-hex>", "", "root"],
// other "e" and "p" tags should be applied here when necessary, following the threading rules of NIP-10
["p", "<patch-author-pubkey-hex>", "", "mention"],
["e", "<previous-reply-id-hex>", "", "reply"],
// rest of tags...
],
// other fields...
}
```
Replies to either a `kind:1621` _issue_ or a `kind:1617` _patch_ event should follow [NIP-22 comment](22.md).
## Status

8
61.md
View File

@@ -46,10 +46,10 @@ Clients MUST prefix the public key they P2PK-lock with `"02"` (for nostr<>cashu
```jsonc
{
kind: 9321,
content: "Thanks for this great idea.",
pubkey: "<sender-pubkey>",
tags: [
"kind": 9321,
"content": "Thanks for this great idea.",
"pubkey": "<sender-pubkey>",
"tags": [
[ "proof", "{\"amount\":1,\"C\":\"02277c66191736eb72fce9d975d08e3191f8f96afb73ab1eec37e4465683066d3f\",\"id\":\"000a93d6f8a1d2c4\",\"secret\":\"[\\\"P2PK\\\",{\\\"nonce\\\":\\\"b00bdd0467b0090a25bdf2d2f0d45ac4e355c482c1418350f273a04fedaaee83\\\",\\\"data\\\":\\\"02eaee8939e3565e48cc62967e2fde9d8e2a4b3ec0081f29eceff5c64ef10ac1ed\\\"}]\"}" ],
[ "u", "https://stablenut.umint.cash" ],
[ "e", "<nutzapped-event-id>", "<relay-hint>" ],

48
65.md
View File

@@ -6,11 +6,9 @@ Relay List Metadata
`draft` `optional`
Defines a replaceable event using `kind:10002` to advertise preferred relays for discovering a user's content and receiving fresh content from others.
Defines a replaceable event using `kind:10002` to advertise relays where the user generally **writes** to and relays where the user generally **reads** mentions.
The event MUST include a list of `r` tags with relay URIs and a `read` or `write` marker. Relays marked as `read` / `write` are called READ / WRITE relays, respectively. If the marker is omitted, the relay is used for both purposes.
The `.content` is not used.
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
{
@@ -26,43 +24,19 @@ The `.content` is not used.
}
```
This NIP doesn't fully replace relay lists that are designed to configure a client's usage of relays (such as `kind:3` style relay lists). Clients MAY use other relay lists in situations where a `kind:10002` relay list cannot be found.
When downloading events **from** a user, clients SHOULD use the **write** relays of that user.
## When to Use Read and Write Relays
When downloading events **about** a user, where the user was tagged (mentioned), clients SHOULD use the user's **read** relays.
When seeking events **from** a user, Clients SHOULD use the WRITE relays of the user's `kind:10002`.
When publishing an event, clients SHOULD:
When seeking events **about** a user, where the user was tagged, Clients SHOULD use the READ relays of the user's `kind:10002`.
- Send the event to the **write** relays of the author
- Send the event to all **read** relays of each tagged user
When broadcasting an event, Clients SHOULD:
### Size
- Broadcast the event to the WRITE relays of the author
- Broadcast the event to all READ relays of each tagged user
Clients SHOULD guide users to keep `kind:10002` lists small (2-4 relays of each category).
## Motivation
### Discoverability
The old model of using a fixed relay list per user centralizes in large relay operators:
- Most users submit their posts to the same highly popular relays, aiming to achieve greater visibility among a broader audience
- Many users are pulling events from a large number of relays in order to get more data at the expense of duplication
- Events are being copied between relays, oftentimes to many different relays
This NIP allows Clients to connect directly with the most up-to-date relay set from each individual user, eliminating the need of broadcasting events to popular relays.
## Final Considerations
1. Clients SHOULD guide users to keep `kind:10002` lists small (2-4 relays).
2. Clients SHOULD spread an author's `kind:10002` event to as many relays as viable.
3. `kind:10002` events should primarily be used to advertise the user's preferred relays to others. A user's own client may use other heuristics for selecting relays for fetching data.
4. DMs SHOULD only be broadcasted to the author's WRITE relays and to the receiver's READ relays to keep maximum privacy.
5. If a relay signals support for this NIP in their [NIP-11](11.md) document that means they're willing to accept kind 10002 events from a broad range of users, not only their paying customers or whitelisted group.
6. Clients SHOULD deduplicate connections by normalizing relay URIs according to [RFC 3986](https://datatracker.ietf.org/doc/html/rfc3986#section-6).
## Related articles
- [Outbox model](https://mikedilger.com/gossip-model/)
- [What is the Outbox Model?](https://habla.news/u/hodlbod@coracle.social/8YjqXm4SKY-TauwjOfLXS)
Clients SHOULD spread an author's `kind:10002` event to as many relays as viable, paying attention to relays that, at any moment, serve naturally as well-known public indexers for these relay lists (where most other clients and users are connecting to in order to publish and fetch those).

6
66.md
View File

@@ -1,4 +1,8 @@
# NIP-66: Relay Discovery and Liveness Monitoring
NIP-66
======
Relay Discovery and Liveness Monitoring
-------------------
`draft` `optional`

6
69.md
View File

@@ -1,6 +1,8 @@
# NIP-69
NIP-69
======
## Peer-to-peer Order events
Peer-to-peer Order events
-------------------------
`draft` `optional`

83
73.md
View File

@@ -13,29 +13,32 @@ There are certain established global content identifiers such as [Book ISBNs](ht
## Supported IDs
| Type | `i` tag | `k` tag |
| --- | --- | --- |
| URLs | "`<URL, normalized, no fragment>`" | "web" |
| Hashtags | "#`<topic, lowercase>`" | "#" |
| Geohashes | "geo:`<geohash, lowercase>`" | "geo" |
| Books | "isbn:`<id, without hyphens>`" | "isbn" |
| Podcast Feeds | "podcast:guid:`<guid>`" | "podcast:guid" |
| Podcast Episodes | "podcast:item:guid:`<guid>`" | "podcast:item:guid" |
| Podcast Publishers | "podcast:publisher:guid:`<guid>`" | "podcast:publisher:guid" |
| Movies | "isan:`<id, without version part>`" | "isan" |
| Papers | "doi:`<id, lowercase>`" | "doi" |
| Type | `i` tag | `k` tag |
| --- | --- | --- |
| URLs | "`<URL, normalized, no fragment>`" | "web" |
| Books | "isbn:`<id, without hyphens>`" | "isbn" |
| Geohashes | "geo:`<geohash, lowercase>`" | "geo" |
| Movies | "isan:`<id, without version part>`" | "isan" |
| Papers | "doi:`<id, lowercase>`" | "doi" |
| Hashtags | "#`<topic, lowercase>`" | "#" |
| Podcast Feeds | "podcast:guid:`<guid>`" | "podcast:guid" |
| Podcast Episodes | "podcast:item:guid:`<guid>`" | "podcast:item:guid" |
| Podcast Publishers | "podcast:publisher:guid:`<guid>`" | "podcast:publisher:guid" |
| Blockchain Transaction | "`<blockchain>`:[`<chainId>`:]tx:`<txid, hex, lowercase>`" | "`<blockchain>`:tx" |
| Blockchain Address | "`<blockchain>`:[`<chainId>`:]address:`<address>`" | "`<blockchain>`:address" |
---
## Examples
### Webpages
For the webpage "https://myblog.example.com/post/2012-03-27/hello-world" the "i" and "k" tags are:
```jsonc
[
["i","https://myblog.example.com/post/2012-03-27/hello-world"],
["i", "https://myblog.example.com/post/2012-03-27/hello-world"],
["k", "web"]
]
```
@@ -58,6 +61,62 @@ Book ISBNs MUST be referenced _**without hyphens**_ as many book search APIs ret
Movie ISANs SHOULD be referenced _**without the version part**_ as the versions / edits of movies are not relevant. More info on ISAN parts here - https://support.isan.org/hc/en-us/articles/360002783131-Records-relations-and-hierarchies-in-the-ISAN-Registry
### Blockchain
`<blockchain>` can be any layer 1 chain (`bitcoin`, `ethereum`, `solana`, ...). If necessary (e.g. for ethereum), you can specify a `<chainId>`.
#### Bitcoin
```
bitcoin:address:<bech32, lowercase | base58, case sensitive>
bitcoin:tx:<txid, hex, lowercase>
```
E.g. https://blockstream.info/tx/a1075db55d416d3ca199f55b6084e2115b9345e16c5cf302fc80e9d5fbf5d48d
```jsonc
[
["i", "bitcoin:tx:a1075db55d416d3ca199f55b6084e2115b9345e16c5cf302fc80e9d5fbf5d48d"],
["k", "bitcoin:tx"]
]
```
E.g. https://blockstream.info/address/1HQ3Go3ggs8pFnXuHVHRytPCq5fGG8Hbhx
```jsonc
[
["i", "bitcoin:address:1HQ3Go3ggs8pFnXuHVHRytPCq5fGG8Hbhx"],
["k", "bitcoin:address"]
]
```
#### Ethereum (and other EVM chains)
```
ethereum:<chainId, integer>:tx:<txHash, hex, lowercase>
ethereum:<chainId, integer>:address:<hex, lowercase>
```
E.g. https://etherscan.io/address/0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045
```jsonc
[
["i", "ethereum:1:address:0xd8da6bf26964af9d7eed9e03e53415d37aa96045"],
["k", "ethereum:address"]
]
```
E.g. https://gnosisscan.io/tx/0x98f7812be496f97f80e2e98d66358d1fc733cf34176a8356d171ea7fbbe97ccd
```jsonc
[
["i", "ethereum:100:tx:0x98f7812be496f97f80e2e98d66358d1fc733cf34176a8356d171ea7fbbe97ccd"],
["k", "ethereum:tx"]
]
```
---
### Optional URL Hints

5
7D.md
View File

@@ -6,15 +6,14 @@ Threads
`draft` `optional`
A thread is a `kind 11` event. Threads SHOULD include a `subject` with a summary
of the thread's topic.
A thread is a `kind 11` event. Threads SHOULD include a `title`.
```json
{
"kind": 11,
"content": "Good morning",
"tags": [
["subject", "GM"]
["title", "GM"]
]
}
```

11
84.md
View File

@@ -23,7 +23,7 @@ or obvious non-useful information from the query string.
### Attribution
Clients MAY include one or more `p` tags, tagging the original authors of the material being highlighted; this is particularly
useful when highlighting non-nostr content for which the client might be able to get a nostr pubkey somehow
(e.g. prompting the user or reading a `<meta name="nostr:nprofile1..." />` tag on the document). A role MAY be included as the
(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
@@ -40,3 +40,12 @@ last value of the tag.
### Context
Clients MAY include a `context` tag, useful when the highlight is a subset of a paragraph and displaying the
surrounding content might be beneficial to give context to the highlight.
## Quote Highlights
A `comment` tag may be added to create a quote highlight. This MUST be rendered like a quote repost with the highlight as the quoted note.
This is to prevent the creation and multiple notes (highlight + kind 1) for a single highlight action, which looks bad in micro-blogging clients where these notes may appear in succession.
p-tag mentions MUST have a `mention` attribute to distinguish it from authors and editors.
r-tag urls from the comment MUST have a `mention` attribute to distinguish from the highlighted source url. The source url MUST have the `source` attribute.

6
88.md
View File

@@ -1,6 +1,8 @@
# NIP-88
NIP-88
======
## Polls
Polls
-----
`draft` `optional`

61
B0.md Normal file
View File

@@ -0,0 +1,61 @@
NIP-B0
======
Web Bookmarking
---------------
`draft` `optional`
This NIP defines `kind:39701` (an _addressable event_) for a URI as a web bookmark which uses the HTTP (Hypertext transfer protocol) scheme.
These web bookmark events are _addressable_ and deletable per [NIP-09](09.md).
### Editability
Web bookmarks are meant to be editable, so they should include a `d` tag with an identifier for the bookmark. Clients should take care to only publish and read these events from relays that implement that. If they don't do that they should also take care to hide old versions of the same bookmark they may receive.
### Format
The format uses an _addressable event_ of `kind:39701`.
The `.content` of these events should be a detailed description of the web bookmark. It is required but can be an empty string.
The `d` tag is required.
In this way web bookmarks events can be queried by the `d` tag by clients, which is just their URL without the scheme, which is always and everywhere assumed to be `https://` or `http://`.
The querystring and the hash must be removed entirely, unless their requirement is explicitly stated either by the user or by some hardcoded list of URLs that rely on querystrings for basic routing provided by the client.
### Metadata
For the date of the last update the `.created_at` field should be used. For "tags"/"hashtags" (i.e. topics about which the event might be of relevance) the `t` tag should be used.
Other metadata fields can be added as tags to the event as necessary.
* `"published_at"`, for the timestamp in unix seconds (stringified) of the first time the bookmark was published
* `"title"`, title about bookmark and can be used as a attribute for the HTML link element
## Example event
```jsonc
{
"kind": 39701,
"id": "d7a92714f81d0f712e715556aee69ea6da6bfb287e6baf794a095d301d603ec7",
"pubkey": "2729620da105979b22acfdfe9585274a78c282869b493abfa4120d3af2061298",
"created_at": 1738869705,
"tags": [
// Required tags
["d", "alice.blog/post"],
// Optional tags
["published_at", "1738863000"],
["title", "Blog insights by Alice"],
["t", "post"],
["t", "insight"]
],
"content": "A marvelous insight by Alice about the nature of blogs and posts.",
"sig": "36d34e6448fe0223e9999361c39c492a208bc423d2fcdfc2a3404e04df7c22dc65bbbd62dbe8a4373c62e4d29aac285b5aa4bb9b4b8053bd6207a8b45fbd0c98"
}
```
### Replies & Comments
Replies to `kind 39701` MUST use `kind 1111` events as comments with [NIP-22](22.md).

41
B7.md Normal file
View File

@@ -0,0 +1,41 @@
NIP-B7
======
Blossom media
-------------
`draft` `optional`
This NIP specifies how Nostr clients can use [Blossom][] for handling media.
Blossom is a set of standards (called BUDs) for dealing with servers that store files addressable by their SHA-256 sums. Nostr clients may make use of all the BUDs for allowing users to upload files, manage their own files and so on, but most importantly Nostr clients SHOULD make use of [BUD-03][] to fetch `kind:10063` lists of servers for each user:
```json
{
"id": "e4bee088334cb5d38cff1616e964369c37b6081be997962ab289d6c671975d71",
"pubkey": "781208004e09102d7da3b7345e64fd193cd1bc3fce8fdae6008d77f9cabcd036",
"content": "",
"kind": 10063,
"created_at": 1708774162,
"tags": [
["server", "https://blossom.self.hosted"],
["server", "https://cdn.blossom.cloud"]
],
"sig": "cc5efa74f59e80622c77cacf4dd62076bcb7581b45e9acff471e7963a1f4d8b3406adab5ee1ac9673487480e57d20e523428e60ffcc7e7a904ac882cfccfc653"
}
```
Whenever a Nostr client finds a URL in an event published by a given user and that URL ends a 64-character hex string (with or without an ending file extension) and that URL is not available anymore, that means that string is likely a representation of a sha256 and that the user may have a `kind:10063` list of Blossom servers published.
Given that, the client SHOULD look into the `kind:10063` list for other Blossom servers and lookup for the same 64-character hex string in them, by just using the hex string as a path (optionally with the file extension at the end), producing a URL like `https://blossom.self.hosted/<hex-string>.png`.
When downloading such files Nostr clients SHOULD verify that the sha256-hash of its contents matches the 64-character hex string.
More information can be found at [BUD-03][].
### More complex interactions
Clients may use other facilities exposed by Blossom servers (for example, for checking if a file exists in a Blossom server, instead of actually downloading it) which are better documented in the [BUDs][Blossom].
[Blossom]: https://github.com/hzrd149/blossom
[BUD-03]: https://github.com/hzrd149/blossom/blob/master/buds/03.md

69
C0.md Normal file
View File

@@ -0,0 +1,69 @@
NIP-C0
======
Code Snippets
-------------
`draft` `optional`
## Abstract
This NIP defines a new event kind for sharing and storing code snippets. Unlike regular text notes (`kind:1`), code snippets have specialized metadata like language, extension, and other code-specific attributes that enhance discoverability, syntax highlighting, and improved user experience.
## Event Kind
This NIP defines `kind:1337` as a code snippet event.
The `.content` field contains the actual code snippet text.
## Optional Tags
- `l` - Programming language name (lowercase). Examples: "javascript", "python", "rust"
- `name` - Name of the code snippet, commonly a filename. Examples: "hello-world.js", "quick-sort.py"
- `extension` - File extension (without the dot). Examples: "js", "py", "rs"
- `description` - Brief description of what the code does
- `runtime` - Runtime or environment specification (e.g., "node v18.15.0", "python 3.11")
- `license` - License under which the code is shared (e.g., "MIT", "GPL-3.0", "Apache-2.0")
- `dep` - Dependency required for the code to run (can be repeated)
- `repo` - Reference to a repository where this code originates
## Format
```json
{
"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>",
"created_at": <Unix timestamp in seconds>,
"kind": 1337,
"content": "function helloWorld() {\n console.log('Hello, Nostr!');\n}\n\nhelloWorld();",
"tags": [
["l", "javascript"],
["extension", "js"],
["name", "hello-world.js"],
["description", "A basic JavaScript function that prints 'Hello, Nostr!' to the console"],
["runtime", "node v18.15.0"],
["license", "MIT"],
["repo", "https://github.com/nostr-protocol/nostr"]
],
"sig": "<64-bytes signature of the id>"
}
```
## Client Behavior
Clients that support this NIP SHOULD:
1. Display code snippets with proper syntax highlighting based on the language.
2. Allow copying the full code snippet with a single action.
3. Render the code with appropriate formatting, preserving whitespace and indentation.
4. Display the language and extension prominently.
5. Provide "run" functionality for supported languages when possible.
6. Display the description (if available) as part of the snippet presentation.
Clients MAY provide additional functionality such as:
1. Code editing capabilities
2. Forking/modifying snippets
3. Creating executable environments based on the runtime/dependencies
4. Downloading the snippet as a file using the provided extension
5. Sharing the snippet with attribution

View File

@@ -44,7 +44,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
- [NIP-23: Long-form Content](23.md)
- [NIP-24: Extra metadata fields and tags](24.md)
- [NIP-25: Reactions](25.md)
- [NIP-26: Delegated Event Signing](26.md)
- [NIP-26: Delegated Event Signing](26.md) --- **unrecommended**: adds unecessary burden for little gain
- [NIP-27: Text Note References](27.md)
- [NIP-28: Public Chat](28.md)
- [NIP-29: Relay-based Groups](29.md)
@@ -89,6 +89,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
- [NIP-73: External Content IDs](73.md)
- [NIP-75: Zap Goals](75.md)
- [NIP-78: Application-specific data](78.md)
- [NIP-7D: Threads](7D.md)
- [NIP-84: Highlights](84.md)
- [NIP-86: Relay Management API](86.md)
- [NIP-88: Polls](88.md)
@@ -99,7 +100,9 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
- [NIP-96: HTTP File Storage Integration](96.md)
- [NIP-98: HTTP Auth](98.md)
- [NIP-99: Classified Listings](99.md)
- [NIP-7D: Threads](7D.md)
- [NIP-B0: Web Bookmarks](B0.md)
- [NIP-B7: Blossom](B7.md)
- [NIP-C0: Code Snippets](C0.md)
- [NIP-C7: Chats](C7.md)
## Event Kinds
@@ -148,9 +151,10 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
| `1068` | Poll | [88](88.md) |
| `1111` | Comment | [22](22.md) |
| `1311` | Live Chat Message | [53](53.md) |
| `1337` | Code Snippet | [C0](C0.md) |
| `1617` | Patches | [34](34.md) |
| `1621` | Issues | [34](34.md) |
| `1622` | Replies | [34](34.md) |
| `1622` | Git Replies (deprecated) | [34](34.md) |
| `1630`-`1633` | Status | [34](34.md) |
| `1971` | Problem Tracker | [nostrocket][nostrocket] |
| `1984` | Reporting | [56](56.md) |
@@ -245,6 +249,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
| `34550` | Community Definition | [72](72.md) |
| `38383` | Peer-to-peer Order events | [69](69.md) |
| `39000-9` | Group metadata events | [29](29.md) |
| `39701` | Web bookmarks | [B0](B0.md) |
[NUD: Custom Feeds]: https://wikifreedia.xyz/cip-01/
[nostrocket]: https://github.com/nostrocket/NIPS/blob/main/Problems.md
@@ -298,7 +303,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
| `I` | root external identity | -- | [22](22.md) |
| `k` | kind | -- | [18](18.md), [25](25.md), [72](72.md), [73](73.md) |
| `K` | root scope | -- | [22](22.md) |
| `l` | label, label namespace | -- | [32](32.md) |
| `l` | label, label namespace, language name| -- | [32](32.md), [C0](C0.md) |
| `L` | label namespace | -- | [32](32.md) |
| `m` | MIME type | -- | [94](94.md) |
| `p` | pubkey (hex) | relay URL, petname | [01](01.md), [02](02.md), [22](22.md) |
@@ -321,29 +326,34 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
| `clone` | git clone URL | -- | [34](34.md) |
| `content-warning` | reason | -- | [36](36.md) |
| `delegation` | pubkey, conditions, delegation token | -- | [26](26.md) |
| `description` | description | -- | [34](34.md), [57](57.md), [58](58.md) |
| `dep` | Required dependency | -- | [C0](C0.md) |
| `description` | description | -- | [34](34.md), [57](57.md), [58](58.md), [C0](C0.md) |
| `emoji` | shortcode, image URL | -- | [30](30.md) |
| `encrypted` | -- | -- | [90](90.md) |
| `extension` | File extension | -- | [C0](C0.md) |
| `expiration` | unix timestamp (string) | -- | [40](40.md) |
| `file` | full path (string) | -- | [35](35.md) |
| `goal` | event id (hex) | relay URL | [75](75.md) |
| `image` | image URL | dimensions in pixels | [23](23.md), [52](52.md), [58](58.md) |
| `imeta` | inline metadata | -- | [92](92.md) |
| `license` | License of the shared content | -- | [C0](C0.md) |
| `lnurl` | `bech32` encoded `lnurl` | -- | [57](57.md) |
| `location` | location string | -- | [52](52.md), [99](99.md) |
| `name` | name | -- | [34](34.md), [58](58.md), [72](72.md) |
| `name` | name | -- | [34](34.md), [58](58.md), [72](72.md), [C0](C0.md) |
| `nonce` | random | difficulty | [13](13.md) |
| `preimage` | hash of `bolt11` invoice | -- | [57](57.md) |
| `price` | price | currency, frequency | [99](99.md) |
| `proxy` | external ID | protocol | [48](48.md) |
| `published_at` | unix timestamp (string) | -- | [23](23.md) |
| `published_at` | unix timestamp (string) | -- | [23](23.md), [B0](B0.md) |
| `relay` | relay url | -- | [42](42.md), [17](17.md) |
| `relays` | relay list | -- | [57](57.md) |
| `repo` | Reference to the origin repository | -- | [C0](C0.md) |
| `runtime` | Runtime or environment specification | -- | [C0](C0.md) |
| `server` | file storage server url | -- | [96](96.md) |
| `subject` | subject | -- | [14](14.md), [17](17.md), [34](34.md) |
| `summary` | summary | -- | [23](23.md), [52](52.md) |
| `thumb` | badge thumbnail | dimensions in pixels | [58](58.md) |
| `title` | article title | -- | [23](23.md) |
| `title` | title | -- | [23](23.md), [B0](B0.md) |
| `tracker` | torrent tracker URL | -- | [35](35.md) |
| `web` | webpage URL | -- | [34](34.md) |
| `zap` | pubkey (hex), relay URL | weight | [57](57.md) |
@@ -384,4 +394,4 @@ All NIPs are public domain.
<a align="center" href="https://github.com/nostr-protocol/nips/graphs/contributors">
<img src="https://contrib.rocks/image?repo=nostr-protocol/nips" />
</a>
</a>