Compare commits

...

89 Commits

Author SHA1 Message Date
Kieran
e72cf63789 Update 94.md 2025-01-28 13:24:25 +00:00
Kieran
56f6919faa Add NIP-71 tags to NIP-94 spec
Adding `duration` and `bitrate` to NIP-94 to cover NIP-71 content
2025-01-28 13:23:39 +00:00
Asai Toshiya
a7f30b1eb2 add kind 32267 to list. (#1698) 2025-01-28 12:33:53 +09:00
Asai Toshiya
1b521d019a BREAKING.md: single quote -> back quote. 2025-01-23 21:39:23 +09:00
Asai Toshiya
cc3fbab153 fix "PRE" to "addressable event". (#1697) 2025-01-17 21:27:06 -03:00
Dan Gershony
3f11c00fb9 Update nip 59 typo (#1687) 2025-01-14 09:56:13 -08:00
Asai Toshiya
190122fd8d update kind 1 link. (#1686) 2025-01-14 06:13:39 -08:00
abhay-raizada
0782ebe0bc Reinstate NIP-88: Polls on Nostr (#1507) 2025-01-13 21:25:30 -03:00
P. Reis
512caf7fcd NIP-61: fix unfinished sentence (#1683) 2025-01-13 15:42:58 -08:00
hodlbod
6c62751e57 Warn against using 1111 to reply to kind 1 (#1680)
Co-authored-by: Jon Staab <shtaab@gmail.com>
2025-01-13 16:24:04 -03:00
Vitor Pamplona
0e3d1cd5d8 Moves Kind:1 definition to NIP-10 (#1076)
Co-authored-by: Michael J <37635304+buttercat1791@users.noreply.github.com>
2025-01-13 09:04:46 -08:00
T.Shinohara
5b6ca881e2 add t-tags in kind 41 (#1673) 2025-01-13 11:37:53 -03:00
Pablo Fernandez
0f376a7aa4 Merge pull request #1679 from nostr-protocol/reposted-70s
Don't stringify magic-wanded protected events in reposts
2025-01-13 14:35:56 +00:00
Pablo Fernandez
d96f6f852a Update 18.md
Co-authored-by: hodlbod <jstaab@protonmail.com>
2025-01-13 14:35:10 +00:00
Asai Toshiya
76fd221ff1 add kind 30267 to list. 2025-01-10 23:39:08 +09:00
pablof7z
1f8bbbfb50 specify magic-wanded protected events should not be stringified in a repost 2025-01-10 08:27:14 -06:00
Asai Toshiya
2561566af7 nip51: format tables. 2025-01-08 20:28:46 +09:00
Pablo Fernandez
c91098af86 Merge pull request #1640 from franzaps/application-sets
Update NIP-51 for software applications
2025-01-02 21:04:36 +00:00
Asai Toshiya
936befbf9b add NIP-22 link to P and p tags. 2025-01-02 23:53:33 +09:00
hodlbod
e42aae6184 Merge pull request #1666 from jdabs/master
Grammar updates to 47.md
2025-01-01 08:14:47 -08:00
jdabs
cd09e6c9d8 Grammar updates to 47.md
Minor grammatical edits for clarity.
- "It's" to "its" to show the possessive case intended instead of the contraction
- Correct article from "an" to "a" for the following d letter (consonant sound)
- Minor edit to fix comma splices with a semicolon ( ; ) to clarify two independent thoughts. Somewhat optional, but it clarifies the two long sentences. Period can instead be used instead as a new sentence.
2025-01-01 11:09:21 -05:00
Pablo Fernandez
42370a3d30 Merge pull request #1664 from nostr-protocol/p-tags-22
Add P-tags and p-tags to NIP-22
2024-12-31 15:38:35 +00:00
pablof7z
7622cdc9c0 adds P and p tags 2024-12-28 10:50:31 +00:00
hodlbod
b1a3ca4d0a Merge pull request #1662 from AsaiToshiya/AsaiToshiya-patch-35
rename NIP-44 in readme.
2024-12-27 05:28:32 -08:00
Alex Gleason
ee21566cc4 Merge pull request #1659 from kehiy/nip32
fix broken link.
2024-12-26 16:20:54 -06:00
Alex Gleason
342e5db8c9 Merge pull request #1663 from kehiy/typo
fix typo in nip-94.
2024-12-26 16:20:21 -06:00
Kay
b88f716eef fix typo in nip-94. 2024-12-26 22:13:22 +00:00
Asai Toshiya
e3911cc9e6 rename NIP-44 in readme. 2024-12-27 06:52:15 +09:00
Alex Gleason
2f3b68bb44 Merge pull request #1661 from kehiy/names
fix nip-46 and nip-47 names are changed.
2024-12-26 10:57:56 -06:00
Kay
9acad1c62c fix nip-46 and nip-47 names are changed. 2024-12-26 14:08:13 +00:00
Kay
71ca3f27f3 fix broken link. 2024-12-26 13:14:28 +00:00
Taha
9d4f2b42b4 add some missing words to readme (#1656) 2024-12-22 23:11:24 -03:00
hodlbod
6b4e0f80c2 Merge pull request #1655 from AsaiToshiya/AsaiToshiya-patch-35
nip44: update some nits.
2024-12-20 08:37:55 -08:00
Asai Toshiya
7e150faed4 nip44: update some nits. 2024-12-21 01:34:43 +09:00
Asai Toshiya
97bf5266d7 add kind 10013 to list. 2024-12-20 09:11:37 +09:00
Pablo Fernandez
8d14490692 Merge pull request #1124 from vitorpamplona/draft-event
Generic Draft Event
2024-12-19 15:17:55 +00:00
Vitor Pamplona
306be43fab removes new line 2024-12-19 10:16:57 -05:00
Vitor Pamplona
f7d97f3f40 Merge branch 'master' into draft-event 2024-12-19 10:15:46 -05:00
fiatjaf_
561059ff85 Merge pull request #1601 from coracle-social/nip29-join
Tweak group join requests to include user feedback
2024-12-12 21:20:59 -03:00
Jon Staab
a1ca7a194b Change strategy for naming groups 2024-12-10 19:25:28 -03:00
franzap
ed128aef46 App curation sets, minor fixes to release artifact sets 2024-12-10 15:02:54 -03:00
Jesus Christ
e942427f8f nip17: specify order (#1637)
Order specificity is implied better.
2024-12-09 12:13:59 -03:00
Josh Brown
624b989f9f clarify that Standard lists and Sets are both types of lists with heading level 2024-12-09 12:13:20 -03:00
hodlbod
b35dd7d294 Merge pull request #1635 from AsaiToshiya/update-breaking
Update BREAKING.md
2024-12-09 06:30:47 -08:00
Asai Toshiya
b94ad00ac7 BREAKING.md: add NIP-46 change 2024-12-09 13:29:10 +09:00
Asai Toshiya
d71887a8e2 BREAKING.md: merge duplicate lines 2024-12-09 13:19:16 +09:00
Asai Toshiya
33cad5108e Merge pull request #1633 from Gudnessuche/patch-5
Update 90.md
2024-12-08 21:37:37 +09:00
Jesus Christ
b04922586e Update 90.md
Added a period to show the end of "Protocol Flow" explanation
2024-12-08 12:34:34 +00:00
Asai Toshiya
d857cfb1b8 Merge pull request #1631 from TsukemonoGit/master
add Event Kinds kind:20 Picture NIP-68
2024-12-07 08:15:06 +09:00
mono
a2be191ecd Update README.md 2024-12-07 07:45:25 +09:00
mono
936616b3c0 Update README.md
add Event Kinds  
kind:20  Picture-first feeds
2024-12-07 07:43:52 +09:00
小原晴太
a92d2e2edd Clarify the units 2024-12-06 08:48:11 -03:00
fiatjaf
6d16019e9e nip46: abandon nip04 entirely and just use nip44. 2024-12-05 20:14:02 -03:00
hodlbod
2ac43aa3f1 Merge pull request #1627 from AsaiToshiya/AsaiToshiya-patch-34
add `P` tag to README.
2024-12-05 08:37:32 -08:00
Asai Toshiya
2776a2aa14 add P tag to README. 2024-12-06 00:58:50 +09:00
hodlbod
5ec59fd70c Merge pull request #1626 from s3-odara/patch-2
NIP-44: Proper base64 explanation
2024-12-04 08:57:03 -08:00
小原晴太
33efff81a6 NIP-44: Proper base64 explanation
"Encoding algorithm" instead of "compression algorithm"
2024-12-04 14:30:42 +00:00
Asai Toshiya
54c0c1352d BREAKING.md: fix change of 7822a8b1 2024-11-30 13:41:50 -03:00
Asai Toshiya
fe1fe75cae mark kind 30001 as deprecated. 2024-11-30 08:01:07 -03:00
Asai Toshiya
e9f4cf52f5 Merge pull request #1617 from s3-odara/patch-2
use example domain
2024-11-29 23:52:53 +09:00
小原晴太
2ffd8ec363 use example domain 2024-11-29 14:40:11 +00:00
Asai Toshiya
0352f8487d remove "NIP-" prefixes. 2024-11-28 23:45:47 +09:00
Asai Toshiya
aa2342bd9d Update BREAKING.md (#1615) 2024-11-28 08:24:01 -03:00
hodlbod
3d1a34de91 Merge pull request #1613 from stl1988/patch-1
Update README.md
2024-11-27 15:39:33 -08:00
stl1988
6acf1c780a Update README.md
Add NIP-68 to the list
2024-11-27 23:28:50 +01:00
Pablo Fernandez
e4cc95ea32 Merge pull request #1551 from vitorpamplona/instagram
Instagram feeds
2024-11-27 16:55:11 +00:00
Asai Toshiya
06dc14c9c1 Merge pull request #1611 from Gudnessuche/patch-1
multi_pay_invoice method Response error (grammatical)
2024-11-28 00:14:31 +09:00
Jesus Christ
821614aee1 multi_pay_invoice method Response error (grammatical)
The response section that explained how the multi_pay_invoice method worked had a grammatical error of explaining the differentiation between requests.

changed ".....contains an d tag" to "...contains a d tag"
2024-11-27 14:43:00 +00:00
Jon Staab
64624a62ea Add r to kind 10009 2024-11-27 08:51:40 -03:00
fiatjaf_
73f65133fc add NIP-86: Relay Management API (#1325)
Co-authored-by: Alex Gleason <alex@alexgleason.me>
2024-11-25 13:21:47 -03:00
hodlbod
e145577b0b Merge pull request #1597 from coracle-social/nip46-meta
Clarify nostrconnect metadata
2024-11-25 08:20:46 -08:00
Asai Toshiya
0e44178961 update related to NIP-29. 2024-11-25 12:51:21 -03:00
Jon Staab
43767e1e53 Add support for naming unmanaged groups 2024-11-24 19:21:06 -03:00
Jon Staab
4d47b38dbc Switch to rejecting duplicate joins 2024-11-23 07:09:25 -08:00
Jon Staab
d09b51246d Tweak group join requests to include user feedback 2024-11-22 14:09:12 -08:00
Jon Staab
7976f8ab77 Clarify nostrconnect metadata 2024-11-22 10:04:52 -08:00
Vitor Pamplona
dfd2c2b8ca Minor changes to simplify the text 2024-11-15 08:28:54 -05:00
Vitor Pamplona
a8dfdff753 Adds x tag to index by sha256
Co-authored-by: Pablo Fernandez <pfer@me.com>
2024-11-15 08:15:30 -05:00
Vitor Pamplona
82291c6afd adds location 2024-10-30 11:50:21 -04:00
Vitor Pamplona
5c7aad212e Adds language tag for images that contain text. 2024-10-28 15:51:54 -04:00
Vitor Pamplona
9517ac6f5d Enforces certain media types 2024-10-27 20:30:27 -04:00
Vitor Pamplona
66c5cc637f Instagram feeds 2024-10-27 19:43:43 -04:00
Vitor Pamplona
d5b77b6d73 Merge remote-tracking branch 'upstream/master' into draft-event
# Conflicts:
#	README.md
2024-05-30 15:32:46 -04:00
Vitor Pamplona
48674e5638 moves from NIP-35 to NIP-37 2024-05-30 15:31:33 -04:00
Vitor Pamplona
00b2e0a5cb Adds private outbox relays. 2024-05-30 15:27:59 -04:00
Vitor Pamplona
0ed2f63f22 Getting drafts to be deleted even without relays supporting deletion events. 2024-03-29 11:39:19 -04:00
Vitor Pamplona
f7f060303d Adds anchor events. 2024-03-14 14:07:23 -04:00
Vitor Pamplona
f96ccc6e35 Improved wording. 2024-03-14 08:52:58 -04:00
Vitor Pamplona
2f2dead4cc Adds draft event. 2024-03-14 08:38:37 -04:00
23 changed files with 592 additions and 149 deletions

5
01.md
View File

@@ -85,10 +85,11 @@ As a convention, all single-letter (only english alphabet letters: a-z, A-Z) key
### Kinds
Kinds specify how clients should interpret the meaning of each event and the other fields of each event (e.g. an `"r"` tag may have a meaning in an event of kind 1 and an entirely different meaning in an event of kind 10002). Each NIP may define the meaning of a set of kinds that weren't defined elsewhere. This NIP defines two basic kinds:
Kinds specify how clients should interpret the meaning of each event and the other fields of each event (e.g. an `"r"` tag may have a meaning in an event of kind 1 and an entirely different meaning in an event of kind 10002). Each NIP may define the meaning of a set of kinds that weren't defined elsewhere. [NIP-10](10.md), for instance, especifies the `kind:1` text note for social media applications.
This NIP defines one basic kind:
- `0`: **user metadata**: the `content` is set to a stringified JSON object `{name: <username>, about: <string>, picture: <url, string>}` describing the user who created the event. [Extra metadata fields](24.md#kind-0) may be set. A relay may delete older events once it gets a new one for the same pubkey.
- `1`: **text note**: the `content` is set to the **plaintext** content of a note (anything the user wants to say). Content that must be parsed, such as Markdown and HTML, should not be used. Clients should also not parse content as those.
And also a convention for kind ranges that allow for easier experimentation and flexibility of relay implementation:

16
10.md
View File

@@ -1,14 +1,22 @@
NIP-10
======
On "e" and "p" tags in Text Events (kind 1)
-------------------------------------------
Text Notes and Threads
----------------------
`draft` `optional`
This NIP defines `kind:1` as a simple plaintext note.
## Abstract
This NIP describes how to use "e" and "p" tags in text events, especially those that are replies to other text events. It helps clients thread the replies into a tree rooted at the original event.
This NIP describes how to use "e" and "p" tags in text events, especially those that are replies to other text events. It helps clients thread the replies into a tree rooted at the original event.
The `.content` property contains some human-readable text.
`e` and `p` tags can be used to define note threads, replies and mentions.
Markup languages such as markdown and HTML SHOULD NOT be used.
## Marked "e" tags (PREFERRED)
`["e", <event-id>, <relay-url>, <marker>, <pubkey>]`

2
17.md
View File

@@ -133,7 +133,7 @@ When sending a message to anyone, clients must then connect to the relays in the
This example sends the message `Hola, que tal?` from `nsec1w8udu59ydjvedgs3yv5qccshcj8k05fh3l60k9x57asjrqdpa00qkmr89m` to `nsec12ywtkplvyq5t6twdqwwygavp5lm4fhuang89c943nf2z92eez43szvn4dt`.
The two final GiftWraps, one to the receiver and the other to the sender, are:
The two final GiftWraps, one to the receiver and the other to the sender, respectively, are:
```json
{

2
18.md
View File

@@ -10,6 +10,7 @@ A repost is a `kind 6` event that is used to signal to followers
that a `kind 1` text note is worth reading.
The `content` of a repost event is _the stringified JSON of the reposted note_. It MAY also be empty, but that is not recommended.
Reposts of [NIP-70](70.md)-protected events SHOULD always have an empty `content`.
The repost event MUST include an `e` tag with the `id` of the note that is
being reposted. That tag MUST include a relay URL as its third entry
@@ -41,3 +42,4 @@ as a "generic repost", that can include any kind of event inside other than
`kind 16` reposts SHOULD contain a `k` tag with the stringified kind number
of the reposted event as its value.

33
22.md
View File

@@ -13,6 +13,9 @@ It uses `kind:1111` with plaintext `.content` (no HTML, Markdown, or other forma
Comments MUST point to the root scope using uppercase tag names (e.g. `K`, `E`, `A` or `I`)
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
{
kind: 1111,
@@ -23,10 +26,16 @@ and MUST point to the parent item with lowercase ones (e.g. `k`, `e`, `a` or `i`
// the root item kind
["K", "<root kind>"],
// pubkey of the author of the root scope event
["P", "<root-pubkey>", "relay-url-hint"],
// parent item: event addresses, event ids, or i-tags.
["<a, e, i>", "<address, id or i-value>", "<relay or web page hint>", "<parent event's pubkey, if an e tag>"],
// parent item kind
["k", "<parent comment kind>"]
["k", "<parent comment kind>"],
// parent item pubkey
["p", "<parent-pubkey>", "relay-url-hint"]
]
// other fields
}
@@ -46,11 +55,8 @@ Their uppercase versions use the same type of values but relate to the root item
```
`p` tags SHOULD be used when mentioning pubkeys in the `.content` with [NIP-21](21.md).
If the parent item is an event, a `p` tag set to the parent event's author SHOULD be added.
```json
["p", "<pubkey>", "<relay-url>"]
```
Comments MUST NOT be used to reply to kind 1 notes. [NIP-10](10.md) should instead be followed.
## Examples
@@ -65,13 +71,17 @@ A comment on a blog post looks like this:
["A", "30023:3c9849383bdea883b0bd16fece1ed36d37e37cdde3ce43b17ea4e9192ec11289:f9347ca7", "wss://example.relay"],
// the root kind
["K", "30023"],
// author of root event
["P", "3c9849383bdea883b0bd16fece1ed36d37e37cdde3ce43b17ea4e9192ec11289", "wss://example.relay"]
// the parent event address (same as root for top-level comments)
["a", "30023:3c9849383bdea883b0bd16fece1ed36d37e37cdde3ce43b17ea4e9192ec11289:f9347ca7", "wss://example.relay"],
// when the parent event is replaceable or addressable, also include an `e` tag referencing its id
["e", "5b4fc7fed15672fefe65d2426f67197b71ccc82aa0cc8a9e94f683eb78e07651", "wss://example.relay"],
// the parent event kind
["k", "30023"]
["k", "30023"],
// author of the parent event
["p", "3c9849383bdea883b0bd16fece1ed36d37e37cdde3ce43b17ea4e9192ec11289", "wss://example.relay"]
]
// other fields
}
@@ -88,11 +98,14 @@ A comment on a [NIP-94](94.md) file looks like this:
["E", "768ac8720cdeb59227cf95e98b66560ef03d8bc9a90d721779e76e68fb42f5e6", "wss://example.relay", "3721e07b079525289877c366ccab47112bdff3d1b44758ca333feb2dbbbbe5bb"],
// the root kind
["K", "1063"],
// author of the root event
["P", "3721e07b079525289877c366ccab47112bdff3d1b44758ca333feb2dbbbbe5bb"],
// the parent event id (same as root for top-level comments)
["e", "768ac8720cdeb59227cf95e98b66560ef03d8bc9a90d721779e76e68fb42f5e6", "wss://example.relay", "3721e07b079525289877c366ccab47112bdff3d1b44758ca333feb2dbbbbe5bb"],
// the parent kind
["k", "1063"]
["k", "1063"],
["p", "3721e07b079525289877c366ccab47112bdff3d1b44758ca333feb2dbbbbe5bb"]
]
// other fields
}
@@ -109,11 +122,13 @@ A reply to a comment looks like this:
["E", "768ac8720cdeb59227cf95e98b66560ef03d8bc9a90d721779e76e68fb42f5e6", "wss://example.relay", "fd913cd6fa9edb8405750cd02a8bbe16e158b8676c0e69fdc27436cc4a54cc9a"],
// the root kind
["K", "1063"],
["P", "fd913cd6fa9edb8405750cd02a8bbe16e158b8676c0e69fdc27436cc4a54cc9a"],
// the parent event
["e", "5c83da77af1dec6d7289834998ad7aafbd9e2191396d75ec3cc27f5a77226f36", "wss://example.relay", "93ef2ebaaf9554661f33e79949007900bbc535d239a4c801c33a4d67d3e7f546"],
// the parent kind
["k", "1111"]
["k", "1111"],
["p", "93ef2ebaaf9554661f33e79949007900bbc535d239a4c801c33a4d67d3e7f546"]
]
// other fields
}
@@ -178,7 +193,9 @@ A reply to a podcast comment:
["e", "80c48d992a38f9c445b943a9c9f1010b396676013443765750431a9004bdac05", "wss://example.relay", "252f10c83610ebca1a059c0bae8255eba2f95be4d1d7bcfa89d7248a82d9f111"],
// the parent comment kind
["k", "1111"]
["p", "252f10c83610ebca1a059c0bae8255eba2f95be4d1d7bcfa89d7248a82d9f111"]
]
// other fields
}
```

9
28.md
View File

@@ -52,10 +52,17 @@ Clients MAY add additional metadata fields.
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
{
"content": "{\"name\": \"Updated Demo Channel\", \"about\": \"Updating a test channel.\", \"picture\": \"https://placekitten.com/201/201\", \"relays\": [\"wss://nos.lol\", \"wss://nostr.mom\"]}",
"tags": [["e", <channel_create_event_id>, <relay-url>]],
"tags": [
["e", <channel_create_event_id>, <relay-url>, "root"],
["t", <category_name-1>],
["t", <category_name-2>],
["t", <category_name-3>],
],
// other fields...
}
```

14
29.md
View File

@@ -22,15 +22,13 @@ Relays are supposed to generate the events that describe group metadata and grou
A group may be identified by a string in the format `<host>'<group-id>`. For example, a group with _id_ `abcdef` hosted at the relay `wss://groups.nostr.com` would be identified by the string `groups.nostr.com'abcdef`.
Group identifiers must be strings restricted to the characters `a-z0-9-_`.
Group identifiers must be strings restricted to the characters `a-z0-9-_`, and SHOULD be random in order to avoid name collisions.
When encountering just the `<host>` without the `'<group-id>`, clients can choose to connect to the group with id `_`, which is a special top-level group dedicated to relay-local discussions.
Group identifiers in most cases should be random or pseudo-random, as that mitigates message replay confusion and ensures they can be migrated or forked to other relays easily without risking conflicting with other groups using the same id in these new relays. This isn't a hard rule, as, for example, in `unmanaged` and/or ephemeral relays groups might not want to migrate ever, so they might not care about this. Notably, the `_` relay-local group isn't expected to be migrated ever.
When encountering just the `<host>` without the `'<group-id>`, clients MAY infer `_` as the group id, which is a special top-level group dedicated to relay-local discussions.
## The `h` tag
Events sent by users to groups (chat messages, text notes, moderation events etc) must have an `h` tag with the value set to the group _id_.
Events sent by users to groups (chat messages, text notes, moderation events etc) MUST have an `h` tag with the value set to the group _id_.
## Timeline references
@@ -72,7 +70,7 @@ These are events that can be sent by users to manage their situation in a group,
- *join request* (`kind:9021`)
Any user can send one of these events to the relay in order to be automatically or manually added to the group. If the group is `open` the relay will automatically issue a `kind:9000` in response adding this user. Otherwise group admins may choose to query for these requests and act upon them.
Any user can send a kind `9021` event to the relay in order to request admission to the group. Relays MUST reject the request if the user has not been added to the group. The accompanying error message SHOULD explain whether the rejection is final, if the request is pending review, or if some other special handling is relevant (e.g. if payment is required). If a user is already a member, the event MUST be rejected with `duplicate: ` as the error message prefix.
```json
{
@@ -241,4 +239,6 @@ A definition for `kind:10009` was included in [NIP-51](51.md) that allows client
### Using `unmanaged` relays
To prevent event leakage, replay and confusion, when using `unmanaged` relays, clients should include the [NIP-70](70.md) `-` tag, as just the `previous` tag won't be checked by other `unmanaged` relays.
To prevent event leakage, when using `unmanaged` relays, clients should include the [NIP-70](70.md) `-` tag, as just the `previous` tag won't be checked by other `unmanaged` relays.
Groups MAY be named without relay support by adding a `name` to the corresponding tag in a user's `kind 10009` group list.

4
32.md
View File

@@ -157,7 +157,7 @@ considered open for public use, and not proprietary. In other words, if there is
namespace that fits your use case, use it even if it points to someone else's domain name.
Vocabularies MAY choose to fully qualify all labels within a namespace (for example,
`["l", "com.example.vocabulary:my-label"]`. This may be preferred when defining more
`["l", "com.example.vocabulary:my-label"]`). This may be preferred when defining more
formal vocabularies that should not be confused with another namespace when querying
without an `L` tag. For these vocabularies, all labels SHOULD include the namespace
(rather than mixing qualified and unqualified labels).
@@ -173,4 +173,4 @@ Appendix: Known Ontologies
Below is a non-exhaustive list of ontologies currently in widespread use.
- [social.ontolo.categories](https://ontolo.social/)
- [social ontology categories](https://github.com/CLARIAH/awesome-humanities-ontologies)

50
37.md Normal file
View File

@@ -0,0 +1,50 @@
NIP-37
======
Draft Events
------------
`draft` `optional`
This NIP defines kind `31234` as a private wrap for drafts of any other event kind.
The draft event is JSON-stringified, [NIP44-encrypted](44.md) to the signer's public key and placed inside the `.content` of the event.
An additional `k` tag identifies the kind of the draft event.
```js
{
"kind": 31234,
"tags": [
["d", "<identifier>"],
["k", "<kind of the draft event>"],
["e", "<anchor event event id>", "<relay-url>"],
["a", "<anchor event address>", "<relay-url>"],
],
"content": nip44Encrypt(JSON.stringify(draft_event)),
// other fields
}
```
A blanked `.content` means this draft has been deleted by a client but relays still have the event.
Tags `e` and `a` identify one or more anchor events, such as parent events on replies.
## Relay List for Private Content
Kind `10013` indicates the user's preferred relays to store private events like Drafts. The event MUST include a list of `relay` URLs in private tags. Private tags are JSON Stringified, NIP-44-encrypted to the signer's keys and placed inside the .content of the event.
```js
{
"kind": 10013,
"tags": [],
"content": nip44Encrypt(JSON.stringify([
["relay", "wss://myrelay.mydomain.com"]
]))
//...other fields
}
```
Relays listed in this event SHOULD be authed and only allow downloads to events signed by the authed user.
Clients SHOULD publish kind `10013` events to the author's [NIP-65](65.md) `write` relays.

14
44.md
View File

@@ -8,11 +8,11 @@ Encrypted Payloads (Versioned)
The NIP introduces a new data format for keypair-based encryption. This NIP is versioned
to allow multiple algorithm choices to exist simultaneously. This format may be used for
many things, but MUST be used in the context of a signed event as described in NIP 01.
many things, but MUST be used in the context of a signed event as described in NIP-01.
*Note*: this format DOES NOT define any `kind`s related to a new direct messaging standard,
only the encryption required to define one. It SHOULD NOT be used as a drop-in replacement
for NIP 04 payloads.
for NIP-04 payloads.
## Versions
@@ -41,7 +41,7 @@ On its own, messages sent using this scheme have a number of important shortcomi
- No post-compromise security: when a key is compromised, it is possible to decrypt all future conversations
- No post-quantum security: a powerful quantum computer would be able to decrypt the messages
- IP address leak: user IP may be seen by relays and all intermediaries between user and relay
- Date leak: `created_at` is public, since it is a part of NIP 01 event
- Date leak: `created_at` is public, since it is a part of NIP-01 event
- Limited message size leak: padding only partially obscures true message length
- No attachments: they are not supported
@@ -63,7 +63,7 @@ NIP-44 version 2 has the following design characteristics:
- SHA256 is used instead of SHA3 or BLAKE because it is already used in nostr. Also BLAKE's speed advantage
is smaller in non-parallel environments.
- A custom padding scheme is used instead of padmé because it provides better leakage reduction for small messages.
- Base64 encoding is used instead of another compression algorithm because it is widely available, and is already used in nostr.
- Base64 encoding is used instead of another encoding algorithm because it is widely available, and is already used in nostr.
### Encryption
@@ -86,7 +86,7 @@ NIP-44 version 2 has the following design characteristics:
- Content must be encoded from UTF-8 into byte array
- Validate plaintext length. Minimum is 1 byte, maximum is 65535 bytes
- Padding format is: `[plaintext_length: u16][plaintext][zero_bytes]`
- Padding algorithm is related to powers-of-two, with min padded msg size of 32
- Padding algorithm is related to powers-of-two, with min padded msg size of 32 bytes
- Plaintext length is encoded in big-endian as first 2 bytes of the padded blob
5. Encrypt padded content
- Use ChaCha20, with key and nonce from step 3
@@ -148,8 +148,8 @@ validation rules, refer to BIP-340.
- `x[i:j]`, where `x` is a byte array and `i, j <= 0` returns a `(j - i)`-byte array with a copy of the
`i`-th byte (inclusive) to the `j`-th byte (exclusive) of `x`.
- Constants `c`:
- `min_plaintext_size` is 1. 1b msg is padded to 32b.
- `max_plaintext_size` is 65535 (64kb - 1). It is padded to 65536.
- `min_plaintext_size` is 1. 1 byte msg is padded to 32 bytes.
- `max_plaintext_size` is 65535 (64kB - 1). It is padded to 65536 bytes.
- Functions
- `base64_encode(string)` and `base64_decode(bytes)` are Base64 ([RFC 4648](https://datatracker.ietf.org/doc/html/rfc4648), with padding)
- `concat` refers to byte array concatenation

34
46.md
View File

@@ -45,15 +45,25 @@ _remote-signer_ provides connection token in the form:
bunker://<remote-signer-pubkey>?relay=<wss://relay-to-connect-on>&relay=<wss://another-relay-to-connect-on>&secret=<optional-secret-value>
```
_user_ passes this token to _client_, which then sends `connect` request to _remote-signer_ via the specified relays. Optional secret can be used for single successfully established connection only, _remote-signer_ SHOULD ignore new attempts to establish connection with old secret.
_user_ passes this token to _client_, which then sends `connect` request to _remote-signer_ via the specified relays. Optional secret can be used for single successfully established connection only, _remote-signer_ SHOULD ignore new attempts to establish connection with old secret.
### Direct connection initiated by the _client_
_client_ provides a connection token in the form:
_client_ provides a connection token using `nostrconnect://` as the protocol, and `client-pubkey` as the origin. Additional information should be passed as query parameters:
- `relay` (required) - one or more relay urls on which the _client_ is listening for responses from the _remote-signer_.
- `secret` (required) - a short random string that the _remote-signer_ should return as the `result` field of its response.
- `perms` (optional) - a comma-separated list of permissions the _client_ is requesting be approved by the _remote-signer_
- `name` (optional) - the name of the _client_ application
- `url` (optional) - the canonical url of the _client_ application
- `image` (optional) - a small image representing the _client_ application
Here's an example:
```
nostrconnect://<client-pubkey>?relay=<wss://relay-to-connect-on>&metadata=<json metadata: {"name":"...", "url": "...", "description": "...", "perms": "..."}>&secret=<required-secret-value>
nostrconnect://83f3b2ae6aa368e8275397b9c26cf550101d63ebaab900d19dd4a4429f5ad8f5?relay=wss%3A%2F%2Frelay1.example.com&perms=nip44_encrypt%2Cnip44_decrypt%2Csign_event%3A13%2Csign_event%3A14%2Csign_event%3A1059&name=My+Client&secret=0s8j2djs&relay=wss%3A%2F%2Frelay2.example2.com
```
_user_ passes this token to _remote-signer_, which then sends `connect` *response* event to the `client-pubkey` via the specified relays. Client discovers `remote-signer-pubkey` from connect response author. `secret` value MUST be provided to avoid connection spoofing, _client_ MUST validate the `secret` returned by `connect` response.
## Request Events `kind: 24133`
@@ -62,12 +72,12 @@ _user_ passes this token to _remote-signer_, which then sends `connect` *respons
{
"kind": 24133,
"pubkey": <local_keypair_pubkey>,
"content": <nip04(<request>)>,
"content": <nip44(<request>)>,
"tags": [["p", <remote-signer-pubkey>]],
}
```
The `content` field is a JSON-RPC-like message that is [NIP-04](04.md) encrypted and has the following structure:
The `content` field is a JSON-RPC-like message that is [NIP-44](44.md) encrypted and has the following structure:
```jsonc
{
@@ -99,7 +109,7 @@ Each of the following are methods that the _client_ sends to the _remote-signer_
### Requested permissions
The `connect` method may be provided with `optional_requested_permissions` for user convenience. The permissions are a comma-separated list of `method[:params]`, i.e. `nip04_encrypt,sign_event:4` meaning permissions to call `nip04_encrypt` and to call `sign_event` with `kind:4`. Optional parameter for `sign_event` is the kind number, parameters for other methods are to be defined later. Same permission format may be used for `perms` field of `metadata` in `nostrconnect://` string.
The `connect` method may be provided with `optional_requested_permissions` for user convenience. The permissions are a comma-separated list of `method[:params]`, i.e. `nip44_encrypt,sign_event:4` meaning permissions to call `nip44_encrypt` and to call `sign_event` with `kind:4`. Optional parameter for `sign_event` is the kind number, parameters for other methods are to be defined later. Same permission format may be used for `perms` field of `metadata` in `nostrconnect://` string.
## Response Events `kind:24133`
@@ -108,13 +118,13 @@ The `connect` method may be provided with `optional_requested_permissions` for u
"id": <id>,
"kind": 24133,
"pubkey": <remote-signer-pubkey>,
"content": <nip04(<response>)>,
"content": <nip44(<response>)>,
"tags": [["p", <client-pubkey>]],
"created_at": <unix timestamp in seconds>
}
```
The `content` field is a JSON-RPC-like message that is [NIP-04](04.md) encrypted and has the following structure:
The `content` field is a JSON-RPC-like message that is [NIP-44](44.md) encrypted and has the following structure:
```json
{
@@ -140,7 +150,7 @@ The `content` field is a JSON-RPC-like message that is [NIP-04](04.md) encrypted
{
"kind": 24133,
"pubkey": "eff37350d839ce3707332348af4549a96051bd695d3223af4aabce4993531d86",
"content": nip04({
"content": nip44({
"id": <random_string>,
"method": "sign_event",
"params": [json_stringified(<{
@@ -160,7 +170,7 @@ The `content` field is a JSON-RPC-like message that is [NIP-04](04.md) encrypted
{
"kind": 24133,
"pubkey": "fa984bd7dbb282f07e16e7ae87b26a2a7b9b90b7246a44771f0cf5ae58018f52",
"content": nip04({
"content": nip44({
"id": <random_string>,
"result": json_stringified(<signed-event>)
}),
@@ -203,7 +213,7 @@ _remote-signer_ MAY publish it's metadata by using [NIP-05](05.md) and [NIP-89](
},
"nip46": {
"relays": ["wss://relay1","wss://relay2"...],
"nostrconnect_url": "https://remote-signer-domain.com/<nostrconnect>"
"nostrconnect_url": "https://remote-signer-domain.example/<nostrconnect>"
}
}
```
@@ -214,4 +224,4 @@ The `<remote-signer-app-pubkey>` MAY be used to verify the domain from _remote-s
_remote-signer_ MAY publish a NIP-89 `kind: 31990` event with `k` tag of `24133`, which MAY also include one or more `relay` tags and MAY include `nostrconnect_url` tag. The semantics of `relay` and `nostrconnect_url` tags are the same as in the section above.
_client_ MAY improve UX by discovering _remote-signers_ using their `kind: 31990` events. _client_ MAY then pre-generate `nostrconnect://` strings for the _remote-signers_, and SHOULD in that case verify that `kind: 31990` event's author is mentioned in signer's `nostr.json?name=_` file as `<remote-signer-app-pubkey>`.
_client_ MAY improve UX by discovering _remote-signers_ using their `kind: 31990` events. _client_ MAY then pre-generate `nostrconnect://` strings for the _remote-signers_, and SHOULD in that case verify that `kind: 31990` event's author is mentioned in signer's `nostr.json?name=_` file as `<remote-signer-app-pubkey>`.

6
47.md
View File

@@ -107,7 +107,7 @@ The content of notifications is encrypted with [NIP04](https://github.com/nostr-
## Nostr Wallet Connect URI
**client** discovers **wallet service** by scanning a QR code, handling a deeplink or pasting in a URI.
The **wallet service** generates this connection URI with protocol `nostr+walletconnect://` and base path it's hex-encoded `pubkey` with the following query string parameters:
The **wallet service** generates this connection URI with protocol `nostr+walletconnect://` and base path its hex-encoded `pubkey` with the following query string parameters:
- `relay` Required. URL of the relay where the **wallet service** is connected and will be listening for events. May be more than one.
- `secret` Required. 32-byte randomly generated hex encoded string. The **client** MUST use this to sign events and encrypt payloads when communicating with the **wallet service**.
@@ -175,7 +175,7 @@ Request:
Response:
For every invoice in the request, a separate response event is sent. To differentiate between the responses, each
response event contains an `d` tag with the id of the invoice it is responding to, if no id was given, then the
response event contains a `d` tag with the id of the invoice it is responding to; if no id was given, then the
payment hash of the invoice should be used.
```jsonc
@@ -247,7 +247,7 @@ Request:
Response:
For every keysend in the request, a separate response event is sent. To differentiate between the responses, each
response event contains an `d` tag with the id of the keysend it is responding to, if no id was given, then the
response event contains a `d` tag with the id of the keysend it is responding to; if no id was given, then the
pubkey should be used.
```jsonc

88
51.md
View File

@@ -14,29 +14,29 @@ When new items are added to an existing list, clients SHOULD append them to the
## Types of lists
## Standard lists
### Standard lists
Standard lists use normal replaceable events, meaning users may only have a single list of each kind. They have special meaning and clients may rely on them to augment a user's profile or browsing experience.
For example, _mute list_ can contain the public keys of spammers and bad actors users don't want to see in their feeds or receive annoying notifications from.
| name | kind | description | expected tag items |
| --- | --- | --- | --- |
| Mute list | 10000 | things the user doesn't want to see in their feeds | `"p"` (pubkeys), `"t"` (hashtags), `"word"` (lowercase string), `"e"` (threads) |
| Pinned notes | 10001 | events the user intends to showcase in their profile page | `"e"` (kind:1 notes) |
| Bookmarks | 10003 | uncategorized, "global" list of things a user wants to save | `"e"` (kind:1 notes), `"a"` (kind:30023 articles), `"t"` (hashtags), `"r"` (URLs) |
| Communities | 10004 | [NIP-72](72.md) communities the user belongs to | `"a"` (kind:34550 community definitions) |
| Public chats | 10005 | [NIP-28](28.md) chat channels the user is in | `"e"` (kind:40 channel definitions) |
| Blocked relays | 10006 | relays clients should never connect to | `"relay"` (relay URLs) |
| Search relays | 10007 | relays clients should use when performing search queries | `"relay"` (relay URLs) |
| Simple groups | 10009 | [NIP-29](29.md) groups the user is in | `"group"` ([NIP-29](29.md) group ids + mandatory relay URL) |
| Interests | 10015 | topics a user may be interested in and pointers | `"t"` (hashtags) and `"a"` (kind:30015 interest set) |
| Emojis | 10030 | user preferred emojis and pointers to emoji sets | `"emoji"` (see [NIP-30](30.md)) and `"a"` (kind:30030 emoji set) |
| DM relays | 10050 | Where to receive [NIP-17](17.md) direct messages | `"relay"` (see [NIP-17](17.md)) |
| Good wiki authors | 10101 | [NIP-54](54.md) user recommended wiki authors | `"p"` (pubkeys) |
| Good wiki relays | 10102 | [NIP-54](54.md) relays deemed to only host useful articles | `"relay"` (relay URLs) |
| name | kind | description | expected tag items |
| --- | --- | --- | --- |
| Mute list | 10000 | things the user doesn't want to see in their feeds | `"p"` (pubkeys), `"t"` (hashtags), `"word"` (lowercase string), `"e"` (threads) |
| Pinned notes | 10001 | events the user intends to showcase in their profile page | `"e"` (kind:1 notes) |
| Bookmarks | 10003 | uncategorized, "global" list of things a user wants to save | `"e"` (kind:1 notes), `"a"` (kind:30023 articles), `"t"` (hashtags), `"r"` (URLs) |
| Communities | 10004 | [NIP-72](72.md) communities the user belongs to | `"a"` (kind:34550 community definitions) |
| Public chats | 10005 | [NIP-28](28.md) chat channels the user is in | `"e"` (kind:40 channel definitions) |
| Blocked relays | 10006 | relays clients should never connect to | `"relay"` (relay URLs) |
| Search relays | 10007 | relays clients should use when performing search queries | `"relay"` (relay URLs) |
| Simple groups | 10009 | [NIP-29](29.md) groups the user is in | `"group"` ([NIP-29](29.md) group id + relay URL + optional group name), `"r"` for each relay in use |
| Interests | 10015 | topics a user may be interested in and pointers | `"t"` (hashtags) and `"a"` (kind:30015 interest set) |
| Emojis | 10030 | user preferred emojis and pointers to emoji sets | `"emoji"` (see [NIP-30](30.md)) and `"a"` (kind:30030 emoji set) |
| DM relays | 10050 | Where to receive [NIP-17](17.md) direct messages | `"relay"` (see [NIP-17](17.md)) |
| Good wiki authors | 10101 | [NIP-54](54.md) user recommended wiki authors | `"p"` (pubkeys) |
| Good wiki relays | 10102 | [NIP-54](54.md) relays deemed to only host useful articles | `"relay"` (relay URLs) |
## Sets
### Sets
Sets are lists with well-defined meaning that can enhance the functionality and the UI of clients that rely on them. Unlike standard lists, users are expected to have more than one set of each kind, therefore each of them must be assigned a different `"d"` identifier.
@@ -44,19 +44,20 @@ For example, _relay sets_ can be displayed in a dropdown UI to give users the op
Aside from their main identifier, the `"d"` tag, sets can optionally have a `"title"`, an `"image"` and a `"description"` tags that can be used to enhance their UI.
| name | kind | description | expected tag items |
| --- | --- | --- | --- |
| Follow sets | 30000 | categorized groups of users a client may choose to check out in different circumstances | `"p"` (pubkeys) |
| Relay sets | 30002 | user-defined relay groups the user can easily pick and choose from during various operations | `"relay"` (relay URLs) |
| Bookmark sets | 30003 | user-defined bookmarks categories , for when bookmarks must be in labeled separate groups | `"e"` (kind:1 notes), `"a"` (kind:30023 articles), `"t"` (hashtags), `"r"` (URLs) |
| Curation sets | 30004 | groups of articles picked by users as interesting and/or belonging to the same category | `"a"` (kind:30023 articles), `"e"` (kind:1 notes) |
| Curation sets | 30005 | groups of videos picked by users as interesting and/or belonging to the same category | `"a"` (kind:34235 videos) |
| Kind mute sets | 30007 | mute pubkeys by kinds<br>`"d"` tag MUST be the kind string | `"p"` (pubkeys) |
| Interest sets | 30015 | interest topics represented by a bunch of "hashtags" | `"t"` (hashtags) |
| Emoji sets | 30030 | categorized emoji groups | `"emoji"` (see [NIP-30](30.md)) |
| Release artifact sets | 30063 | groups of files of a software release | `"e"` (kind:1063 [file metadata](94.md) events), `"i"` (application identifier, typically reverse domain notation), `"version"` |
| name | kind | description | expected tag items |
| --- | --- | --- | --- |
| Follow sets | 30000 | categorized groups of users a client may choose to check out in different circumstances | `"p"` (pubkeys) |
| Relay sets | 30002 | user-defined relay groups the user can easily pick and choose from during various operations | `"relay"` (relay URLs) |
| Bookmark sets | 30003 | user-defined bookmarks categories , for when bookmarks must be in labeled separate groups | `"e"` (kind:1 notes), `"a"` (kind:30023 articles), `"t"` (hashtags), `"r"` (URLs) |
| Curation sets | 30004 | groups of articles picked by users as interesting and/or belonging to the same category | `"a"` (kind:30023 articles), `"e"` (kind:1 notes) |
| Curation sets | 30005 | groups of videos picked by users as interesting and/or belonging to the same category | `"a"` (kind:34235 videos) |
| Kind mute sets | 30007 | mute pubkeys by kinds<br>`"d"` tag MUST be the kind string | `"p"` (pubkeys) |
| Interest sets | 30015 | interest topics represented by a bunch of "hashtags" | `"t"` (hashtags) |
| Emoji sets | 30030 | categorized emoji groups | `"emoji"` (see [NIP-30](30.md)) |
| Release artifact sets | 30063 | group of artifacts of a software release | `"e"` (kind:1063 [file metadata](94.md) events), `"a"` (software application event) |
| App curation sets | 30267 | references to multiple software applications | `"a"` (software application event) |
## Deprecated standard lists
### Deprecated standard lists
Some clients have used these lists in the past, but they should work on transitioning to the [standard formats](#standard-lists) above.
@@ -117,22 +118,39 @@ Some clients have used these lists in the past, but they should work on transiti
"pubkey": "d6dc95542e18b8b7aec2f14610f55c335abebec76f3db9e58c254661d0593a0c",
"created_at": 1695327657,
"kind": 30063,
"content": "Release notes in markdown",
"tags": [
["d", "ak8dy3v7"],
["i", "com.example.app"],
["version", "0.0.1"],
["title", "Example App"],
["image", "http://cdn.site/p/com.example.app/icon.png"],
["d", "com.example.app@0.0.1"],
["e", "d78ba0d5dce22bfff9db0a9e996c9ef27e2c91051de0c4e1da340e0326b4941e"], // Windows exe
["e", "f27e2c91051de0c4e1da0d5dce22bfff9db0a9340e0326b4941ed78bae996c9e"], // MacOS dmg
["e", "9d24ddfab95ba3ff7c03fbd07ad011fff245abea431fb4d3787c2d04aad02332"], // Linux AppImage
["e", "340e0326b340e0326b4941ed78ba340e0326b4941ed78ba340e0326b49ed78ba"] // PWA
["e", "340e0326b340e0326b4941ed78ba340e0326b4941ed78ba340e0326b49ed78ba"], // PWA
["a", "32267:d6dc95542e18b8b7aec2f14610f55c335abebec76f3db9e58c254661d0593a0c:com.example.app"] // Reference to parent software application
],
"content": "Example App is a decentralized marketplace for apps",
"sig": "a9a4e2192eede77e6c9d24ddfab95ba3ff7c03fbd07ad011fff245abea431fb4d3787c2d04aad001cb039cb8de91d83ce30e9a94f82ac3c5a2372aa1294a96bd"
}
```
### An _app curation set_
```jsonc
{
"id": "d8037fa866eb5acd2159960b3ada7284172f7d687b5289cc72a96ca2b431b611",
"pubkey": "78ce6faa72264387284e647ba6938995735ec8c7d5c5a65737e55130f026307d",
"sig": "c1ce0a04521c020ae7485307cd86285530c1f778766a3fd594d662a73e7c28f307d7cd9a9ab642ae749fce62abbabb3a32facfe8d19a21fba551b60fae863d95",
"kind": 30267,
"created_at": 1729302793,
"content": "My nostr app selection",
"tags": [
["d", "nostr"],
["a", "32267:7579076d9aff0a4cfdefa7e2045f2486c7e5d8bc63bfc6b45397233e1bbfcb19:com.example.app1"],
["a", "32267:045f2486c7e5d8bc63bfc6b45397233e1bbfcb197579076d9aff0a4cfdefa7e2:net.example.app2"],
["a", "32267:264387284e647ba6938995735ec8c7d5c5a6f026307d78ce6faa725737e55130:pl.code.app3"]
]
}
```
## Encryption process pseudocode
```scala

2
59.md
View File

@@ -53,7 +53,7 @@ without the receiver's or the sender's private key. The only public information
}
```
Tags MUST must always be empty in a `kind:13`. The inner event MUST always be unsigned.
Tags MUST always be empty in a `kind:13`. The inner event MUST always be unsigned.
## 3. Gift Wrap Event Kind

2
60.md
View File

@@ -54,7 +54,7 @@ Tags:
Any tag, other than the `d` tag, can be [[NIP-44]] encrypted into the `.content` field.
### Deleting a wallet event
Due to PRE being hard to delete, if a user wants to delete a wallet, they should empty the event and keep just the `d` identifier and add a `deleted` tag.
Due to addressable event being hard to delete, if a user wants to delete a wallet, they should empty the event and keep just the `d` identifier and add a `deleted` tag.
## Token Event
Token events are used to record the unspent proofs that come from the mint.

4
61.md
View File

@@ -70,7 +70,7 @@ WIP: Clients SHOULD embed a DLEQ proof in the nutzap event to make it possible t
* The sender fetches the recipient's `kind:10019`.
* The sender mints/swaps ecash on one of the recipient's listed mints.
* The sender p2pk locks to the recipient's specified pubkey in their
* The sender p2pk locks to the recipient's specified pubkey in their `kind:10019`
# Receiving nutzaps
@@ -129,4 +129,4 @@ For this scenarios clients can:
* add a `pubkey` tag to the `kind:10019` (indicating which pubkey senders should P2PK to)
* store the private key in the `kind:37375` event in the nip44-encrypted `content` field.
This is to avoid depending on NIP-07/46 adaptations to sign cashu payloads.
This is to avoid depending on NIP-07/46 adaptations to sign cashu payloads.

92
68.md Normal file
View File

@@ -0,0 +1,92 @@
NIP-68
======
Picture-first feeds
-------------------
`draft` `optional`
This NIP defines event kind `20` for picture-first clients. Images must be self-contained. They are hosted externally and referenced using `imeta` tags.
The idea is for this type of event to cater to Nostr clients resembling platforms like Instagram, Flickr, Snapchat, or 9GAG, where the picture itself takes center stage in the user experience.
## Picture Events
Picture events contain a `title` tag and description in the `.content`.
They may contain multiple images to be displayed as a single post.
```jsonc
{
"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": 20,
"content": "<description of post>",
"tags": [
["title", "<short title of post>"],
// Picture Data
[
"imeta",
"url https://nostr.build/i/my-image.jpg",
"m image/jpeg",
"blurhash eVF$^OI:${M{o#*0-nNFxakD-?xVM}WEWB%iNKxvR-oetmo#R-aen$",
"dim 3024x4032",
"alt A scenic photo overlooking the coast of Costa Rica",
"x <sha256 hash as specified in NIP 94>",
"fallback https://nostrcheck.me/alt1.jpg",
"fallback https://void.cat/alt1.jpg"
],
[
"imeta",
"url https://nostr.build/i/my-image2.jpg",
"m image/jpeg",
"blurhash eVF$^OI:${M{o#*0-nNFxakD-?xVM}WEWB%iNKxvR-oetmo#R-aen$",
"dim 3024x4032",
"alt Another scenic photo overlooking the coast of Costa Rica",
"x <sha256 hash as specified in NIP 94>",
"fallback https://nostrcheck.me/alt2.jpg",
"fallback https://void.cat/alt2.jpg",
"annotate-user <32-bytes hex of a pubkey>:<posX>:<posY>" // Tag users in specific locations in the picture
],
["content-warning", "<reason>"], // if NSFW
// Tagged users
["p", "<32-bytes hex of a pubkey>", "<optional recommended relay URL>"],
["p", "<32-bytes hex of a pubkey>", "<optional recommended relay URL>"],
// Specify the media type for filters to allow clients to filter by supported kinds
["m", "image/jpeg"],
// Hashes of each image to make them queryable
["x", "<sha256>"]
// Hashtags
["t", "<tag>"],
["t", "<tag>"],
// location
["location", "<location>"], // city name, state, country
["g", "<geohash>"],
// When text is written in the image, add the tag to represent the language
["L", "ISO-639-1"],
["l", "en", "ISO-639-1"]
]
}
```
The `imeta` tag `annotate-user` places a user link in the specific position in the image.
Only the following media types are accepted:
- `image/apng`: Animated Portable Network Graphics (APNG)
- `image/avif`: AV1 Image File Format (AVIF)
- `image/gif`: Graphics Interchange Format (GIF)
- `image/jpeg`: Joint Photographic Expert Group image (JPEG)
- `image/png`: Portable Network Graphics (PNG)
- `image/webp`: Web Picture format (WEBP)
Picture events might be used with [NIP-71](71.md)'s kind `34236` to display short vertical videos in the same feed.

90
86.md Normal file
View File

@@ -0,0 +1,90 @@
NIP-86
======
Relay Management API
--------------------
`draft` `optional`
Relays may provide an API for performing management tasks. This is made available as a JSON-RPC-like request-response protocol over HTTP, on the same URI as the relay's websocket.
When a relay receives an HTTP(s) request with a `Content-Type` header of `application/nostr+json+rpc` to a URI supporting WebSocket upgrades, it should parse the request as a JSON document with the following fields:
```json
{
"method": "<method-name>",
"params": ["<array>", "<of>", "<parameters>"]
}
```
Then it should return a response in the format
```json
{
"result": {"<arbitrary>": "<value>"},
"error": "<optional error message, if the call has errored>"
}
```
This is the list of **methods** that may be supported:
* `supportedmethods`:
- params: `[]`
- result: `["<method-name>", "<method-name>", ...]` (an array with the names of all the other supported methods)
* `banpubkey`:
- params: `["<32-byte-hex-public-key>", "<optional-reason>"]`
- result: `true` (a boolean always set to `true`)
* `listbannedpubkeys`:
- params: `[]`
- result: `[{"pubkey": "<32-byte-hex>", "reason": "<optional-reason>"}, ...]`, an array of objects
* `allowpubkey`:
- params: `["<32-byte-hex-public-key>", "<optional-reason>"]`
- result: `true` (a boolean always set to `true`)
* `listallowedpubkeys`:
- params: `[]`
- result: `[{"pubkey": "<32-byte-hex>", "reason": "<optional-reason>"}, ...]`, an array of objects
* `listeventsneedingmoderation`:
- params: `[]`
- result: `[{"id": "<32-byte-hex>", "reason": "<optional-reason>"}]`, an array of objects
* `allowevent`:
- params: `["<32-byte-hex-event-id>", "<optional-reason>"]`
- result: `true` (a boolean always set to `true`)
* `banevent`:
- params: `["<32-byte-hex-event-id>", "<optional-reason>"]`
- result: `true` (a boolean always set to `true`)
* `listbannedevents`:
- params: `[]`
- result: `[{"id": "<32-byte hex>", "reason": "<optional-reason>"}, ...]`, an array of objects
* `changerelayname`:
- params: `["<new-name>"]`
- result: `true` (a boolean always set to `true`)
* `changerelaydescription`:
- params: `["<new-description>"]`
- result: `true` (a boolean always set to `true`)
* `changerelayicon`:
- params: `["<new-icon-url>"]`
- result: `true` (a boolean always set to `true`)
* `allowkind`:
- params: `[<kind-number>]`
- result: `true` (a boolean always set to `true`)
* `disallowkind`:
- params: `[<kind-number>]`
- result: `true` (a boolean always set to `true`)
* `listallowedkinds`:
- params: `[]`
- result: `[<kind-number>, ...]`, an array of numbers
* `blockip`:
- params: `["<ip-address>", "<optional-reason>"]`
- result: `true` (a boolean always set to `true`)
* `unblockip`:
- params: `["<ip-address>"]`
- result: `true` (a boolean always set to `true`)
* `listblockedips`:
- params: `[]`
- result: `[{"ip": "<ip-address>", "reason": "<optional-reason>"}, ...]`, an array of objects
### Authorization
The request must contain an `Authorization` header with a valid [NIP-98](./98.md) event, except the `payload` tag is required. The `u` tag is the relay URL.
If `Authorization` is not provided or is invalid, the endpoint should return a 401 response.

130
88.md Normal file
View File

@@ -0,0 +1,130 @@
# NIP-88
## Polls
`draft` `optional`
This NIP defines the event scheme that describe Polls on nostr.
## Events
### Poll Event
The poll event is defined as a `kind:1068` event.
- **content** key holds the label for the poll.
Major tags in the poll event are:
- **option**: The option tags contain an OptionId(any alphanumeric) field, followed by an option label field.
- **relay**: One or multiple tags that the poll is expecting respondents to respond on.
- **polltype**: can be "singlechoice" or "multiplechoice". Polls that do not have a polltype should be considered a "singlechoice" poll.
- **endsAt**: signifying at which unix timestamp the poll is meant to end.
Example Event
```json
{
"content": "Pineapple on pizza",
"created_at": 1719888496,
"id": "9d1b6b9562e66f2ecf35eb0a3c2decc736c47fddb13d6fb8f87185a153ea3634",
"kind": 1068,
"pubkey": "dee45a23c4f1d93f3a2043650c5081e4ac14a778e0acbef03de3768e4f81ac7b",
"sig": "7fa93bf3c430eaef784b0dacc217d3cd5eff1c520e7ef5d961381bc0f014dde6286618048d924808e54d1be03f2f2c2f0f8b5c9c2082a4480caf45a565ca9797",
"tags": [
["option", "qj518h583", "Yay"],
["option", "gga6cdnqj", "Nay"],
["relay", "<relay url1>"],
["relay", "<relay url2>"],
["polltype", "singlechoice"],
["endsAt", "<unix timestamp in seconds>"]
]
}
```
### Responses
The response event is a `kind:1018` event. It contains an e tag with the poll event it is referencing, followed by one or more response tags.
- **response** : The tag contains "response" as it's first positional argument followed by the option Id selected.
The responses are meant to be published to the relays specified in the poll event.
Example Response Event
```json
{
"content": "",
"created_at": 1720097117,
"id": "60a005e32e9596c3f544a841a9bc4e46d3020ca3650d6a739c95c1568e33f6d8",
"kind": 1018,
"pubkey": "1bc70a0148b3f316da33fe7e89f23e3e71ac4ff998027ec712b905cd24f6a411",
"sig": "30071a633c65db8f3a075c7a8de757fbd8ce65e3607f4ba287fe6d7fbf839a380f94ff4e826fbba593f6faaa13683b7ea9114ade140720ecf4927010ebf3e44f",
"tags": [
["e", "1fc80cf813f1af33d5a435862b7ef7fb96b47e68a48f1abcadf8081f5a545550"],
["response", "gga6cdnqj"],
["response", "m3agjsdq1"]
]
}
```
### Poll Types
The polltype setting dictates how multiple response tags are handled in the `kind:1018` event.
- **polltype: singlechoice**: The first response tag is to be considered the actual response.
- **polltype: multiplechoice**: The first response tag pointing to each id is considered the actual response, without considering the order of the response tags.
### Counting Results
Results can be queried by fetching `kind:1018` events from the relays specified in the poll.
The results displayed should only be 1 vote event per pubkey.
In case of multiple events for a pubkey, the event with the largest timestamp within the poll limits should be considered.
Example for querying polls.
```ts
const fetchVoteEvents = (filterPubkeys: string[]) => {
let resultFilter: Filter = {
"#e": [pollEvent.id],
kinds: [1018],
};
if (filterPubkeys?.length) {
resultFilter.authors = filterPubkeys;
}
if (pollExpiration) {
resultFilter.until = Number(pollExpiration);
}
pool.subscribeMany(relays, [resultFilter], {
onevent: handleResultEvent,
});
};
```
Example for maintaining OneVotePerPubkey
```ts
const oneVotePerPubkey = (events: Event[]) => {
const eventMap = new Map<string, Event>();
events.forEach((event) => {
if (
!eventMap.has(event.pubkey) ||
event.created_at > eventMap.get(event.pubkey)!.created_at
) {
eventMap.set(event.pubkey, event);
}
});
return Array.from(eventMap.values());
};
```
### Relays
It is advisable for poll authors to use relays that do not allow backdated events and do not honor kind:5 (delete) requests for vote events in order to maintain the integrity of poll results after the poll has ended.
### Curation
The clients may configure fetching results by specific people. This can be achieved by creating `kind:30000` follow sets, and fetching results only from the follow set.
Clients can also employ other curation algorithms, like Proof Of Work and Web of Trust scores for result curations.

2
90.md
View File

@@ -185,7 +185,7 @@ Any job feedback event MIGHT include results in the `.content` field, as describ
* Customer publishes a job request (e.g. `kind:5000` speech-to-text).
* Service Providers MAY submit `kind:7000` job-feedback events (e.g. `payment-required`, `processing`, `error`, etc.).
* Upon completion, the service provider publishes the result of the job with a `kind:6000` job-result event.
* At any point, if there is an `amount` pending to be paid as instructed by the service provider, the user can pay the included `bolt11` or zap the job result event the service provider has sent to the user
* At any point, if there is an `amount` pending to be paid as instructed by the service provider, the user can pay the included `bolt11` or zap the job result event the service provider has sent to the user.
Job feedback (`kind:7000`) and Job Results (`kind:6000-6999`) events MAY include an `amount` tag, this can be interpreted as a suggestion to pay. Service Providers MUST use the `payment-required` feedback event to signal that a payment is required and no further actions will be performed until the payment is sent.

6
94.md
View File

@@ -10,12 +10,12 @@ The purpose of this NIP is to allow an organization and classification of shared
## Event format
This NIP specifies the use of the `1063` event type, having in `content` a description of the file content, and a list of tags described below:
This NIP specifies the use of the `1063` event kind, having in `content` a description of the file content, and a list of tags described below:
* `url` the url to download the file
* `m` a string indicating the data type of the file. The [MIME types](https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types/Common_types) format must be used, and they should be lowercase.
* `x` containing the SHA-256 hexencoded string of the file.
* `ox` containing the SHA-256 hexencoded string of the original file, before any transformations done by the upload server
* `ox` (optional) containing the SHA-256 hexencoded string of the original file, before any transformations done by the upload server
* `size` (optional) size of file in bytes
* `dim` (optional) size of file in pixels in the form `<width>x<height>`
* `magnet` (optional) URI to magnet file
@@ -27,6 +27,8 @@ This NIP specifies the use of the `1063` event type, having in `content` a descr
* `alt` (optional) description for accessibility
* `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))
* `duration` (optional) duration of media (video/audio) in seconds
* `bitrate` (optional) average bitrate of media (video/audio) in bits/sec
```jsonc
{

View File

@@ -5,54 +5,57 @@ reverse chronological order.
| Date | Commit | NIP | Change |
| ----------- | --------- | -------- | ------ |
| 2024-10-15 | [1cda2dcc](https://github.com/nostr-protocol/nips/commit/1cda2dcc) | [NIP-71](71.md) | some tags were replaced with `imeta` tag |
| 2024-10-15 | [1cda2dcc](https://github.com/nostr-protocol/nips/commit/1cda2dcc) | [NIP-71](71.md) | `kind: 34237` was dropped |
| 2024-10-07 | [7bb8997b](https://github.com/nostr-protocol/nips/commit/7bb8997b) | [NIP-55](55.md) | some fields and passing data were changed |
| 2024-08-18 | [3aff37bd](https://github.com/nostr-protocol/nips/commit/3aff37bd) | [NIP-54](54.md) | content should be Asciidoc |
| 2024-07-31 | [3ea2f1a4](https://github.com/nostr-protocol/nips/commit/3ea2f1a4) | [NIP-45](45.md) | [444ad28d](https://github.com/nostr-protocol/nips/commit/444ad28d) was reverted |
| 2024-07-30 | [444ad28d](https://github.com/nostr-protocol/nips/commit/444ad28d) | [NIP-45](45.md) | NIP-45 was deprecated |
| 2024-07-26 | [ecee40df](https://github.com/nostr-protocol/nips/commit/ecee40df) | [NIP-19](19.md) | `nrelay` was deprecated |
| 2024-07-23 | [0227a2cd](https://github.com/nostr-protocol/nips/commit/0227a2cd) | [NIP-01](01.md) | events should be sorted by id after created_at |
| 2024-06-06 | [58e94b20](https://github.com/nostr-protocol/nips/commit/58e94b20) | [NIP-25](25.md) | [8073c848](https://github.com/nostr-protocol/nips/commit/8073c848) was reverted |
| 2024-06-06 | [a6dfc7b5](https://github.com/nostr-protocol/nips/commit/a6dfc7b5) | [NIP-55](55.md) | NIP number was changed |
| 2024-05-25 | [5d1d1c17](https://github.com/nostr-protocol/nips/commit/5d1d1c17) | [NIP-71](71.md) | 'aes-256-gcm' tag was removed |
| 2024-05-07 | [8073c848](https://github.com/nostr-protocol/nips/commit/8073c848) | [NIP-25](25.md) | e-tags were changed to not include entire thread |
| 2024-04-30 | [bad88262](https://github.com/nostr-protocol/nips/commit/bad88262) | [NIP-34](34.md) | 'earliest-unique-commit' tag was removed (use 'r' tag instead) |
| 2024-02-25 | [4a171cb0](https://github.com/nostr-protocol/nips/commit/4a171cb0) | [NIP-18](18.md) | quote repost should use `q` tag |
| 2024-02-21 | [c6cd655c](https://github.com/nostr-protocol/nips/commit/c6cd655c) | [NIP-46](46.md) | Params were stringified |
| 2024-02-16 | [cbec02ab](https://github.com/nostr-protocol/nips/commit/cbec02ab) | [NIP-49](49.md) | Password first normalized to NFKC |
| 2024-02-15 | [afbb8dd0](https://github.com/nostr-protocol/nips/commit/afbb8dd0) | [NIP-39](39.md) | PGP identity was removed |
| 2024-02-07 | [d3dad114](https://github.com/nostr-protocol/nips/commit/d3dad114) | [NIP-46](46.md) | Connection token format was changed |
| 2024-01-30 | [1a2b21b6](https://github.com/nostr-protocol/nips/commit/1a2b21b6) | [NIP-59](59.md) | 'p' tag became optional |
| 2023-01-27 | [c2f34817](https://github.com/nostr-protocol/nips/commit/c2f34817) | [NIP-47](47.md) | optional expiration tag should be honored |
| 2024-01-10 | [3d8652ea](https://github.com/nostr-protocol/nips/commit/3d8652ea) | [NIP-02](02.md) | list entries should be chronological |
| 2024-01-10 | [3d8652ea](https://github.com/nostr-protocol/nips/commit/3d8652ea) | [NIP-51](51.md) | list entries should be chronological |
| 2023-12-30 | [29869821](https://github.com/nostr-protocol/nips/commit/29869821) | [NIP-52](52.md) | 'name' tag was removed (use 'title' tag instead) |
| 2023-12-27 | [17c67ef5](https://github.com/nostr-protocol/nips/commit/17c67ef5) | [NIP-94](94.md) | 'aes-256-gcm' tag was removed |
| 2023-12-03 | [0ba45895](https://github.com/nostr-protocol/nips/commit/0ba45895) | [NIP-01](01.md) | WebSocket status code `4000` was replaced by 'CLOSED' message |
| 2023-11-28 | [6de35f9e](https://github.com/nostr-protocol/nips/commit/6de35f9e) | [NIP-89](89.md) | 'client' tag value was changed |
| 2023-11-20 | [7822a8b1](https://github.com/nostr-protocol/nips/commit/7822a8b1) | [NIP-51](51.md) | `kind: 30000` and `kind: 30001` were deprecated |
| 2023-11-11 | [cbdca1e9](https://github.com/nostr-protocol/nips/commit/cbdca1e9) | [NIP-84](84.md) | 'range' tag was removed |
| 2023-11-10 | [c945d8bd](https://github.com/nostr-protocol/nips/commit/c945d8bd) | [NIP-32](32.md) | 'l' tag annotations was removed |
| 2023-11-07 | [108b7f16](https://github.com/nostr-protocol/nips/commit/108b7f16) | [NIP-01](01.md) | 'OK' message must have 4 items |
| 2023-10-17 | [cf672b76](https://github.com/nostr-protocol/nips/commit/cf672b76) | [NIP-03](03.md) | 'block' tag was removed |
| 2023-09-29 | [7dc6385f](https://github.com/nostr-protocol/nips/commit/7dc6385f) | [NIP-57](57.md) | optional 'a' tag was included in `zap receipt` |
| 2023-08-21 | [89915e02](https://github.com/nostr-protocol/nips/commit/89915e02) | [NIP-11](11.md) | 'min_prefix' was removed |
| 2023-08-20 | [37c4375e](https://github.com/nostr-protocol/nips/commit/37c4375e) | [NIP-01](01.md) | replaceable events with same timestamp should be retained event with lowest id |
| 2023-08-15 | [88ee873c](https://github.com/nostr-protocol/nips/commit/88ee873c) | [NIP-15](15.md) | 'countries' tag was renamed to 'regions' |
| 2023-08-14 | [72bb8a12](https://github.com/nostr-protocol/nips/commit/72bb8a12) | [NIP-12](12.md) | NIP-12, 16, 20 and 33 were merged into NIP-01 |
| 2023-08-14 | [72bb8a12](https://github.com/nostr-protocol/nips/commit/72bb8a12) | [NIP-16](16.md) | NIP-12, 16, 20 and 33 were merged into NIP-01 |
| 2023-08-14 | [72bb8a12](https://github.com/nostr-protocol/nips/commit/72bb8a12) | [NIP-20](20.md) | NIP-12, 16, 20 and 33 were merged into NIP-01 |
| 2023-08-14 | [72bb8a12](https://github.com/nostr-protocol/nips/commit/72bb8a12) | [NIP-33](33.md) | NIP-12, 16, 20 and 33 were merged into NIP-01 |
| 2023-08-11 | [d87f8617](https://github.com/nostr-protocol/nips/commit/d87f8617) | [NIP-25](25.md) | empty `content` should be considered as "+" |
| 2023-08-01 | [5d63b157](https://github.com/nostr-protocol/nips/commit/5d63b157) | [NIP-57](57.md) | 'zap' tag was changed |
| 2023-07-15 | [d1814405](https://github.com/nostr-protocol/nips/commit/d1814405) | [NIP-01](01.md) | `since` and `until` filters should be `since <= created_at <= until` |
| 2023-07-12 | [a1cd2bd8](https://github.com/nostr-protocol/nips/commit/a1cd2bd8) | [NIP-25](25.md) | custom emoji was supported |
| 2023-06-18 | [83cbd3e1](https://github.com/nostr-protocol/nips/commit/83cbd3e1) | [NIP-11](11.md) | 'image' was renamed to 'icon' |
| 2023-04-13 | [bf0a0da6](https://github.com/nostr-protocol/nips/commit/bf0a0da6) | [NIP-15](15.md) | different NIP was re-added as NIP-15 |
| 2023-04-09 | [fb5b7c73](https://github.com/nostr-protocol/nips/commit/fb5b7c73) | [NIP-15](15.md) | NIP-15 was merged into NIP-01 |
| 2023-03-29 | [599e1313](https://github.com/nostr-protocol/nips/commit/599e1313) | [NIP-18](18.md) | NIP-18 was bring back |
| 2023-03-15 | [e1004d3d](https://github.com/nostr-protocol/nips/commit/e1004d3d) | [NIP-19](19.md) | `1: relay` was changed to optionally |
| 2024-12-05 | [6d16019e](https://github.com/nostr-protocol/nips/commit/6d16019e) | [46](46.md) | message encryption was changed to NIP-44 |
| 2024-11-12 | [2838e3bd](https://github.com/nostr-protocol/nips/commit/2838e3bd) | [29](29.md) | `kind: 12` and `kind: 10` were removed (use `kind: 1111` instead) |
| 2024-11-12 | [926a51e7](https://github.com/nostr-protocol/nips/commit/926a51e7) | [46](46.md) | NIP-05 login was removed |
| 2024-11-12 | [926a51e7](https://github.com/nostr-protocol/nips/commit/926a51e7) | [46](46.md) | `create_account` method was removed |
| 2024-11-12 | [926a51e7](https://github.com/nostr-protocol/nips/commit/926a51e7) | [46](46.md) | `connect` params and result were changed |
| 2024-10-29 | [f1e8d2c4](https://github.com/nostr-protocol/nips/commit/f1e8d2c4) | [46](46.md) | bunker URL should use `remote-signer-key` |
| 2024-10-15 | [1cda2dcc](https://github.com/nostr-protocol/nips/commit/1cda2dcc) | [71](71.md) | some tags were replaced with `imeta` tag |
| 2024-10-15 | [1cda2dcc](https://github.com/nostr-protocol/nips/commit/1cda2dcc) | [71](71.md) | `kind: 34237` was dropped |
| 2024-10-07 | [7bb8997b](https://github.com/nostr-protocol/nips/commit/7bb8997b) | [55](55.md) | some fields and passing data were changed |
| 2024-08-18 | [3aff37bd](https://github.com/nostr-protocol/nips/commit/3aff37bd) | [54](54.md) | content should be Asciidoc |
| 2024-07-31 | [3ea2f1a4](https://github.com/nostr-protocol/nips/commit/3ea2f1a4) | [45](45.md) | [444ad28d](https://github.com/nostr-protocol/nips/commit/444ad28d) was reverted |
| 2024-07-30 | [444ad28d](https://github.com/nostr-protocol/nips/commit/444ad28d) | [45](45.md) | NIP-45 was deprecated |
| 2024-07-26 | [ecee40df](https://github.com/nostr-protocol/nips/commit/ecee40df) | [19](19.md) | `nrelay` was deprecated |
| 2024-07-23 | [0227a2cd](https://github.com/nostr-protocol/nips/commit/0227a2cd) | [01](01.md) | events should be sorted by id after created_at |
| 2024-06-06 | [58e94b20](https://github.com/nostr-protocol/nips/commit/58e94b20) | [25](25.md) | [8073c848](https://github.com/nostr-protocol/nips/commit/8073c848) was reverted |
| 2024-06-06 | [a6dfc7b5](https://github.com/nostr-protocol/nips/commit/a6dfc7b5) | [55](55.md) | NIP number was changed |
| 2024-05-25 | [5d1d1c17](https://github.com/nostr-protocol/nips/commit/5d1d1c17) | [71](71.md) | `aes-256-gcm` tag was removed |
| 2024-05-07 | [8073c848](https://github.com/nostr-protocol/nips/commit/8073c848) | [25](25.md) | e-tags were changed to not include entire thread |
| 2024-04-30 | [bad88262](https://github.com/nostr-protocol/nips/commit/bad88262) | [34](34.md) | `earliest-unique-commit` tag was removed (use `r` tag instead) |
| 2024-02-25 | [4a171cb0](https://github.com/nostr-protocol/nips/commit/4a171cb0) | [18](18.md) | quote repost should use `q` tag |
| 2024-02-21 | [c6cd655c](https://github.com/nostr-protocol/nips/commit/c6cd655c) | [46](46.md) | Params were stringified |
| 2024-02-16 | [cbec02ab](https://github.com/nostr-protocol/nips/commit/cbec02ab) | [49](49.md) | Password first normalized to NFKC |
| 2024-02-15 | [afbb8dd0](https://github.com/nostr-protocol/nips/commit/afbb8dd0) | [39](39.md) | PGP identity was removed |
| 2024-02-07 | [d3dad114](https://github.com/nostr-protocol/nips/commit/d3dad114) | [46](46.md) | Connection token format was changed |
| 2024-01-30 | [1a2b21b6](https://github.com/nostr-protocol/nips/commit/1a2b21b6) | [59](59.md) | `p` tag became optional |
| 2023-01-27 | [c2f34817](https://github.com/nostr-protocol/nips/commit/c2f34817) | [47](47.md) | optional expiration tag should be honored |
| 2024-01-10 | [3d8652ea](https://github.com/nostr-protocol/nips/commit/3d8652ea) | [02](02.md), [51](51.md) | list entries should be chronological |
| 2023-12-30 | [29869821](https://github.com/nostr-protocol/nips/commit/29869821) | [52](52.md) | `name` tag was removed (use `title` tag instead) |
| 2023-12-27 | [17c67ef5](https://github.com/nostr-protocol/nips/commit/17c67ef5) | [94](94.md) | `aes-256-gcm` tag was removed |
| 2023-12-03 | [0ba45895](https://github.com/nostr-protocol/nips/commit/0ba45895) | [01](01.md) | WebSocket status code `4000` was replaced by `CLOSED` message |
| 2023-11-28 | [6de35f9e](https://github.com/nostr-protocol/nips/commit/6de35f9e) | [89](89.md) | `client` tag value was changed |
| 2023-11-20 | [7822a8b1](https://github.com/nostr-protocol/nips/commit/7822a8b1) | [51](51.md) | `kind: 30001` was deprecated |
| 2023-11-20 | [7822a8b1](https://github.com/nostr-protocol/nips/commit/7822a8b1) | [51](51.md) | the meaning of `kind: 30000` was changed |
| 2023-11-11 | [cbdca1e9](https://github.com/nostr-protocol/nips/commit/cbdca1e9) | [84](84.md) | `range` tag was removed |
| 2023-11-10 | [c945d8bd](https://github.com/nostr-protocol/nips/commit/c945d8bd) | [32](32.md) | `l` tag annotations was removed |
| 2023-11-07 | [108b7f16](https://github.com/nostr-protocol/nips/commit/108b7f16) | [01](01.md) | `OK` message must have 4 items |
| 2023-10-17 | [cf672b76](https://github.com/nostr-protocol/nips/commit/cf672b76) | [03](03.md) | `block` tag was removed |
| 2023-09-29 | [7dc6385f](https://github.com/nostr-protocol/nips/commit/7dc6385f) | [57](57.md) | optional `a` tag was included in `zap receipt` |
| 2023-08-21 | [89915e02](https://github.com/nostr-protocol/nips/commit/89915e02) | [11](11.md) | `min_prefix` was removed |
| 2023-08-20 | [37c4375e](https://github.com/nostr-protocol/nips/commit/37c4375e) | [01](01.md) | replaceable events with same timestamp should be retained event with lowest id |
| 2023-08-15 | [88ee873c](https://github.com/nostr-protocol/nips/commit/88ee873c) | [15](15.md) | `countries` tag was renamed to `regions` |
| 2023-08-14 | [72bb8a12](https://github.com/nostr-protocol/nips/commit/72bb8a12) | [12](12.md), [16](16.md), [20](20.md), [33](33.md) | NIP-12, 16, 20 and 33 were merged into NIP-01 |
| 2023-08-11 | [d87f8617](https://github.com/nostr-protocol/nips/commit/d87f8617) | [25](25.md) | empty `content` should be considered as "+" |
| 2023-08-01 | [5d63b157](https://github.com/nostr-protocol/nips/commit/5d63b157) | [57](57.md) | `zap` tag was changed |
| 2023-07-15 | [d1814405](https://github.com/nostr-protocol/nips/commit/d1814405) | [01](01.md) | `since` and `until` filters should be `since <= created_at <= until` |
| 2023-07-12 | [a1cd2bd8](https://github.com/nostr-protocol/nips/commit/a1cd2bd8) | [25](25.md) | custom emoji was supported |
| 2023-06-18 | [83cbd3e1](https://github.com/nostr-protocol/nips/commit/83cbd3e1) | [11](11.md) | `image` was renamed to `icon` |
| 2023-04-13 | [bf0a0da6](https://github.com/nostr-protocol/nips/commit/bf0a0da6) | [15](15.md) | different NIP was re-added as NIP-15 |
| 2023-04-09 | [fb5b7c73](https://github.com/nostr-protocol/nips/commit/fb5b7c73) | [15](15.md) | NIP-15 was merged into NIP-01 |
| 2023-03-29 | [599e1313](https://github.com/nostr-protocol/nips/commit/599e1313) | [18](18.md) | NIP-18 was bring back |
| 2023-03-15 | [e1004d3d](https://github.com/nostr-protocol/nips/commit/e1004d3d) | [19](19.md) | `1: relay` was changed to optionally |
Breaking changes prior to 2023-03-01 are not yet documented.
@@ -60,4 +63,3 @@ Breaking changes prior to 2023-03-01 are not yet documented.
- If it isn't clear that a change is breaking or not, we list it.
- The date is the date it was merged, not necessarily the date of the commit.

View File

@@ -31,7 +31,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
- [NIP-07: `window.nostr` capability for web browsers](07.md)
- [NIP-08: Handling Mentions](08.md) --- **unrecommended**: deprecated in favor of [NIP-27](27.md)
- [NIP-09: Event Deletion Request](09.md)
- [NIP-10: Conventions for clients' use of `e` and `p` tags in text events](10.md)
- [NIP-10: Text Notes and Threads](10.md)
- [NIP-11: Relay Information Document](11.md)
- [NIP-13: Proof of Work](13.md)
- [NIP-14: Subject tag in text events](14.md)
@@ -54,14 +54,15 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
- [NIP-34: `git` stuff](34.md)
- [NIP-35: Torrents](35.md)
- [NIP-36: Sensitive Content](36.md)
- [NIP-37: Draft Events](37.md)
- [NIP-38: User Statuses](38.md)
- [NIP-39: External Identities in Profiles](39.md)
- [NIP-40: Expiration Timestamp](40.md)
- [NIP-42: Authentication of clients to relays](42.md)
- [NIP-44: Versioned Encryption](44.md)
- [NIP-44: Encrypted Payloads (Versioned)](44.md)
- [NIP-45: Counting results](45.md)
- [NIP-46: Nostr Connect](46.md)
- [NIP-47: Wallet Connect](47.md)
- [NIP-46: Nostr Remote Signing](46.md)
- [NIP-47: Nostr Wallet Connect](47.md)
- [NIP-48: Proxy Tags](48.md)
- [NIP-49: Private Key Encryption](49.md)
- [NIP-50: Search Capability](50.md)
@@ -78,6 +79,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
- [NIP-61: Nutzaps](61.md)
- [NIP-64: Chess (PGN)](64.md)
- [NIP-65: Relay List Metadata](65.md)
- [NIP-68: Picture-first feeds](68.md)
- [NIP-69: Peer-to-peer Order events](69.md)
- [NIP-70: Protected Events](70.md)
- [NIP-71: Video Events](71.md)
@@ -86,6 +88,8 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
- [NIP-75: Zap Goals](75.md)
- [NIP-78: Application-specific data](78.md)
- [NIP-84: Highlights](84.md)
- [NIP-86: Relay Management API](86.md)
- [NIP-88: Polls](88.md)
- [NIP-89: Recommended Application Handlers](89.md)
- [NIP-90: Data Vending Machines](90.md)
- [NIP-92: Media Attachments](92.md)
@@ -93,13 +97,15 @@ 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-C7: Chats](C7.md)
## Event Kinds
| kind | description | NIP |
| ------------- | ------------------------------- | -------------------------------------- |
| `0` | User Metadata | [01](01.md) |
| `1` | Short Text Note | [01](01.md) |
| `1` | Short Text Note | [10](10.md) |
| `2` | Recommend Relay | 01 (deprecated) |
| `3` | Follows | [02](02.md) |
| `4` | Encrypted Direct Messages | [04](04.md) |
@@ -107,14 +113,15 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
| `6` | Repost | [18](18.md) |
| `7` | Reaction | [25](25.md) |
| `8` | Badge Award | [58](58.md) |
| `9` | Group Chat Message | [29](29.md) |
| `9` | Chat Message | [C7](C7.md) |
| `10` | Group Chat Threaded Reply | 29 (deprecated) |
| `11` | Group Thread | [29](29.md) |
| `11` | Thread | [7D](7D.md) |
| `12` | Group Thread Reply | 29 (deprecated) |
| `13` | Seal | [59](59.md) |
| `14` | Direct Message | [17](17.md) |
| `16` | Generic Repost | [18](18.md) |
| `17` | Reaction to a website | [25](25.md) |
| `20` | Picture | [68](68.md) |
| `40` | Channel Creation | [28](28.md) |
| `41` | Channel Metadata | [28](28.md) |
| `42` | Channel Message | [28](28.md) |
@@ -122,11 +129,13 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
| `44` | Channel Mute User | [28](28.md) |
| `64` | Chess (PGN) | [64](64.md) |
| `818` | Merge Requests | [54](54.md) |
| `1018` | Poll Response | [88](88.md) |
| `1021` | Bid | [15](15.md) |
| `1022` | Bid confirmation | [15](15.md) |
| `1040` | OpenTimestamps | [03](03.md) |
| `1059` | Gift Wrap | [59](59.md) |
| `1063` | File Metadata | [94](94.md) |
| `1068` | Poll | [88](88.md) |
| `1111` | Comment | [22](22.md) |
| `1311` | Live Chat Message | [53](53.md) |
| `1617` | Patches | [34](34.md) |
@@ -164,6 +173,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
| `10006` | Blocked relays list | [51](51.md) |
| `10007` | Search relays list | [51](51.md) |
| `10009` | User groups | [51](51.md), [29](29.md) |
| `10013` | Draft relays | [37](37.md) |
| `10015` | Interests list | [51](51.md) |
| `10019` | Nutzap Mint Recommendation | [61](61.md) |
| `10030` | User emoji list | [51](51.md) |
@@ -179,7 +189,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
| `24242` | Blobs stored on mediaservers | [Blossom][blossom] |
| `27235` | HTTP Auth | [98](98.md) |
| `30000` | Follow sets | [51](51.md) |
| `30001` | Generic lists | [51](51.md) |
| `30001` | Generic lists | 51 (deprecated) |
| `30002` | Relay sets | [51](51.md) |
| `30003` | Bookmark sets | [51](51.md) |
| `30004` | Curation sets | [51](51.md) |
@@ -199,6 +209,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
| `30041` | Modular Article Content | [NKBIP-01] |
| `30063` | Release artifact sets | [51](51.md) |
| `30078` | Application-specific Data | [78](78.md) |
| `30267` | App curation sets | [51](51.md) |
| `30311` | Live Event | [53](53.md) |
| `30315` | User Statuses | [38](38.md) |
| `30388` | Slide Set | [Corny Chat][cornychat-slideset] |
@@ -208,6 +219,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
| `30618` | Repository state announcements | [34](34.md) |
| `30818` | Wiki article | [54](54.md) |
| `30819` | Redirects | [54](54.md) |
| `31234` | Draft Event | [37](37.md) |
| `31388` | Link Set | [Corny Chat][cornychat-linkset] |
| `31890` | Feed | [NUD: Custom Feeds][NUD: Custom Feeds] |
| `31922` | Date-Based Calendar Event | [52](52.md) |
@@ -216,6 +228,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
| `31925` | Calendar Event RSVP | [52](52.md) |
| `31989` | Handler recommendation | [89](89.md) |
| `31990` | Handler information | [89](89.md) |
| `32267` | Software Application | |
| `34235` | Video Event | [71](71.md) |
| `34236` | Short-form Portrait Video Event | [71](71.md) |
| `34550` | Community Definition | [72](72.md) |
@@ -277,7 +290,8 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
| `l` | label, label namespace | -- | [32](32.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) |
| `p` | pubkey (hex) | relay URL, petname | [01](01.md), [02](02.md), [22](22.md) |
| `P` | pubkey (hex) | -- | [22](22.md), [57](57.md) |
| `q` | event id (hex) | relay URL, pubkey (hex) | [18](18.md) |
| `r` | a reference (URL, etc) | -- | [24](24.md), [25](25.md) |
| `r` | relay url | marker | [65](65.md) |
@@ -335,9 +349,9 @@ Please update these lists when proposing new NIPs.
## Is this repository a centralizing factor?
To promote interoperability, we standards that everybody can follow, and we need them to define a **single way of doing each thing** without ever hurting **backwards-compatibility**, and for that purpose there is no way around getting everybody to agree on the same thing and keep a centralized index of these standards. However the fact that such index exists doesn't hurt the decentralization of Nostr. _At any point the central index can be challenged if it is failing to fulfill the needs of the protocol_ and it can migrate to other places and be maintained by other people.
To promote interoperability, we need standards that everybody can follow, and we need them to define a **single way of doing each thing** without ever hurting **backwards-compatibility**, and for that purpose there is no way around getting everybody to agree on the same thing and keep a centralized index of these standards. However the fact that such an index exists doesn't hurt the decentralization of Nostr. _At any point the central index can be challenged if it is failing to fulfill the needs of the protocol_ and it can migrate to other places and be maintained by other people.
It can even fork into multiple and then some clients would go one way, others would go another way, and some clients would adhere to both competing standards. This would hurt the simplicity, openness and interoperability of Nostr a little, but everything would still work in the short term.
It can even fork into multiple versions, and then some clients would go one way, others would go another way, and some clients would adhere to both competing standards. This would hurt the simplicity, openness and interoperability of Nostr a little, but everything would still work in the short term.
There is a list of notable Nostr software developers who have commit access to this repository, but that exists mostly for practical reasons, as by the nature of the thing we're dealing with the repository owner can revoke membership and rewrite history as they want -- and if these actions are unjustified or perceived as bad or evil the community must react.