upleb.uk

Public git repos — served from a NIP-34 GRASP relay at git.upleb.uk

summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorOscar Merry <MerryOscar@users.noreply.github.com>2024-06-17 13:38:45 +0100
committerGitHub <noreply@github.com>2024-06-17 13:38:45 +0100
commit45351b561dcc15b9d3c09b64967a5e30a80ddabe (patch)
treee3bb8995aed591b519d042909eddd7d983bbe56e
parent32004283da0f0893d7b697c9a0b1a1f8611e9929 (diff)
parentc576737ba42772a561c6ebfd9faf0baae6d19b17 (diff)
Merge branch 'nostr-protocol:master' into external-content-ids
Diffstat
-rw-r--r--01.md20
-rw-r--r--02.md4
-rw-r--r--09.md2
-rw-r--r--10.md4
-rw-r--r--13.md2
-rw-r--r--24.md2
-rw-r--r--25.md20
-rw-r--r--32.md10
-rw-r--r--35.md70
-rw-r--r--38.md4
-rw-r--r--50.md2
-rw-r--r--53.md2
-rw-r--r--54.md5
-rw-r--r--55.md538
-rw-r--r--57.md2
-rw-r--r--71.md118
-rw-r--r--96.md126
-rw-r--r--BREAKING.md12
-rw-r--r--README.md115
19 files changed, 928 insertions, 130 deletions
diff --git a/01.md b/01.md
index 8be85bc..aa7fda2 100644
--- a/01.md
+++ b/01.md
@@ -43,16 +43,16 @@ To obtain the `event.id`, we `sha256` the serialized event. The serialization is
43``` 43```
44 44
45To prevent implementation differences from creating a different event ID for the same event, the following rules MUST be followed while serializing: 45To prevent implementation differences from creating a different event ID for the same event, the following rules MUST be followed while serializing:
46- No whitespace, line breaks or other unnecessary formatting should be included in the output JSON.
47- No characters except the following should be escaped, and instead should be included verbatim:
48 - A line break, `0x0A`, as `\n`
49 - A double quote, `0x22`, as `\"`
50 - A backslash, `0x5C`, as `\\`
51 - A carriage return, `0x0D`, as `\r`
52 - A tab character, `0x09`, as `\t`
53 - A backspace, `0x08`, as `\b`
54 - A form feed, `0x0C`, as `\f`
55- UTF-8 should be used for encoding. 46- UTF-8 should be used for encoding.
47- Whitespace, line breaks or other unnecessary formatting should not be included in the output JSON.
48- The following characters in the content field must be escaped as shown, and all other characters must be included verbatim:
49 - A line break (`0x0A`), use `\n`
50 - A double quote (`0x22`), use `\"`
51 - A backslash (`0x5C`), use `\\`
52 - A carriage return (`0x0D`), use `\r`
53 - A tab character (`0x09`), use `\t`
54 - A backspace, (`0x08`), use `\b`
55 - A form feed, (`0x0C`), use `\f`
56 56
57### Tags 57### Tags
58 58
@@ -87,7 +87,7 @@ As a convention, all single-letter (only english alphabet letters: a-z, A-Z) key
87 87
88Kinds 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: 88Kinds 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:
89 89
90- `0`: **metadata**: the `content` is set to a stringified JSON object `{name: <username>, about: <string>, picture: <url, string>}` describing the user who created the event. A relay may delete older events once it gets a new one for the same pubkey. 90- `0`: **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.
91- `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. 91- `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.
92 92
93And also a convention for kind ranges that allow for easier experimentation and flexibility of relay implementation: 93And also a convention for kind ranges that allow for easier experimentation and flexibility of relay implementation:
diff --git a/02.md b/02.md
index 8b0aee1..4029b22 100644
--- a/02.md
+++ b/02.md
@@ -8,7 +8,9 @@ Follow List
8 8
9A special event with kind `3`, meaning "follow list" is defined as having a list of `p` tags, one for each of the followed/known profiles one is following. 9A special event with kind `3`, meaning "follow list" is defined as having a list of `p` tags, one for each of the followed/known profiles one is following.
10 10
11Each tag entry should contain the key for the profile, a relay URL where events from that key can be found (can be set to an empty string if not needed), and a local name (or "petname") for that profile (can also be set to an empty string or not provided), i.e., `["p", <32-bytes hex key>, <main relay URL>, <petname>]`. The `content` can be anything and should be ignored. 11Each tag entry should contain the key for the profile, a relay URL where events from that key can be found (can be set to an empty string if not needed), and a local name (or "petname") for that profile (can also be set to an empty string or not provided), i.e., `["p", <32-bytes hex key>, <main relay URL>, <petname>]`.
12
13The `.content` is not used.
12 14
13For example: 15For example:
14 16
diff --git a/09.md b/09.md
index fbbd6e1..5e79ac2 100644
--- a/09.md
+++ b/09.md
@@ -32,6 +32,8 @@ Relays SHOULD delete or stop publishing any referenced events that have an ident
32 32
33Relays SHOULD continue to publish/share the deletion events indefinitely, as clients may already have the event that's intended to be deleted. Additionally, clients SHOULD broadcast deletion events to other relays which don't have it. 33Relays SHOULD continue to publish/share the deletion events indefinitely, as clients may already have the event that's intended to be deleted. Additionally, clients SHOULD broadcast deletion events to other relays which don't have it.
34 34
35When an `a` tag is used, relays SHOULD delete all versions of the replaceable event up to the `created_at` timestamp of the deletion event.
36
35## Client Usage 37## Client Usage
36 38
37Clients MAY choose to fully hide any events that are referenced by valid deletion events. This includes text notes, direct messages, or other yet-to-be defined event kinds. Alternatively, they MAY show the event along with an icon or other indication that the author has "disowned" the event. The `content` field MAY also be used to replace the deleted events' own content, although a user interface should clearly indicate that this is a deletion reason, not the original content. 39Clients MAY choose to fully hide any events that are referenced by valid deletion events. This includes text notes, direct messages, or other yet-to-be defined event kinds. Alternatively, they MAY show the event along with an icon or other indication that the author has "disowned" the event. The `content` field MAY also be used to replace the deleted events' own content, although a user interface should clearly indicate that this is a deletion reason, not the original content.
diff --git a/10.md b/10.md
index a434ea0..dfd4cb9 100644
--- a/10.md
+++ b/10.md
@@ -38,13 +38,14 @@ They are citing from this event. `root-id` and `reply-id` are as above.
38>This scheme is deprecated because it creates ambiguities that are difficult, or impossible to resolve when an event references another but is not a reply. 38>This scheme is deprecated because it creates ambiguities that are difficult, or impossible to resolve when an event references another but is not a reply.
39 39
40## Marked "e" tags (PREFERRED) 40## Marked "e" tags (PREFERRED)
41`["e", <event-id>, <relay-url>, <marker>]` 41`["e", <event-id>, <relay-url>, <marker>, <pubkey>]`
42 42
43Where: 43Where:
44 44
45 * `<event-id>` is the id of the event being referenced. 45 * `<event-id>` is the id of the event being referenced.
46 * `<relay-url>` is the URL of a recommended relay associated with the reference. Clients SHOULD add a valid `<relay-URL>` field, but may instead leave it as `""`. 46 * `<relay-url>` is the URL of a recommended relay associated with the reference. Clients SHOULD add a valid `<relay-URL>` field, but may instead leave it as `""`.
47 * `<marker>` is optional and if present is one of `"reply"`, `"root"`, or `"mention"`. 47 * `<marker>` is optional and if present is one of `"reply"`, `"root"`, or `"mention"`.
48 * `<pubkey>` is optional, SHOULD be the pubkey of the author of the referenced event
48 49
49Those marked with `"reply"` denote the id of the reply event being responded to. Those marked with `"root"` denote the root id of the reply thread being responded to. For top level replies (those replying directly to the root event), only the `"root"` marker should be used. Those marked with `"mention"` denote a quoted or reposted event id. 50Those marked with `"reply"` denote the id of the reply event being responded to. Those marked with `"root"` denote the root id of the reply thread being responded to. For top level replies (those replying directly to the root event), only the `"root"` marker should be used. Those marked with `"mention"` denote a quoted or reposted event id.
50 51
@@ -52,6 +53,7 @@ A direct reply to the root of a thread should have a single marked "e" tag of ty
52 53
53>This scheme is preferred because it allows events to mention others without confusing them with `<reply-id>` or `<root-id>`. 54>This scheme is preferred because it allows events to mention others without confusing them with `<reply-id>` or `<root-id>`.
54 55
56`<pubkey>` SHOULD be the pubkey of the author of the `e` tagged event, this is used in the outbox model to search for that event from the authors write relays where relay hints did not resolve the event.
55 57
56## The "p" tag 58## The "p" tag
57Used in a text event contains a list of pubkeys used to record who is involved in a reply thread. 59Used in a text event contains a list of pubkeys used to record who is involved in a reply thread.
diff --git a/13.md b/13.md
index 53c4d1b..99289c2 100644
--- a/13.md
+++ b/13.md
@@ -35,7 +35,7 @@ Example mined note
35 "created_at": 1651794653, 35 "created_at": 1651794653,
36 "kind": 1, 36 "kind": 1,
37 "tags": [ 37 "tags": [
38 ["nonce", "776797", "21"] 38 ["nonce", "776797", "20"]
39 ], 39 ],
40 "content": "It's just me mining my own business", 40 "content": "It's just me mining my own business",
41 "sig": "284622fc0a3f4f1303455d5175f7ba962a3300d136085b9566801bc2e0699de0c7e31e44c81fb40ad9049173742e904713c3594a1da0fc5d2382a25c11aba977" 41 "sig": "284622fc0a3f4f1303455d5175f7ba962a3300d136085b9566801bc2e0699de0c7e31e44c81fb40ad9049173742e904713c3594a1da0fc5d2382a25c11aba977"
diff --git a/24.md b/24.md
index 99fcedf..8710af6 100644
--- a/24.md
+++ b/24.md
@@ -28,7 +28,7 @@ These are fields that should be ignored or removed when found in the wild:
28kind 3 28kind 3
29====== 29======
30 30
31These are extra fields not specified in NIP-02 that may be present in the stringified JSON of contacts events: 31These are extra fields not specified in NIP-02 that may be present in the stringified JSON of follow events:
32 32
33### Deprecated fields 33### Deprecated fields
34 34
diff --git a/25.md b/25.md
index 7cc96b5..17c203e 100644
--- a/25.md
+++ b/25.md
@@ -25,24 +25,23 @@ consider it a "+".
25Tags 25Tags
26---- 26----
27 27
28The reaction event SHOULD include `a`, `e` and `p` tags pointing to the note the user is 28The reaction event SHOULD include `e` and `p` tags from the note the user is reacting to (and optionally `a` tags if the target is a replaceable event). This allows users to be notified of reactions to posts they were mentioned in. Including the `e` tags enables clients to pull all the reactions associated with individual posts or all the posts in a thread. `a` tags enables clients to seek reactions for all versions of a replaceable event.
29reacting to. The `p` tag allows authors to be notified. The `e` tags enables clients
30to pull all the reactions to individual events and `a` tags enables clients to seek reactions
31for all versions of a replaceable event.
32 29
33The `e` tag MUST be the `id` of the note that is being reacted to. 30The last `e` tag MUST be the `id` of the note that is being reacted to.
34 31
35The `a` tag MUST contain the coordinates (`kind:pubkey:d-tag`) of the replaceable being reacted to. 32The last `p` tag MUST be the `pubkey` of the event being reacted to.
36 33
37The `p` tag MUST be the `pubkey` of the event being reacted to. 34The `a` tag MUST contain the coordinates (`kind:pubkey:d-tag`) of the replaceable being reacted to.
38 35
39The reaction event MAY include a `k` tag with the stringified kind number 36The reaction event MAY include a `k` tag with the stringified kind number of the reacted event as its value.
40of the reacted event as its value.
41 37
42Example code 38Example code
43 39
44```swift 40```swift
45func make_like_event(pubkey: String, privkey: String, liked: NostrEvent) -> NostrEvent { 41func make_like_event(pubkey: String, privkey: String, liked: NostrEvent) -> NostrEvent {
42 var tags: [[String]] = liked.tags.filter {
43 tag in tag.count >= 2 && (tag[0] == "e" || tag[0] == "p")
44 }
46 tags.append(["e", liked.id]) 45 tags.append(["e", liked.id])
47 tags.append(["p", liked.pubkey]) 46 tags.append(["p", liked.pubkey])
48 tags.append(["k", liked.kind]) 47 tags.append(["k", liked.kind])
@@ -67,8 +66,7 @@ content as an emoji if shortcode is specified.
67 "tags": [ 66 "tags": [
68 ["emoji", "soapbox", "https://gleasonator.com/emoji/Gleasonator/soapbox.png"] 67 ["emoji", "soapbox", "https://gleasonator.com/emoji/Gleasonator/soapbox.png"]
69 ], 68 ],
70 "pubkey": "79c2cae114ea28a981e7559b4fe7854a473521a8d22a66bbab9fa248eb820ff6", 69 ...other fields
71 "created_at": 1682790000
72} 70}
73``` 71```
74 72
diff --git a/32.md b/32.md
index 92497a6..79f5937 100644
--- a/32.md
+++ b/32.md
@@ -20,7 +20,7 @@ Label Namespace Tag
20An `L` tag can be any string, but publishers SHOULD ensure they are unambiguous by using a well-defined namespace 20An `L` tag can be any string, but publishers SHOULD ensure they are unambiguous by using a well-defined namespace
21(such as an ISO standard) or reverse domain name notation. 21(such as an ISO standard) or reverse domain name notation.
22 22
23`L` tags are REQUIRED in order to support searching by namespace rather than by a specific tag. The special `ugc` 23`L` tags are RECOMMENDED in order to support searching by namespace rather than by a specific tag. The special `ugc`
24("user generated content") namespace MAY be used when the label content is provided by an end user. 24("user generated content") namespace MAY be used when the label content is provided by an end user.
25 25
26`L` tags starting with `#` indicate that the label target should be associated with the label's value. 26`L` tags starting with `#` indicate that the label target should be associated with the label's value.
@@ -29,7 +29,9 @@ This is a way of attaching standard nostr tags to events, pubkeys, relays, urls,
29Label Tag 29Label Tag
30---- 30----
31 31
32An `l` tag's value can be any string. `l` tags MUST include a `mark` matching an `L` tag value in the same event. 32An `l` tag's value can be any string. If using an `L` tag, `l` tags MUST include a mark matching an `L`
33tag value in the same event. If no `L` tag is included, a mark SHOULD still be included. If none is
34included, `ugc` is implied.
33 35
34Label Target 36Label Target
35---- 37----
@@ -42,7 +44,7 @@ or topics respectively. As with NIP-01, a relay hint SHOULD be included when usi
42Content 44Content
43------- 45-------
44 46
45Labels should be short, meaningful strings. Longer discussions, such as for a review, or an 47Labels should be short, meaningful strings. Longer discussions, such as for an
46explanation of why something was labeled the way it was, should go in the event's `content` field. 48explanation of why something was labeled the way it was, should go in the event's `content` field.
47 49
48Self-Reporting 50Self-Reporting
@@ -158,4 +160,4 @@ Appendix: Known Ontologies
158 160
159Below is a non-exhaustive list of ontologies currently in widespread use. 161Below is a non-exhaustive list of ontologies currently in widespread use.
160 162
161- (social.ontolo.categories)[https://ontolo.social/] 163- [social.ontolo.categories](https://ontolo.social/)
diff --git a/35.md b/35.md
new file mode 100644
index 0000000..04cfb46
--- /dev/null
+++ b/35.md
@@ -0,0 +1,70 @@
1NIP-35
2======
3
4Torrents
5-----------
6
7`draft` `optional`
8
9This NIP defined a new `kind 2003` which is a Torrent.
10
11`kind 2003` is a simple torrent index where there is enough information to search for content and construct the magnet link. No torrent files exist on nostr.
12
13## Tags
14- `x`: V1 BitTorrent Info Hash, as seen in the [magnet link](https://www.bittorrent.org/beps/bep_0053.html) `magnet:?xt=urn:btih:HASH`
15- `file`: A file entry inside the torrent, including the full path ie. `info/example.txt`
16- `tracker`: (Optional) A tracker to use for this torrent
17
18In order to make torrents searchable by general category, you SHOULD include a few tags like `movie`, `tv`, `HD`, `UHD` etc.
19
20## Tag prefixes
21
22Tag prefixes are used to label the content with references, ie. `["i", "imdb:1234"]`
23
24- `tcat`: A comma separated text category path, ie. `["i", "tcat:video,movie,4k"]`, this should also match the `newznab` category in a best effort approach.
25- `newznab`: The category ID from [newznab](https://github.com/Prowlarr/Prowlarr/blob/develop/src/NzbDrone.Core/Indexers/NewznabStandardCategory.cs)
26- `tmdb`: [The movie database](https://www.themoviedb.org/) id.
27- `ttvdb`: [TV database](https://thetvdb.com/) id.
28- `imdb`: [IMDB](https://www.imdb.com/) id.
29- `mal`: [MyAnimeList](https://myanimelist.net/) id.
30- `anilist`: [AniList](https://anilist.co/) id.
31
32A second level prefix should be included where the database supports multiple media types.
33- `tmdb:movie:693134` maps to `themoviedb.org/movie/693134`
34- `ttvdb:movie:290272` maps to `thetvdb.com/movies/dune-part-two`
35- `mal:anime:9253` maps to `myanimelist.net/anime/9253`
36- `mal:manga:17517` maps to `myanimelist.net/manga/17517`
37
38In some cases the url mapping isnt direct, mapping the url in general is out of scope for this NIP, the section above is only a guide so that implementers have enough information to succsesfully map the url if they wish.
39
40```jsonc
41{
42 "kind": 2003,
43 "content": "<long-description-pre-formatted>",
44 "tags": [
45 ["title", "<torrent-title>"],
46 ["x", "<bittorrent-info-hash>"],
47 ["file", "<file-name>", "<file-size-in-bytes>"],
48 ["file", "<file-name>", "<file-size-in-bytes>"],
49 ["tracker", "udp://mytacker.com:1337"],
50 ["tracker", "http://1337-tracker.net/announce"],
51 ["i", "tcat:video,movie,4k"],
52 ["i", "newznab:2045"],
53 ["i", "imdb:tt15239678"],
54 ["i", "tmdb:movie:693134"],
55 ["i", "ttvdb:movie:290272"],
56 ["t", "movie"],
57 ["t", "4k"],
58 ]
59}
60```
61
62## Torrent Comments
63
64A torrent comment is a `kind 2004` event which is used to reply to a torrent event.
65
66This event works exactly like a `kind 1` and should follow `NIP-10` for tagging.
67
68## Implementations
691. [dtan.xyz](https://git.v0l.io/Kieran/dtan)
702. [nostrudel.ninja](https://github.com/hzrd149/nostrudel/tree/next/src/views/torrents) \ No newline at end of file
diff --git a/38.md b/38.md
index 911d5b1..4f2c06d 100644
--- a/38.md
+++ b/38.md
@@ -46,6 +46,8 @@ Any other status types can be used but they are not defined by this NIP.
46 46
47The status MAY include an `r`, `p`, `e` or `a` tag linking to a URL, profile, note, or parameterized replaceable event. 47The status MAY include an `r`, `p`, `e` or `a` tag linking to a URL, profile, note, or parameterized replaceable event.
48 48
49The `content` MAY include emoji(s), or [NIP-30](30.md) custom emoji(s). If the `content` is an empty string then the client should clear the status.
50
49# Client behavior 51# Client behavior
50 52
51Clients MAY display this next to the username on posts or profiles to provide live user status information. 53Clients MAY display this next to the username on posts or profiles to provide live user status information.
@@ -57,5 +59,3 @@ Clients MAY display this next to the username on posts or profiles to provide li
57* Nostr music streaming services that update your music status when you're listening 59* Nostr music streaming services that update your music status when you're listening
58* Podcasting apps that update your music status when you're listening to a podcast, with a link for others to listen as well 60* Podcasting apps that update your music status when you're listening to a podcast, with a link for others to listen as well
59* Clients can use the system media player to update playing music status 61* Clients can use the system media player to update playing music status
60
61The `content` MAY include emoji(s), or [NIP-30](30.md) custom emoji(s). If the `content` is an empty string then the client should clear the status.
diff --git a/50.md b/50.md
index a6e02be..2a31cb1 100644
--- a/50.md
+++ b/50.md
@@ -26,6 +26,8 @@ Relays SHOULD interpret the query to the best of their ability and return events
26Relays SHOULD perform matching against `content` event field, and MAY perform 26Relays SHOULD perform matching against `content` event field, and MAY perform
27matching against other fields if that makes sense in the context of a specific kind. 27matching against other fields if that makes sense in the context of a specific kind.
28 28
29Results SHOULD be returned in descending order by quality of search result (as defined by the implementation),
30not by the usual `.created_at`. The `limit` filter SHOULD be applied after sorting by matching score.
29A query string may contain `key:value` pairs (two words separated by colon), these are extensions, relays SHOULD ignore 31A query string may contain `key:value` pairs (two words separated by colon), these are extensions, relays SHOULD ignore
30extensions they don't support. 32extensions they don't support.
31 33
diff --git a/53.md b/53.md
index fad2622..0b1cb81 100644
--- a/53.md
+++ b/53.md
@@ -77,7 +77,7 @@ Event `kind:1311` is live chat's channel message. Clients MUST include the `a` t
77 77
78## Use Cases 78## Use Cases
79 79
80Common use cases include meeting rooms/workshops, watch-together activities, or event spaces, such as [live.snort.social](https://live.snort.social) and [nostrnests.com](https://nostrnests.com). 80Common use cases include meeting rooms/workshops, watch-together activities, or event spaces, such as [zap.stream](https://zap.stream).
81 81
82## Example 82## Example
83 83
diff --git a/54.md b/54.md
index 8823af9..fe46918 100644
--- a/54.md
+++ b/54.md
@@ -36,6 +36,11 @@ The content should be Markdown, following the same rules as of [NIP-23](23.md),
36 36
37One extra functionality is added: **wikilinks**. Unlike normal Markdown links `[]()` that link to webpages, wikilinks `[[]]` link to other articles in the wiki. In this case, the wiki is the entirety of Nostr. Clicking on a wikilink should cause the client to ask relays for events with `d` tags equal to the target of that wikilink. 37One extra functionality is added: **wikilinks**. Unlike normal Markdown links `[]()` that link to webpages, wikilinks `[[]]` link to other articles in the wiki. In this case, the wiki is the entirety of Nostr. Clicking on a wikilink should cause the client to ask relays for events with `d` tags equal to the target of that wikilink.
38 38
39Wikilinks can take these two forms:
40
41 1. `[[Target Page]]` -- in this case it will link to the page `target-page` (according to `d` tag normalization rules above) and be displayed as `Target Page`;
42 2. `[[target page|see this]]` -- in this case it will link to the page `target-page`, but will be displayed as `see this`.
43
39### Merge Requests 44### Merge Requests
40 45
41Event `kind:818` represents a request to merge from a forked article into the source. It is directed to a pubkey and references the original article and the modified event. 46Event `kind:818` represents a request to merge from a forked article into the source. It is directed to a pubkey and references the original article and the modified event.
diff --git a/55.md b/55.md
new file mode 100644
index 0000000..4565e8c
--- /dev/null
+++ b/55.md
@@ -0,0 +1,538 @@
1# NIP-55
2
3## Android Signer Application
4
5`draft` `optional`
6
7This NIP describes a method for 2-way communication between an Android signer and any Nostr client on Android. The Android signer is an Android Application and the client can be a web client or an Android application.
8
9# Usage for Android applications
10
11The Android signer uses Intents and Content Resolvers to communicate between applications.
12
13To be able to use the Android signer in your application you should add this to your AndroidManifest.xml:
14
15```xml
16<queries>
17 <intent>
18 <action android:name="android.intent.action.VIEW" />
19 <category android:name="android.intent.category.BROWSABLE" />
20 <data android:scheme="nostrsigner" />
21 </intent>
22</queries>
23```
24
25Then you can use this function to check if there's a signer application installed:
26
27```kotlin
28fun isExternalSignerInstalled(context: Context): Boolean {
29 val intent =
30 Intent().apply {
31 action = Intent.ACTION_VIEW
32 data = Uri.parse("nostrsigner:")
33 }
34 val infos = context.packageManager.queryIntentActivities(intent, 0)
35 return infos.size > 0
36}
37```
38
39## Using Intents
40
41To get the result back from the Signer Application you should use `registerForActivityResult` or `rememberLauncherForActivityResult` in Kotlin. If you are using another framework check the documentation of your framework or a third party library to get the result.
42
43```kotlin
44val launcher = rememberLauncherForActivityResult(
45 contract = ActivityResultContracts.StartActivityForResult(),
46 onResult = { result ->
47 if (result.resultCode != Activity.RESULT_OK) {
48 Toast.makeText(
49 context,
50 "Sign request rejected",
51 Toast.LENGTH_SHORT
52 ).show()
53 } else {
54 val signature = activityResult.data?.getStringExtra("signature")
55 // Do something with signature ...
56 }
57 }
58)
59```
60
61Create the Intent using the **nostrsigner** scheme:
62
63```kotlin
64val intent = Intent(Intent.ACTION_VIEW, Uri.parse("nostrsigner:$content"))
65```
66
67Set the Signer package name:
68
69```kotlin
70intent.`package` = "com.example.signer"
71```
72
73Send the Intent:
74
75```kotlin
76launcher.launch(intent)
77```
78
79### Methods
80
81- **get_public_key**
82 - params:
83
84 ```kotlin
85 val intent = Intent(Intent.ACTION_VIEW, Uri.parse("nostrsigner:"))
86 intent.`package` = "com.example.signer"
87 intent.putExtra("type", "get_public_key")
88 // You can send some default permissions for the user to authorize for ever
89 val permissions = listOf(
90 Permission(
91 type = "sign_event",
92 kind = 22242
93 ),
94 Permission(
95 type = "nip44_decrypt"
96 )
97 )
98 intent.putExtra("permissions", permissions.toJson())
99 context.startActivity(intent)
100 ```
101 - result:
102 - If the user approved intent it will return the **npub** in the signature field
103
104 ```kotlin
105 val npub = intent.data?.getStringExtra("signature")
106 // The package name of the signer application
107 val packageName = intent.data?.getStringExtra("package")
108 ```
109
110- **sign_event**
111 - params:
112
113 ```kotlin
114 val intent = Intent(Intent.ACTION_VIEW, Uri.parse("nostrsigner:$eventJson"))
115 intent.`package` = "com.example.signer"
116 intent.putExtra("type", "sign_event")
117 // To handle results when not waiting between intents
118 intent.putExtra("id", event.id)
119 // Send the current logged in user npub
120 intent.putExtra("current_user", npub)
121
122 context.startActivity(intent)
123 ```
124 - result:
125 - If the user approved intent it will return the **signature**, **id** and **event** fields
126
127 ```kotlin
128 val signature = intent.data?.getStringExtra("signature")
129 // The id you sent
130 val id = intent.data?.getStringExtra("id")
131 val signedEventJson = intent.data?.getStringExtra("event")
132 ```
133
134- **nip04_encrypt**
135 - params:
136
137 ```kotlin
138 val intent = Intent(Intent.ACTION_VIEW, Uri.parse("nostrsigner:$plaintext"))
139 intent.`package` = "com.example.signer"
140 intent.putExtra("type", "nip04_encrypt")
141 // to control the result in your application in case you are not waiting the result before sending another intent
142 intent.putExtra("id", "some_id")
143 // Send the current logged in user npub
144 intent.putExtra("current_user", account.keyPair.pubKey.toNpub())
145 // Send the hex pubKey that will be used for encrypting the data
146 intent.putExtra("pubKey", pubKey)
147
148 context.startActivity(intent)
149 ```
150 - result:
151 - If the user approved intent it will return the **signature** and **id** fields
152
153 ```kotlin
154 val encryptedText = intent.data?.getStringExtra("signature")
155 // the id you sent
156 val id = intent.data?.getStringExtra("id")
157 ```
158
159- **nip44_encrypt**
160 - params:
161
162 ```kotlin
163 val intent = Intent(Intent.ACTION_VIEW, Uri.parse("nostrsigner:$plaintext"))
164 intent.`package` = "com.example.signer"
165 intent.putExtra("type", "nip44_encrypt")
166 // to control the result in your application in case you are not waiting the result before sending another intent
167 intent.putExtra("id", "some_id")
168 // Send the current logged in user npub
169 intent.putExtra("current_user", account.keyPair.pubKey.toNpub())
170 // Send the hex pubKey that will be used for encrypting the data
171 intent.putExtra("pubKey", pubKey)
172
173 context.startActivity(intent)
174 ```
175 - result:
176 - If the user approved intent it will return the **signature** and **id** fields
177
178 ```kotlin
179 val encryptedText = intent.data?.getStringExtra("signature")
180 // the id you sent
181 val id = intent.data?.getStringExtra("id")
182 ```
183
184- **nip04_decrypt**
185 - params:
186
187 ```kotlin
188 val intent = Intent(Intent.ACTION_VIEW, Uri.parse("nostrsigner:$encryptedText"))
189 intent.`package` = "com.example.signer"
190 intent.putExtra("type", "nip04_decrypt")
191 // to control the result in your application in case you are not waiting the result before sending another intent
192 intent.putExtra("id", "some_id")
193 // Send the current logged in user npub
194 intent.putExtra("current_user", account.keyPair.pubKey.toNpub())
195 // Send the hex pubKey that will be used for decrypting the data
196 intent.putExtra("pubKey", pubKey)
197
198 context.startActivity(intent)
199 ```
200 - result:
201 - If the user approved intent it will return the **signature** and **id** fields
202
203 ```kotlin
204 val plainText = intent.data?.getStringExtra("signature")
205 // the id you sent
206 val id = intent.data?.getStringExtra("id")
207 ```
208
209- **nip44_decrypt**
210 - params:
211
212 ```kotlin
213 val intent = Intent(Intent.ACTION_VIEW, Uri.parse("nostrsigner:$encryptedText"))
214 intent.`package` = "com.example.signer"
215 intent.putExtra("type", "nip04_decrypt")
216 // to control the result in your application in case you are not waiting the result before sending another intent
217 intent.putExtra("id", "some_id")
218 // Send the current logged in user npub
219 intent.putExtra("current_user", account.keyPair.pubKey.toNpub())
220 // Send the hex pubKey that will be used for decrypting the data
221 intent.putExtra("pubKey", pubKey)
222
223 context.startActivity(intent)
224 ```
225 - result:
226 - If the user approved intent it will return the **signature** and **id** fields
227
228 ```kotlin
229 val plainText = intent.data?.getStringExtra("signature")
230 // the id you sent
231 val id = intent.data?.getStringExtra("id")
232 ```
233
234- **decrypt_zap_event**
235 - params:
236
237 ```kotlin
238 val intent = Intent(Intent.ACTION_VIEW, Uri.parse("nostrsigner:$eventJson"))
239 intent.`package` = "com.example.signer"
240 intent.putExtra("type", "decrypt_zap_event")
241 // to control the result in your application in case you are not waiting the result before sending another intent
242 intent.putExtra("id", "some_id")
243 // Send the current logged in user npub
244 intent.putExtra("current_user", account.keyPair.pubKey.toNpub())
245 context.startActivity(intent)
246 ```
247 - result:
248 - If the user approved intent it will return the **signature** and **id** fields
249
250 ```kotlin
251 val eventJson = intent.data?.getStringExtra("signature")
252 // the id you sent
253 val id = intent.data?.getStringExtra("id")
254 ```
255
256## Using Content Resolver
257
258To get the result back from Signer Application you should use contentResolver.query in Kotlin. If you are using another framework check the documentation of your framework or a third party library to get the result.
259
260If the user did not check the "remember my choice" option, the npub is not in Signer Application or the signer type is not recognized the `contentResolver` will return null
261
262For the SIGN_EVENT type Signer Application returns two columns "signature" and "event". The column event is the signed event json
263
264For the other types Signer Application returns the column "signature"
265
266If the user chose to always reject the event, signer application will return the column "rejected" and you should not open signer application
267
268### Methods
269
270- **get_public_key**
271 - params:
272
273 ```kotlin
274 val result = context.contentResolver.query(
275 Uri.parse("content://com.example.signer.GET_PUBLIC_KEY"),
276 listOf("login"),
277 null,
278 null,
279 null
280 )
281 ```
282 - result:
283 - Will return the **npub** in the signature column
284
285 ```kotlin
286 if (result == null) return
287
288 if (result.moveToFirst()) {
289 val index = it.getColumnIndex("signature")
290 if (index < 0) return
291 val npub = it.getString(index)
292 }
293 ```
294
295- **sign_event**
296 - params:
297
298 ```kotlin
299 val result = context.contentResolver.query(
300 Uri.parse("content://com.example.signer.SIGN_EVENT"),
301 listOf("$eventJson", "", "${logged_in_user_npub}"),
302 null,
303 null,
304 null
305 )
306 ```
307 - result:
308 - Will return the **signature** and the **event** columns
309
310 ```kotlin
311 if (result == null) return
312
313 if (result.moveToFirst()) {
314 val index = it.getColumnIndex("signature")
315 val indexJson = it.getColumnIndex("event")
316 val signature = it.getString(index)
317 val eventJson = it.getString(indexJson)
318 }
319 ```
320
321- **nip04_encrypt**
322 - params:
323
324 ```kotlin
325 val result = context.contentResolver.query(
326 Uri.parse("content://com.example.signer.NIP04_ENCRYPT"),
327 listOf("$plainText", "${hex_pub_key}", "${logged_in_user_npub}"),
328 null,
329 null,
330 null
331 )
332 ```
333 - result:
334 - Will return the **signature** column
335
336 ```kotlin
337 if (result == null) return
338
339 if (result.moveToFirst()) {
340 val index = it.getColumnIndex("signature")
341 val encryptedText = it.getString(index)
342 }
343 ```
344
345- **nip44_encrypt**
346 - params:
347
348 ```kotlin
349 val result = context.contentResolver.query(
350 Uri.parse("content://com.example.signer.NIP44_ENCRYPT"),
351 listOf("$plainText", "${hex_pub_key}", "${logged_in_user_npub}"),
352 null,
353 null,
354 null
355 )
356 ```
357 - result:
358 - Will return the **signature** column
359
360 ```kotlin
361 if (result == null) return
362
363 if (result.moveToFirst()) {
364 val index = it.getColumnIndex("signature")
365 val encryptedText = it.getString(index)
366 }
367 ```
368
369- **nip04_decrypt**
370 - params:
371
372 ```kotlin
373 val result = context.contentResolver.query(
374 Uri.parse("content://com.example.signer.NIP04_DECRYPT"),
375 listOf("$encryptedText", "${hex_pub_key}", "${logged_in_user_npub}"),
376 null,
377 null,
378 null
379 )
380 ```
381 - result:
382 - Will return the **signature** column
383
384 ```kotlin
385 if (result == null) return
386
387 if (result.moveToFirst()) {
388 val index = it.getColumnIndex("signature")
389 val encryptedText = it.getString(index)
390 }
391 ```
392
393- **nip44_decrypt**
394 - params:
395
396 ```kotlin
397 val result = context.contentResolver.query(
398 Uri.parse("content://com.example.signer.NIP44_DECRYPT"),
399 listOf("$encryptedText", "${hex_pub_key}", "${logged_in_user_npub}"),
400 null,
401 null,
402 null
403 )
404 ```
405 - result:
406 - Will return the **signature** column
407
408 ```kotlin
409 if (result == null) return
410
411 if (result.moveToFirst()) {
412 val index = it.getColumnIndex("signature")
413 val encryptedText = it.getString(index)
414 }
415 ```
416
417- **decrypt_zap_event**
418 - params:
419
420 ```kotlin
421 val result = context.contentResolver.query(
422 Uri.parse("content://com.example.signer.DECRYPT_ZAP_EVENT"),
423 listOf("$eventJson", "", "${logged_in_user_npub}"),
424 null,
425 null,
426 null
427 )
428 ```
429 - result:
430 - Will return the **signature** column
431
432 ```kotlin
433 if (result == null) return
434
435 if (result.moveToFirst()) {
436 val index = it.getColumnIndex("signature")
437 val eventJson = it.getString(index)
438 }
439 ```
440
441# Usage for Web Applications
442
443Since web applications can't receive a result from the intent, you should add a modal to paste the signature or the event json or create a callback url.
444
445If you send the callback url parameter, Signer Application will send the result to the url.
446
447If you don't send a callback url, Signer Application will copy the result to the clipboard.
448
449You can configure the `returnType` to be **signature** or **event**.
450
451Android intents and browser urls have limitations, so if you are using the `returnType` of **event** consider using the parameter **compressionType=gzip** that will return "Signer1" + Base64 gzip encoded event json
452
453## Methods
454
455- **get_public_key**
456 - params:
457
458 ```js
459 window.href = `nostrsigner:?compressionType=none&returnType=signature&type=get_public_key&callbackUrl=https://example.com/?event=`;
460 ```
461
462- **sign_event**
463 - params:
464
465 ```js
466 window.href = `nostrsigner:${eventJson}?compressionType=none&returnType=signature&type=sign_event&callbackUrl=https://example.com/?event=`;
467 ```
468
469- **nip04_encrypt**
470 - params:
471
472 ```js
473 window.href = `nostrsigner:${plainText}?pubKey=${hex_pub_key}&compressionType=none&returnType=signature&type=nip04_encrypt&callbackUrl=https://example.com/?event=`;
474 ```
475
476- **nip44_encrypt**
477 - params:
478
479 ```js
480 window.href = `nostrsigner:${plainText}?pubKey=${hex_pub_key}&compressionType=none&returnType=signature&type=nip44_encrypt&callbackUrl=https://example.com/?event=`;
481 ```
482
483- **nip04_decrypt**
484 - params:
485
486 ```js
487 window.href = `nostrsigner:${encryptedText}?pubKey=${hex_pub_key}&compressionType=none&returnType=signature&type=nip04_decrypt&callbackUrl=https://example.com/?event=`;
488 ```
489
490- **nip44_decrypt**
491 - params:
492
493 ```js
494 window.href = `nostrsigner:${encryptedText}?pubKey=${hex_pub_key}&compressionType=none&returnType=signature&type=nip44_decrypt&callbackUrl=https://example.com/?event=`;
495 ```
496
497- **decrypt_zap_event**
498 - params:
499
500 ```js
501 window.href = `nostrsigner:${eventJson}?compressionType=none&returnType=signature&type=decrypt_zap_event&callbackUrl=https://example.com/?event=`;
502 ```
503
504## Example
505
506```js
507<!DOCTYPE html>
508<html lang="en">
509<head>
510 <meta charset="UTF-8">
511 <meta name="viewport" content="width=device-width, initial-scale=1.0">
512 <title>Document</title>
513</head>
514<body>
515 <h1>Test</h1>
516
517 <script>
518 window.onload = function() {
519 var url = new URL(window.location.href);
520 var params = url.searchParams;
521 if (params) {
522 var param1 = params.get("event");
523 if (param1) alert(param1)
524 }
525 let json = {
526 kind: 1,
527 content: "test"
528 }
529 let encodedJson = encodeURIComponent(JSON.stringify(json))
530 var newAnchor = document.createElement("a");
531 newAnchor.href = `nostrsigner:${encodedJson}?compressionType=none&returnType=signature&type=sign_event&callbackUrl=https://example.com/?event=`;
532 newAnchor.textContent = "Open External Signer";
533 document.body.appendChild(newAnchor)
534 }
535 </script>
536</body>
537</html>
538```
diff --git a/57.md b/57.md
index 6d89620..d04eeff 100644
--- a/57.md
+++ b/57.md
@@ -131,7 +131,7 @@ The following should be true of the `zap receipt` event:
131- The `created_at` date SHOULD be set to the invoice `paid_at` date for idempotency. 131- The `created_at` date SHOULD be set to the invoice `paid_at` date for idempotency.
132- `tags` MUST include the `p` tag (zap recipient) AND optional `e` tag from the `zap request` AND optional `a` tag from the `zap request` AND optional `P` tag from the pubkey of the zap request (zap sender). 132- `tags` MUST include the `p` tag (zap recipient) AND optional `e` tag from the `zap request` AND optional `a` tag from the `zap request` AND optional `P` tag from the pubkey of the zap request (zap sender).
133- The `zap receipt` MUST have a `bolt11` tag containing the description hash bolt11 invoice. 133- The `zap receipt` MUST have a `bolt11` tag containing the description hash bolt11 invoice.
134- The `zap receipt` MUST contain a `description` tag which is the JSON-encoded invoice description. 134- The `zap receipt` MUST contain a `description` tag which is the JSON-encoded zap request.
135- `SHA256(description)` MUST match the description hash in the bolt11 invoice. 135- `SHA256(description)` MUST match the description hash in the bolt11 invoice.
136- The `zap receipt` MAY contain a `preimage` tag to match against the payment hash of the bolt11 invoice. This isn't really a payment proof, there is no real way to prove that the invoice is real or has been paid. You are trusting the author of the `zap receipt` for the legitimacy of the payment. 136- The `zap receipt` MAY contain a `preimage` tag to match against the payment hash of the bolt11 invoice. This isn't really a payment proof, there is no real way to prove that the invoice is real or has been paid. You are trusting the author of the `zap receipt` for the legitimacy of the payment.
137 137
diff --git a/71.md b/71.md
new file mode 100644
index 0000000..a811434
--- /dev/null
+++ b/71.md
@@ -0,0 +1,118 @@
1NIP-71
2======
3
4Video Events
5---------------
6
7`draft` `optional`
8
9This specification defines video events representing a dedicated post of externally hosted content. These video events are _parameterized replaceable_ and deletable per [NIP-09](09.md).
10
11Unlike a `kind 1` event with a video attached, Video Events are meant to contain all additional metadata concerning the subject media and to be surfaced in video-specific clients rather than general micro-blogging clients. The thought is for events of this kind to be referenced in a Netflix, YouTube, or TikTok like nostr client where the video itself is at the center of the experience.
12
13## Video Events
14
15There are two types of video events represented by different kinds: horizontal and vertical video events. This is meant to allow clients to cater to each as the viewing experience for horizontal (landscape) videos is often different than that of vertical (portrait) videos (Stories, Reels, Shorts, etc).
16
17#### Format
18
19The format uses a parameterized replaceable event kind `34235` for horizontal videos and `34236` for vertical videos.
20
21The `.content` of these events is a summary or description on the video content.
22
23The list of tags are as follows:
24* `d` (required) universally unique identifier (UUID). Generated by the client creating the video event.
25* `url` (required) the url to the video file
26* `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.
27* `title` (required) title of the video
28* `"published_at"`, for the timestamp in unix seconds (stringified) of the first time the video was published
29* `x` containing the SHA-256 hexencoded string of the file.
30* `size` (optional) size of file in bytes
31* `dim` (optional) size of file in pixels in the form `<width>x<height>`
32* `duration` (optional) video duration in seconds
33* `magnet` (optional) URI to magnet file
34* `i` (optional) torrent infohash
35* `text-track` (optional, repeated) link to WebVTT file for video, type of supplementary information (captions/subtitles/chapters/metadata), optional language code
36* `thumb` (optional) url of thumbnail with same aspect ratio
37* `image` (optional) url of preview image with same dimensions
38* `content-warning` (optional) warning about content of NSFW video
39* `alt` (optional) description for accessibility
40* `segment` (optional, repeated) start timestamp in format `HH:MM:SS.sss`, end timestamp in format `HH:MM:SS.sss`, chapter/segment title, chapter thumbnail-url
41* `t` (optional, repeated) hashtag to categorize video
42* `p` (optional, repeated) 32-bytes hex pubkey of a participant in the video, optional recommended relay URL
43* `r` (optional, repeated) references / links to web pages
44
45```json
46{
47 "id": <32-bytes lowercase hex-encoded SHA-256 of the the serialized event data>,
48 "pubkey": <32-bytes lowercase hex-encoded public key of the event creator>,
49 "created_at": <Unix timestamp in seconds>,
50 "kind": 34235 | 34236,
51 "content": "<summary / description of video>",
52 "tags": [
53 ["d", "<UUID>"],
54
55 ["title", "<title of video>"],
56 ["thumb", "<thumbnail image for video>"],
57 ["published_at", "<unix timestamp>"],
58 ["alt", <description>],
59
60 // Video Data
61 ["url",<string with URI of file>],
62 ["m", <MIME type>],
63 ["x",<Hash SHA-256>],
64 ["size", <size of file in bytes>],
65 ["duration", <duration of video in seconds>],
66 ["dim", <size of file in pixels>],
67 ["magnet",<magnet URI> ],
68 ["i",<torrent infohash>],
69 ["text-track", "<encoded `kind 6000` event>", "<recommended relay urls>"],
70 ["content-warning", "<reason>"],
71 ["segment", <start>, <end>, "<title>", "<thumbnail URL>"],
72
73 // Participants
74 ["p", "<32-bytes hex of a pubkey>", "<optional recommended relay URL>"],
75 ["p", "<32-bytes hex of a pubkey>", "<optional recommended relay URL>"],
76
77 // Hashtags
78 ["t", "<tag>"],
79 ["t", "<tag>"],
80
81 // Reference links
82 ["r", "<url>"],
83 ["r", "<url>"]
84 ]
85}
86```
87
88## Video View
89
90A video event view is a response to a video event to track a user's view or progress viewing the video.
91
92### Format
93
94The format uses a parameterized replaceable event kind `34237`.
95
96The `.content` of these events is optional and could be a free-form note that acts like a bookmark for the user.
97
98The list of tags are as follows:
99* `a` (required) reference tag to kind `34235` or `34236` video event being viewed
100* `d` (required) same as `a` reference tag value
101* `viewed` (optional, repeated) timestamp of the user's start time in seconds, timestamp of the user's end time in seconds
102
103
104```json
105{
106 "id": <32-bytes lowercase hex-encoded SHA-256 of the the serialized event data>,
107 "pubkey": <32-bytes lowercase hex-encoded public key of the event creator>,
108 "created_at": <Unix timestamp in seconds>,
109 "kind": 34237,
110 "content": "<note>",
111 "tags": [
112 ["a", "<34235 | 34236>:<video event author pubkey>:<d-identifier of video event>", "<optional relay url>"],
113 ["e", "<event-id", "<relay-url>"]
114 ["d", "<34235 | 34236>:<video event author pubkey>:<d-identifier of video event>"],
115 ["viewed", <start>, <end>],
116 ]
117}
118```
diff --git a/96.md b/96.md
index f7d901f..2f25351 100644
--- a/96.md
+++ b/96.md
@@ -1,8 +1,6 @@
1NIP-96 1# NIP-96
2======
3 2
4HTTP File Storage Integration 3## HTTP File Storage Integration
5-----------------------------
6 4
7`draft` `optional` 5`draft` `optional`
8 6
@@ -84,46 +82,46 @@ it must use the "api_url" field instead.
84 82
85See https://github.com/aljazceru/awesome-nostr#nip-96-file-storage-servers. 83See https://github.com/aljazceru/awesome-nostr#nip-96-file-storage-servers.
86 84
85## Auth
86
87When indicated, `clients` must add an [NIP-98](98.md) `Authorization` header (**optionally** with the encoded `payload` tag set to the base64-encoded 256-bit SHA-256 hash of the file - not the hash of the whole request body).
88
87## Upload 89## Upload
88 90
89A file can be uploaded one at a time to `https://your-file-server.example/custom-api-path` (route from `https://your-file-server.example/.well-known/nostr/nip96.json` "api_url" field) as `multipart/form-data` content type using `POST` method with the file object set to the `file` form data field. 91`POST $api_url` as `multipart/form-data`.
90 92
91`Clients` must add an [NIP-98](98.md) `Authorization` header (**optionally** with the encoded `payload` tag set to the base64-encoded 256-bit SHA-256 hash of the file - not the hash of the whole request body). 93**AUTH required**
92If using an html form, use an `Authorization` form data field instead.
93 94
94These following **optional** form data fields MAY be used by `servers` and SHOULD be sent by `clients`: 95List of form fields:
95- `expiration`: string of the UNIX timestamp in seconds. Empty string if file should be stored forever. The server isn't required to honor this;
96- `size`: string of the file byte size. This is just a value the server can use to reject early if the file size exceeds the server limits;
97- `alt`: (recommended) strict description text for visibility-impaired users;
98- `caption`: loose description;
99- `media_type`: "avatar" or "banner". Informs the server if the file will be used as an avatar or banner. If absent, the server will interpret it as a normal upload, without special treatment;
100- `content_type`: mime type such as "image/jpeg". This is just a value the server can use to reject early if the mime type isn't supported.
101 96
97- `file`: **REQUIRED** the file to upload
98- `caption`: **RECOMMENDED** loose description;
99- `expiration`: UNIX timestamp in seconds. Empty string if file should be stored forever. The server isn't required to honor this.
100- `size`: File byte size. This is just a value the server can use to reject early if the file size exceeds the server limits.
101- `alt`: **RECOMMENDED** strict description text for visibility-impaired users.
102- `media_type`: "avatar" or "banner". Informs the server if the file will be used as an avatar or banner. If absent, the server will interpret it as a normal upload, without special treatment.
103- `content_type`: mime type such as "image/jpeg". This is just a value the server can use to reject early if the mime type isn't supported.
104- `no_transform`: "true" asks server not to transform the file and serve the uploaded file as is, may be rejected.
102 105
103Others custom form data fields may be used depending on specific `server` support. 106Others custom form data fields may be used depending on specific `server` support.
104The `server` isn't required to store any metadata sent by `clients`. 107The `server` isn't required to store any metadata sent by `clients`.
105 108
106Note for `clients`: if using an HTML form, it is important for the `file` form field to be the **last** one, or be re-ordered right before sending or be appended as the last field of XHR2's FormData object.
107
108The `filename` embedded in the file may not be honored by the `server`, which could internally store just the SHA-256 hash value as the file name, ignoring extra metadata. 109The `filename` embedded in the file may not be honored by the `server`, which could internally store just the SHA-256 hash value as the file name, ignoring extra metadata.
109The hash is enough to uniquely identify a file, that's why it will be used on the "download" and "delete" routes. 110The hash is enough to uniquely identify a file, that's why it will be used on the `download` and `delete` routes.
110
111The `server` MUST link the user's `pubkey` string (which is embedded in the decoded header value) as the owner of the file so to later allow them to delete the file.
112Note that if a file with the same hash of a previously received file (so the same file) is uploaded by another user, the server doesn't need to store the new file.
113It should just add the new user's `pubkey` to the list of the owners of the already stored file with said hash (if it wants to save space by keeping just one copy of the same file, because multiple uploads of the same file results in the same file hash).
114
115The `server` MAY also store the `Authorization` header/field value (decoded or not) for accountability purpose as this proves that the user with the unique pubkey did ask for the upload of the file with a specific hash. However, storing the pubkey is sufficient to establish ownership.
116 111
117The `server` MUST reject with 413 Payload Too Large if file size exceeds limits. 112The `server` MUST link the user's `pubkey` string as the owner of the file so to later allow them to delete the file.
118 113
119The `server` MUST reject with 400 Bad Request status if some fields are invalid. 114`no_transform` can be used to replicate a file to multiple servers for redundancy, clients can use the [server list](#selecting-a-server) to find alternative servers which might contain the same file. When uploading a file and requesting `no_transform` clients should check that the hash matches in the response in order to detect if the file was modified.
120 115
121The `server` MUST reply to the upload with 200 OK status if the `payload` tag value contains an already used SHA-256 hash (if file is already owned by the same pubkey) or reject the upload with 403 Forbidden status if it isn't the same of the received file. 116### Response codes
122 117
123The `server` MAY reject the upload with 402 Payment Required status if the user has a pending payment (Payment flow is not strictly required. Server owners decide if the storage is free or not. Monetization schemes may be added later to correlated NIPs.). 118- `200 OK`: File upload exists, but is successful (Existing hash)
124 119- `201 Created`: File upload successful (New hash)
125On successful uploads the `server` MUST reply with **201 Created** HTTP status code or **202 Accepted** if a `processing_url` field is added 120- `202 Accepted`: File upload is awaiting processing, see [Delayed Processing](#delayed-processing) section
126to the response so that the `client` can follow the processing status (see [Delayed Processing](#delayed-processing) section). 121- `413 Payload Too Large`: File size exceeds limit
122- `400 Bad Request`: Form data is invalid or not supported.
123- `403 Forbidden`: User is not allowed to upload or the uploaded file hash didnt match the hash included in the `Authorization` header `payload` tag.
124- `402 Payment Required`: Payment is required by the server, **this flow is undefined**.
127 125
128The upload response is a json object as follows: 126The upload response is a json object as follows:
129 127
@@ -179,11 +177,13 @@ The upload response is a json object as follows:
179 177
180Note that if the server didn't apply any transformation to the received file, both `nip94_event.tags.*.ox` and `nip94_event.tags.*.x` fields will have the same value. The server MUST link the saved file to the SHA-256 hash of the **original** file before any server transformations (the `nip94_event.tags.*.ox` tag value). The **original** file's SHA-256 hash will be used to identify the saved file when downloading or deleting it. 178Note that if the server didn't apply any transformation to the received file, both `nip94_event.tags.*.ox` and `nip94_event.tags.*.x` fields will have the same value. The server MUST link the saved file to the SHA-256 hash of the **original** file before any server transformations (the `nip94_event.tags.*.ox` tag value). The **original** file's SHA-256 hash will be used to identify the saved file when downloading or deleting it.
181 179
182`Clients` may upload the same file to one or many `servers`. 180`clients` may upload the same file to one or many `servers`.
183After successful upload, the `client` may optionally generate and send to any set of nostr `relays` a [NIP-94](94.md) event by including the missing fields. 181After successful upload, the `client` may optionally generate and send to any set of nostr `relays` a [NIP-94](94.md) event by including the missing fields.
184 182
185Alternatively, instead of using NIP-94, the `client` can share or embed on a nostr note just the above url. 183Alternatively, instead of using NIP-94, the `client` can share or embed on a nostr note just the above url.
186 184
185`clients` may also use the tags from the `nip94_event` to construct an `imeta` tag
186
187### Delayed Processing 187### Delayed Processing
188 188
189Sometimes the server may want to place the uploaded file in a processing queue for deferred file processing. 189Sometimes the server may want to place the uploaded file in a processing queue for deferred file processing.
@@ -219,7 +219,7 @@ However, for all file actions, such as download and deletion, the **original** f
219 219
220## Download 220## Download
221 221
222`Servers` must make available the route `https://your-file-server.example/custom-api-path/<sha256-file-hash>(.ext)` (route taken from `https://your-file-server.example/.well-known/nostr/nip96.json` "api_url" or "download_url" field) with `GET` method for file download. 222`GET $api_url/<sha256-hash>(.ext)`
223 223
224The primary file download url informed at the upload's response field `nip94_event.tags.*.url` 224The primary file download url informed at the upload's response field `nip94_event.tags.*.url`
225can be that or not (it can be any non-standard url the server wants). 225can be that or not (it can be any non-standard url the server wants).
@@ -227,17 +227,17 @@ If not, the server still MUST also respond to downloads at the standard url
227mentioned on the previous paragraph, to make it possible for a client 227mentioned on the previous paragraph, to make it possible for a client
228to try downloading a file on any NIP-96 compatible server by knowing just the SHA-256 file hash. 228to try downloading a file on any NIP-96 compatible server by knowing just the SHA-256 file hash.
229 229
230Note that the "\<sha256-file-hash\>" part is from the **original** file, **not** from the **transformed** file if the uploaded file went through any server transformation. 230Note that the "\<sha256-hash\>" part is from the **original** file, **not** from the **transformed** file if the uploaded file went through any server transformation.
231 231
232Supporting ".ext", meaning "file extension", is required for `servers`. It is optional, although recommended, for `clients` to append it to the path. 232Supporting ".ext", meaning "file extension", is required for `servers`. It is optional, although recommended, for `clients` to append it to the path.
233When present it may be used by `servers` to know which `Content-Type` header to send (e.g.: "Content-Type": "image/png" for ".png" extension). 233When present it may be used by `servers` to know which `Content-Type` header to send (e.g.: "Content-Type": "image/png" for ".png" extension).
234The file extension may be absent because the hash is the only needed string to uniquely identify a file. 234The file extension may be absent because the hash is the only needed string to uniquely identify a file.
235 235
236Example: `https://your-file-server.example/custom-api-path/719171db19525d9d08dd69cb716a18158a249b7b3b3ec4bbdec5698dca104b7b.png` 236Example: `$api_url/719171db19525d9d08dd69cb716a18158a249b7b3b3ec4bbdec5698dca104b7b.png`
237 237
238### Media Transformations 238### Media Transformations
239 239
240`Servers` may respond to some media transformation query parameters and ignore those they don't support by serving 240`servers` may respond to some media transformation query parameters and ignore those they don't support by serving
241the original media file without transformations. 241the original media file without transformations.
242 242
243#### Image Transformations 243#### Image Transformations
@@ -245,23 +245,23 @@ the original media file without transformations.
245##### Resizing 245##### Resizing
246 246
247Upon upload, `servers` may create resized image variants, such as thumbnails, respecting the original aspect ratio. 247Upon upload, `servers` may create resized image variants, such as thumbnails, respecting the original aspect ratio.
248`Clients` may use the `w` query parameter to request an image version with the desired pixel width. 248`clients` may use the `w` query parameter to request an image version with the desired pixel width.
249`Servers` can then serve the variant with the closest width to the parameter value 249`servers` can then serve the variant with the closest width to the parameter value
250or an image variant generated on the fly. 250or an image variant generated on the fly.
251 251
252Example: `https://your-file-server.example/custom-api-path/<sha256-file-hash>.png?w=32` 252Example: `$api_url/<sha256-hash>.png?w=32`
253 253
254## Deletion 254## Deletion
255 255
256`Servers` must make available the route `https://deletion.domain/deletion-path/<sha256-file-hash>(.ext)` (route taken from `https://your-file-server.example/.well-known/nostr/nip96.json` "api_url" field) with `DELETE` method for file deletion. 256`DELETE $api_url/<sha256-hash>(.ext)`
257 257
258Note that the "\<sha256-file-hash\>" part is from the **original** file, **not** from the **transformed** file if the uploaded file went through any server transformation. 258**AUTH required**
259 259
260The extension is optional as the file hash is the only needed file identification. 260Note that the `/<sha256-hash>` part is from the **original** file, **not** from the **transformed** file if the uploaded file went through any server transformation.
261 261
262`Clients` should send a `DELETE` request to the server deletion route in the above format. It must include a NIP-98 `Authorization` header. 262The extension is optional as the file hash is the only needed file identification.
263 263
264The `server` should reject deletes from users other than the original uploader. The `pubkey` encoded on the header value identifies the user. 264The `server` should reject deletes from users other than the original uploader with the appropriate http response code (403 Forbidden).
265 265
266It should be noted that more than one user may have uploaded the same file (with the same hash). In this case, a delete must not really delete the file but just remove the user's `pubkey` from the file owners list (considering the server keeps just one copy of the same file, because multiple uploads of the same file results 266It should be noted that more than one user may have uploaded the same file (with the same hash). In this case, a delete must not really delete the file but just remove the user's `pubkey` from the file owners list (considering the server keeps just one copy of the same file, because multiple uploads of the same file results
267in the same file hash). 267in the same file hash).
@@ -275,6 +275,46 @@ The successful response is a 200 OK one with just basic JSON fields:
275} 275}
276``` 276```
277 277
278## Listing files
279
280`GET $api_url?page=x&count=y`
281
282**AUTH required**
283
284Returns a list of files linked to the authenticated users pubkey.
285
286Example Response:
287
288```js
289{
290 "count": 1, // server page size, eg. max(1, min(server_max_page_size, arg_count))
291 "total": 1, // total number of files
292 "page": 0, // the current page number
293 "files": [
294 {
295 "tags": [
296 ["ox": "719171db19525d9d08dd69cb716a18158a249b7b3b3ec4bbdec5698dca104b7b"],
297 ["x": "5d2899290e0e69bcd809949ee516a4a1597205390878f780c098707a7f18e3df"],
298 ["size", "123456"],
299 ["alt", "a meme that makes you laugh"],
300 ["expiration", "1715691139"],
301 // ...other metadata
302 ]
303 "content": "haha funny meme", // caption
304 "created_at": 1715691130 // upload timestmap
305 },
306 ...
307 ]
308}
309```
310
311`files` contains an array of NIP-94 events
312
313### Query args
314
315- `page` page number (`offset=page*count`)
316- `count` number of items per page
317
278## Selecting a Server 318## Selecting a Server
279 319
280Note: HTTP File Storage Server developers may skip this section. This is meant for client developers. 320Note: HTTP File Storage Server developers may skip this section. This is meant for client developers.
diff --git a/BREAKING.md b/BREAKING.md
index 7b48ee0..c8255cd 100644
--- a/BREAKING.md
+++ b/BREAKING.md
@@ -5,6 +5,10 @@ reverse chronological order.
5 5
6| Date | Commit | NIP | Change | 6| Date | Commit | NIP | Change |
7| ----------- | --------- | -------- | ------ | 7| ----------- | --------- | -------- | ------ |
8| 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 |
9| 2024-06-06 | [a6dfc7b5](https://github.com/nostr-protocol/nips/commit/a6dfc7b5) | [NIP-55](55.md) | NIP number was changed |
10| 2024-05-25 | [5d1d1c17](https://github.com/nostr-protocol/nips/commit/5d1d1c17) | [NIP-71](71.md) | 'aes-256-gcm' tag was removed |
11| 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 |
8| 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) | 12| 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) |
9| 2024-02-25 | [4a171cb0](https://github.com/nostr-protocol/nips/commit/4a171cb0) | [NIP-18](18.md) | quote repost should use `q` tag | 13| 2024-02-25 | [4a171cb0](https://github.com/nostr-protocol/nips/commit/4a171cb0) | [NIP-18](18.md) | quote repost should use `q` tag |
10| 2024-02-21 | [c6cd655c](https://github.com/nostr-protocol/nips/commit/c6cd655c) | [NIP-46](46.md) | Params were stringified | 14| 2024-02-21 | [c6cd655c](https://github.com/nostr-protocol/nips/commit/c6cd655c) | [NIP-46](46.md) | Params were stringified |
@@ -19,8 +23,9 @@ reverse chronological order.
19| 2023-12-27 | [17c67ef5](https://github.com/nostr-protocol/nips/commit/17c67ef5) | [NIP-94](94.md) | 'aes-256-gcm' tag was removed | 23| 2023-12-27 | [17c67ef5](https://github.com/nostr-protocol/nips/commit/17c67ef5) | [NIP-94](94.md) | 'aes-256-gcm' tag was removed |
20| 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 | 24| 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 |
21| 2023-11-28 | [6de35f9e](https://github.com/nostr-protocol/nips/commit/6de35f9e) | [NIP-89](89.md) | 'client' tag value was changed | 25| 2023-11-28 | [6de35f9e](https://github.com/nostr-protocol/nips/commit/6de35f9e) | [NIP-89](89.md) | 'client' tag value was changed |
22| 2023-11-20 | [7822a8b1](https://github.com/nostr-protocol/nips/commit/7822a8b1) | [NIP-51](51.md) | `kind: 30000` and `kind: 30001` were deprecated | 26| 2023-11-20 | [7822a8b1](https://github.com/nostr-protocol/nips/commit/7822a8b1) | [NIP-51](51.md) | `kind: 30000` and `kind: 30001` were deprecated |
23| 2023-11-11 | [cbdca1e9](https://github.com/nostr-protocol/nips/commit/cbdca1e9) | [NIP-84](84.md) | 'range' tag was removed | 27| 2023-11-11 | [cbdca1e9](https://github.com/nostr-protocol/nips/commit/cbdca1e9) | [NIP-84](84.md) | 'range' tag was removed |
28| 2023-11-10 | [c945d8bd](https://github.com/nostr-protocol/nips/commit/c945d8bd) | [NIP-32](32.md) | 'l' tag annotations was removed |
24| 2023-11-07 | [108b7f16](https://github.com/nostr-protocol/nips/commit/108b7f16) | [NIP-01](01.md) | 'OK' message must have 4 items | 29| 2023-11-07 | [108b7f16](https://github.com/nostr-protocol/nips/commit/108b7f16) | [NIP-01](01.md) | 'OK' message must have 4 items |
25| 2023-10-17 | [cf672b76](https://github.com/nostr-protocol/nips/commit/cf672b76) | [NIP-03](03.md) | 'block' tag was removed | 30| 2023-10-17 | [cf672b76](https://github.com/nostr-protocol/nips/commit/cf672b76) | [NIP-03](03.md) | 'block' tag was removed |
26| 2023-09-29 | [7dc6385f](https://github.com/nostr-protocol/nips/commit/7dc6385f) | [NIP-57](57.md) | optional 'a' tag was included in `zap receipt` | 31| 2023-09-29 | [7dc6385f](https://github.com/nostr-protocol/nips/commit/7dc6385f) | [NIP-57](57.md) | optional 'a' tag was included in `zap receipt` |
@@ -33,10 +38,10 @@ reverse chronological order.
33| 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 | 38| 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 |
34| 2023-08-11 | [d87f8617](https://github.com/nostr-protocol/nips/commit/d87f8617) | [NIP-25](25.md) | empty `content` should be considered as "+" | 39| 2023-08-11 | [d87f8617](https://github.com/nostr-protocol/nips/commit/d87f8617) | [NIP-25](25.md) | empty `content` should be considered as "+" |
35| 2023-08-01 | [5d63b157](https://github.com/nostr-protocol/nips/commit/5d63b157) | [NIP-57](57.md) | 'zap' tag was changed | 40| 2023-08-01 | [5d63b157](https://github.com/nostr-protocol/nips/commit/5d63b157) | [NIP-57](57.md) | 'zap' tag was changed |
36| 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` | 41| 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` |
37| 2023-07-12 | [a1cd2bd8](https://github.com/nostr-protocol/nips/commit/a1cd2bd8) | [NIP-25](25.md) | custom emoji was supported | 42| 2023-07-12 | [a1cd2bd8](https://github.com/nostr-protocol/nips/commit/a1cd2bd8) | [NIP-25](25.md) | custom emoji was supported |
38| 2023-06-18 | [83cbd3e1](https://github.com/nostr-protocol/nips/commit/83cbd3e1) | [NIP-11](11.md) | 'image' was renamed to 'icon' | 43| 2023-06-18 | [83cbd3e1](https://github.com/nostr-protocol/nips/commit/83cbd3e1) | [NIP-11](11.md) | 'image' was renamed to 'icon' |
39| 2023-04-13 | [bf0a0da6](https://github.com/nostr-protocol/nips/commit/bf0a0da6) | [NIP-15](15.md) | different NIP was re-added as NIP-15 | 44| 2023-04-13 | [bf0a0da6](https://github.com/nostr-protocol/nips/commit/bf0a0da6) | [NIP-15](15.md) | different NIP was re-added as NIP-15 |
40| 2023-04-09 | [fb5b7c73](https://github.com/nostr-protocol/nips/commit/fb5b7c73) | [NIP-15](15.md) | NIP-15 was merged into NIP-01 | 45| 2023-04-09 | [fb5b7c73](https://github.com/nostr-protocol/nips/commit/fb5b7c73) | [NIP-15](15.md) | NIP-15 was merged into NIP-01 |
41| 2023-03-15 | [e1004d3d](https://github.com/nostr-protocol/nips/commit/e1004d3d) | [NIP-19](19.md) | `1: relay` was changed to optionally | 46| 2023-03-15 | [e1004d3d](https://github.com/nostr-protocol/nips/commit/e1004d3d) | [NIP-19](19.md) | `1: relay` was changed to optionally |
42 47
@@ -46,3 +51,4 @@ Breaking changes prior to 2023-03-01 are not yet documented.
46 51
47- If it isn't clear that a change is breaking or not, we list it. 52- If it isn't clear that a change is breaking or not, we list it.
48- The date is the date it was merged, not necessarily the date of the commit. 53- The date is the date it was merged, not necessarily the date of the commit.
54
diff --git a/README.md b/README.md
index 3209df9..99c4245 100644
--- a/README.md
+++ b/README.md
@@ -51,6 +51,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
51- [NIP-31: Dealing with Unknown Events](31.md) 51- [NIP-31: Dealing with Unknown Events](31.md)
52- [NIP-32: Labeling](32.md) 52- [NIP-32: Labeling](32.md)
53- [NIP-34: `git` stuff](34.md) 53- [NIP-34: `git` stuff](34.md)
54- [NIP-35: Torrents](35.md)
54- [NIP-36: Sensitive Content](36.md) 55- [NIP-36: Sensitive Content](36.md)
55- [NIP-38: User Statuses](38.md) 56- [NIP-38: User Statuses](38.md)
56- [NIP-39: External Identities in Profiles](39.md) 57- [NIP-39: External Identities in Profiles](39.md)
@@ -67,11 +68,13 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
67- [NIP-52: Calendar Events](52.md) 68- [NIP-52: Calendar Events](52.md)
68- [NIP-53: Live Activities](53.md) 69- [NIP-53: Live Activities](53.md)
69- [NIP-54: Wiki](54.md) 70- [NIP-54: Wiki](54.md)
71- [NIP-55: Android Signer Application](55.md)
70- [NIP-56: Reporting](56.md) 72- [NIP-56: Reporting](56.md)
71- [NIP-57: Lightning Zaps](57.md) 73- [NIP-57: Lightning Zaps](57.md)
72- [NIP-58: Badges](58.md) 74- [NIP-58: Badges](58.md)
73- [NIP-59: Gift Wrap](59.md) 75- [NIP-59: Gift Wrap](59.md)
74- [NIP-65: Relay List Metadata](65.md) 76- [NIP-65: Relay List Metadata](65.md)
77- [NIP-71: Video Events](71.md)
75- [NIP-72: Moderated Communities](72.md) 78- [NIP-72: Moderated Communities](72.md)
76- [NIP-75: Zap Goals](75.md) 79- [NIP-75: Zap Goals](75.md)
77- [NIP-78: Application-specific data](78.md) 80- [NIP-78: Application-specific data](78.md)
@@ -122,6 +125,9 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
122| `1971` | Problem Tracker | [nostrocket][nostrocket] | 125| `1971` | Problem Tracker | [nostrocket][nostrocket] |
123| `1984` | Reporting | [56](56.md) | 126| `1984` | Reporting | [56](56.md) |
124| `1985` | Label | [32](32.md) | 127| `1985` | Label | [32](32.md) |
128| `2003` | Torrent | [35](35.md) |
129| `2004` | Torrent Comment | [35](35.md) |
130| `2022` | Coinjoin Pool | [joinstr][joinstr] |
125| `4550` | Community Post Approval | [72](72.md) | 131| `4550` | Community Post Approval | [72](72.md) |
126| `5000`-`5999` | Job Request | [90](90.md) | 132| `5000`-`5999` | Job Request | [90](90.md) |
127| `6000`-`6999` | Job Result | [90](90.md) | 133| `6000`-`6999` | Job Result | [90](90.md) |
@@ -156,6 +162,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
156| `30002` | Relay sets | [51](51.md) | 162| `30002` | Relay sets | [51](51.md) |
157| `30003` | Bookmark sets | [51](51.md) | 163| `30003` | Bookmark sets | [51](51.md) |
158| `30004` | Curation sets | [51](51.md) | 164| `30004` | Curation sets | [51](51.md) |
165| `30005` | Video sets | [51](51.md) |
159| `30008` | Profile Badges | [58](58.md) | 166| `30008` | Profile Badges | [58](58.md) |
160| `30009` | Badge Definition | [58](58.md) | 167| `30009` | Badge Definition | [58](58.md) |
161| `30015` | Interest sets | [51](51.md) | 168| `30015` | Interest sets | [51](51.md) |
@@ -175,17 +182,23 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
175| `30617` | Repository announcements | [34](34.md) | 182| `30617` | Repository announcements | [34](34.md) |
176| `30818` | Wiki article | [54](54.md) | 183| `30818` | Wiki article | [54](54.md) |
177| `30819` | Redirects | [54](54.md) | 184| `30819` | Redirects | [54](54.md) |
185| `31890` | Feed | [NUD: Custom Feeds](https://wikifreedia.xyz/cip-01/97c70a44366a6535c1) |
178| `31922` | Date-Based Calendar Event | [52](52.md) | 186| `31922` | Date-Based Calendar Event | [52](52.md) |
179| `31923` | Time-Based Calendar Event | [52](52.md) | 187| `31923` | Time-Based Calendar Event | [52](52.md) |
180| `31924` | Calendar | [52](52.md) | 188| `31924` | Calendar | [52](52.md) |
181| `31925` | Calendar Event RSVP | [52](52.md) | 189| `31925` | Calendar Event RSVP | [52](52.md) |
182| `31989` | Handler recommendation | [89](89.md) | 190| `31989` | Handler recommendation | [89](89.md) |
183| `31990` | Handler information | [89](89.md) | 191| `31990` | Handler information | [89](89.md) |
192| `34235` | Video Event | [71](71.md) |
193| `34236` | Short-form Portrait Video Event | [71](71.md) |
194| `34237` | Video View Event | [71](71.md) |
184| `34550` | Community Definition | [72](72.md) | 195| `34550` | Community Definition | [72](72.md) |
185| `39000-9` | Group metadata events | [29](29.md) | 196| `39000-9` | Group metadata events | [29](29.md) |
186 197
198[NUD: Custom Feeds]: https://wikifreedia.xyz/cip-01/97c70a44366a6535c1
187[nostrocket]: https://github.com/nostrocket/NIPS/blob/main/Problems.md 199[nostrocket]: https://github.com/nostrocket/NIPS/blob/main/Problems.md
188[lnpub]: https://github.com/shocknet/Lightning.Pub/blob/master/proto/autogenerated/client.md 200[lnpub]: https://github.com/shocknet/Lightning.Pub/blob/master/proto/autogenerated/client.md
201[joinstr]: https://gitlab.com/1440000bytes/joinstr/-/blob/main/NIP.md
189 202
190## Message types 203## Message types
191 204
@@ -211,62 +224,62 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
211| `AUTH` | used to send authentication challenges | [42](42.md) | 224| `AUTH` | used to send authentication challenges | [42](42.md) |
212| `COUNT` | used to send requested event counts to clients | [45](45.md) | 225| `COUNT` | used to send requested event counts to clients | [45](45.md) |
213 226
214Please update these lists when proposing NIPs introducing new event kinds.
215
216## Standardized Tags 227## Standardized Tags
217 228
218| name | value | other parameters | NIP | 229| name | value | other parameters | NIP |
219| ----------------- | ------------------------------------ | -------------------- | ------------------------------------- | 230| ----------------- | ------------------------------------ | ------------------------------- | ------------------------------------- |
220| `e` | event id (hex) | relay URL, marker | [01](01.md), [10](10.md) | 231| `e` | event id (hex) | relay URL, marker, pubkey (hex) | [01](01.md), [10](10.md) |
221| `p` | pubkey (hex) | relay URL, petname | [01](01.md), [02](02.md) | 232| `p` | pubkey (hex) | relay URL, petname | [01](01.md), [02](02.md) |
222| `a` | coordinates to an event | relay URL | [01](01.md) | 233| `a` | coordinates to an event | relay URL | [01](01.md) |
223| `d` | identifier | -- | [01](01.md) | 234| `d` | identifier | -- | [01](01.md) |
224| `g` | geohash | -- | [52](52.md) | 235| `g` | geohash | -- | [52](52.md) |
225| `i` | identity | proof | [39](39.md) | 236| `i` | identity | proof | [39](39.md) |
226| `k` | kind number (string) | -- | [18](18.md), [25](25.md), [72](72.md) | 237| `k` | kind number (string) | -- | [18](18.md), [25](25.md), [72](72.md) |
227| `l` | label, label namespace | annotations | [32](32.md) | 238| `l` | label, label namespace | -- | [32](32.md) |
228| `L` | label namespace | -- | [32](32.md) | 239| `L` | label namespace | -- | [32](32.md) |
229| `m` | MIME type | -- | [94](94.md) | 240| `m` | MIME type | -- | [94](94.md) |
230| `q` | event id (hex) | relay URL | [18](18.md) | 241| `q` | event id (hex) | relay URL | [18](18.md) |
231| `r` | a reference (URL, etc) | petname | | 242| `r` | a reference (URL, etc) | petname | [24](24.md) |
232| `r` | relay url | marker | [65](65.md) | 243| `r` | relay url | marker | [65](65.md) |
233| `t` | hashtag | -- | | 244| `t` | hashtag | -- | |
234| `alt` | summary | -- | [31](31.md) | 245| `alt` | summary | -- | [31](31.md) |
235| `amount` | millisatoshis, stringified | -- | [57](57.md) | 246| `amount` | millisatoshis, stringified | -- | [57](57.md) |
236| `bolt11` | `bolt11` invoice | -- | [57](57.md) | 247| `bolt11` | `bolt11` invoice | -- | [57](57.md) |
237| `challenge` | challenge string | -- | [42](42.md) | 248| `challenge` | challenge string | -- | [42](42.md) |
238| `client` | name, address | relay URL | [89](89.md) | 249| `client` | name, address | relay URL | [89](89.md) |
239| `clone` | git clone URL | -- | [34](34.md) | 250| `clone` | git clone URL | -- | [34](34.md) |
240| `content-warning` | reason | -- | [36](36.md) | 251| `content-warning` | reason | -- | [36](36.md) |
241| `delegation` | pubkey, conditions, delegation token | -- | [26](26.md) | 252| `delegation` | pubkey, conditions, delegation token | -- | [26](26.md) |
242| `description` | description | -- | [34](34.md), [57](57.md), [58](58.md) | 253| `description` | description | -- | [34](34.md), [57](57.md), [58](58.md) |
243| `emoji` | shortcode, image URL | -- | [30](30.md) | 254| `emoji` | shortcode, image URL | -- | [30](30.md) |
244| `encrypted` | -- | -- | [90](90.md) | 255| `encrypted` | -- | -- | [90](90.md) |
245| `expiration` | unix timestamp (string) | -- | [40](40.md) | 256| `expiration` | unix timestamp (string) | -- | [40](40.md) |
246| `goal` | event id (hex) | relay URL | [75](75.md) | 257| `goal` | event id (hex) | relay URL | [75](75.md) |
247| `image` | image URL | dimensions in pixels | [23](23.md), [58](58.md) | 258| `image` | image URL | dimensions in pixels | [23](23.md), [58](58.md) |
248| `imeta` | inline metadata | -- | [92](92.md) | 259| `imeta` | inline metadata | -- | [92](92.md) |
249| `lnurl` | `bech32` encoded `lnurl` | -- | [57](57.md) | 260| `lnurl` | `bech32` encoded `lnurl` | -- | [57](57.md) |
250| `location` | location string | -- | [52](52.md), [99](99.md) | 261| `location` | location string | -- | [52](52.md), [99](99.md) |
251| `name` | name | -- | [34](34.md), [58](58.md) | 262| `name` | name | -- | [34](34.md), [58](58.md) |
252| `nonce` | random | -- | [13](13.md) | 263| `nonce` | random | difficulty | [13](13.md) |
253| `preimage` | hash of `bolt11` invoice | -- | [57](57.md) | 264| `preimage` | hash of `bolt11` invoice | -- | [57](57.md) |
254| `price` | price | currency, frequency | [99](99.md) | 265| `price` | price | currency, frequency | [99](99.md) |
255| `proxy` | external ID | protocol | [48](48.md) | 266| `proxy` | external ID | protocol | [48](48.md) |
256| `published_at` | unix timestamp (string) | -- | [23](23.md) | 267| `published_at` | unix timestamp (string) | -- | [23](23.md) |
257| `relay` | relay url | -- | [42](42.md), [17](17.md) | 268| `relay` | relay url | -- | [42](42.md), [17](17.md) |
258| `relays` | relay list | -- | [57](57.md) | 269| `relays` | relay list | -- | [57](57.md) |
259| `server` | file storage server url | -- | [96](96.md) | 270| `server` | file storage server url | -- | [96](96.md) |
260| `subject` | subject | -- | [14](14.md), [17](17.md) | 271| `subject` | subject | -- | [14](14.md), [17](17.md) |
261| `summary` | article summary | -- | [23](23.md) | 272| `summary` | article summary | -- | [23](23.md) |
262| `thumb` | badge thumbnail | dimensions in pixels | [58](58.md) | 273| `thumb` | badge thumbnail | dimensions in pixels | [58](58.md) |
263| `title` | article title | -- | [23](23.md) | 274| `title` | article title | -- | [23](23.md) |
264| `web` | webpage URL | -- | [34](34.md) | 275| `web` | webpage URL | -- | [34](34.md) |
265| `zap` | pubkey (hex), relay URL | weight | [57](57.md) | 276| `zap` | pubkey (hex), relay URL | weight | [57](57.md) |
277
278Please update these lists when proposing new NIPs.
266 279
267## Criteria for acceptance of NIPs 280## Criteria for acceptance of NIPs
268 281
2691. They should be implemented in at least two clients and one relay -- when applicable. 2821. They should be fully implemented in at least two clients and one relay -- when applicable.
2702. They should make sense. 2832. They should make sense.
2713. They should be optional and backwards-compatible: care must be taken such that clients and relays that choose to not implement them do not stop working when interacting with the ones that choose to. 2843. They should be optional and backwards-compatible: care must be taken such that clients and relays that choose to not implement them do not stop working when interacting with the ones that choose to.
2724. There should be no more than one way of doing the same thing. 2854. There should be no more than one way of doing the same thing.
generated by cgit v1.2.3 (git 2.39.1) at 2026-06-05 06:41:09 +0000