diff options
| -rw-r--r-- | 10.md | 4 | ||||
| -rw-r--r-- | 24.md | 2 | ||||
| -rw-r--r-- | 32.md | 8 | ||||
| -rw-r--r-- | 47.md | 6 | ||||
| -rw-r--r-- | 59.md | 2 | ||||
| -rw-r--r-- | 71.md | 120 | ||||
| -rw-r--r-- | README.md | 7 |
7 files changed, 143 insertions, 6 deletions
| @@ -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 | ||
| 43 | Where: | 43 | Where: |
| 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 | ||
| 49 | Those 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 | Those 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 |
| 57 | Used in a text event contains a list of pubkeys used to record who is involved in a reply thread. | 59 | Used in a text event contains a list of pubkeys used to record who is involved in a reply thread. |
| @@ -40,4 +40,4 @@ tags | |||
| 40 | These tags may be present in multiple event kinds. Whenever a different meaning is not specified by some more specific NIP, they have the following meanings: | 40 | These tags may be present in multiple event kinds. Whenever a different meaning is not specified by some more specific NIP, they have the following meanings: |
| 41 | 41 | ||
| 42 | - `r`: a web URL the event is referring to in some way | 42 | - `r`: a web URL the event is referring to in some way |
| 43 | - `title`: title of the event | 43 | - `title`: name of [NIP-51](51.md) sets, [NIP-52](52.md) calendar event, [NIP-53](53.md) live event or [NIP-99](99.md) listing |
| @@ -151,3 +151,11 @@ A good heuristic for whether a use case fits this NIP is whether labels would ev | |||
| 151 | For example, many events might be labeled with a particular place, topic, or pubkey, but labels | 151 | For example, many events might be labeled with a particular place, topic, or pubkey, but labels |
| 152 | with specific values like "John Doe" or "3.18743" are not labels, they are values, and should | 152 | with specific values like "John Doe" or "3.18743" are not labels, they are values, and should |
| 153 | be handled in some other way. | 153 | be handled in some other way. |
| 154 | |||
| 155 | |||
| 156 | Appendix: Known Ontologies | ||
| 157 | ------------------------- | ||
| 158 | |||
| 159 | Below is a non-exhaustive list of ontologies currently in widespread use. | ||
| 160 | |||
| 161 | - (social.ontolo.categories)[https://ontolo.social/] | ||
| @@ -81,7 +81,7 @@ If the command was successful, the `error` field must be null. | |||
| 81 | ## Nostr Wallet Connect URI | 81 | ## Nostr Wallet Connect URI |
| 82 | **client** discovers **wallet service** by scanning a QR code, handling a deeplink or pasting in a URI. | 82 | **client** discovers **wallet service** by scanning a QR code, handling a deeplink or pasting in a URI. |
| 83 | 83 | ||
| 84 | 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: | 84 | 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: |
| 85 | 85 | ||
| 86 | - `relay` Required. URL of the relay where the **wallet service** is connected and will be listening for events. May be more than one. | 86 | - `relay` Required. URL of the relay where the **wallet service** is connected and will be listening for events. May be more than one. |
| 87 | - `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**. | 87 | - `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**. |
| @@ -95,7 +95,7 @@ The **client** should then store this connection and use it when the user wants | |||
| 95 | 95 | ||
| 96 | ### Example connection string | 96 | ### Example connection string |
| 97 | ```sh | 97 | ```sh |
| 98 | nostr+walletconnect:b889ff5b1513b641e2a139f661a661364979c5beee91842f8f0ef42ab558e9d4?relay=wss%3A%2F%2Frelay.damus.io&secret=71a8c14c1407c113601079c4302dab36460f0ccd0ad506f1f2dc73b5100e4f3c | 98 | nostr+walletconnect://b889ff5b1513b641e2a139f661a661364979c5beee91842f8f0ef42ab558e9d4?relay=wss%3A%2F%2Frelay.damus.io&secret=71a8c14c1407c113601079c4302dab36460f0ccd0ad506f1f2dc73b5100e4f3c |
| 99 | ``` | 99 | ``` |
| 100 | 100 | ||
| 101 | ## Commands | 101 | ## Commands |
| @@ -402,7 +402,7 @@ Response: | |||
| 402 | 402 | ||
| 403 | ## Example pay invoice flow | 403 | ## Example pay invoice flow |
| 404 | 404 | ||
| 405 | 0. The user scans the QR code generated by the **wallet service** with their **client** application, they follow a `nostr+walletconnect:` deeplink or configure the connection details manually. | 405 | 0. The user scans the QR code generated by the **wallet service** with their **client** application, they follow a `nostr+walletconnect://` deeplink or configure the connection details manually. |
| 406 | 1. **client** sends an event to the **wallet service** with kind `23194`. The content is a `pay_invoice` request. The private key is the secret from the connection string above. | 406 | 1. **client** sends an event to the **wallet service** with kind `23194`. The content is a `pay_invoice` request. The private key is the secret from the connection string above. |
| 407 | 2. **wallet service** verifies that the author's key is authorized to perform the payment, decrypts the payload and sends the payment. | 407 | 2. **wallet service** verifies that the author's key is authorized to perform the payment, decrypts the payload and sends the payment. |
| 408 | 3. **wallet service** responds to the event by sending an event with kind `23195` and content being a response either containing an error message or a preimage. | 408 | 3. **wallet service** responds to the event by sending an event with kind `23195` and content being a response either containing an error message or a preimage. |
| @@ -155,7 +155,7 @@ Sign the `gift wrap` using the random key generated in the previous step. | |||
| 155 | "created_at": 1703021488, | 155 | "created_at": 1703021488, |
| 156 | "pubkey": "18b1a75918f1f2c90c23da616bce317d36e348bcf5f7ba55e75949319210c87c", | 156 | "pubkey": "18b1a75918f1f2c90c23da616bce317d36e348bcf5f7ba55e75949319210c87c", |
| 157 | "id": "5c005f3ccf01950aa8d131203248544fb1e41a0d698e846bd419cec3890903ac", | 157 | "id": "5c005f3ccf01950aa8d131203248544fb1e41a0d698e846bd419cec3890903ac", |
| 158 | "sig": "35fabdae4634eb630880a1896a886e40fd6ea8a60958e30b89b33a93e6235df750097b04f9e13053764251b8bc5dd7e8e0794a3426a90b6bcc7e5ff660f54259" | 158 | "sig": "35fabdae4634eb630880a1896a886e40fd6ea8a60958e30b89b33a93e6235df750097b04f9e13053764251b8bc5dd7e8e0794a3426a90b6bcc7e5ff660f54259", |
| 159 | "tags": [["p", "166bf3765ebd1fc55decfe395beff2ea3b2a4e0a8946e7eb578512b555737c99"]], | 159 | "tags": [["p", "166bf3765ebd1fc55decfe395beff2ea3b2a4e0a8946e7eb578512b555737c99"]], |
| 160 | } | 160 | } |
| 161 | ``` | 161 | ``` |
| @@ -0,0 +1,120 @@ | |||
| 1 | NIP-71 | ||
| 2 | ====== | ||
| 3 | |||
| 4 | Video Events | ||
| 5 | --------------- | ||
| 6 | |||
| 7 | `draft` `optional` | ||
| 8 | |||
| 9 | This 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 | |||
| 11 | Unlike 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 | |||
| 15 | There 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 | |||
| 19 | The format uses a parameterized replaceable event kind `34235` for horizontal videos and `34236` for vertical videos. | ||
| 20 | |||
| 21 | The `.content` of these events is a summary or description on the video content. | ||
| 22 | |||
| 23 | The 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 | * `"aes-256-gcm"` (optional) key and nonce for AES-GCM encryption with tagSize always 128bits | ||
| 30 | * `x` containing the SHA-256 hexencoded string of the file. | ||
| 31 | * `size` (optional) size of file in bytes | ||
| 32 | * `dim` (optional) size of file in pixels in the form `<width>x<height>` | ||
| 33 | * `duration` (optional) video duration in seconds | ||
| 34 | * `magnet` (optional) URI to magnet file | ||
| 35 | * `i` (optional) torrent infohash | ||
| 36 | * `text-track` (optional, repeated) link to WebVTT file for video, type of supplementary information (captions/subtitles/chapters/metadata), optional language code | ||
| 37 | * `thumb` (optional) url of thumbnail with same aspect ratio | ||
| 38 | * `image` (optional) url of preview image with same dimensions | ||
| 39 | * `content-warning` (optional) warning about content of NSFW video | ||
| 40 | * `alt` (optional) description for accessibility | ||
| 41 | * `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 | ||
| 42 | * `t` (optional, repeated) hashtag to categorize video | ||
| 43 | * `p` (optional, repeated) 32-bytes hex pubkey of a participant in the video, optional recommended relay URL | ||
| 44 | * `r` (optional, repeated) references / links to web pages | ||
| 45 | |||
| 46 | ```json | ||
| 47 | { | ||
| 48 | "id": <32-bytes lowercase hex-encoded SHA-256 of the the serialized event data>, | ||
| 49 | "pubkey": <32-bytes lowercase hex-encoded public key of the event creator>, | ||
| 50 | "created_at": <Unix timestamp in seconds>, | ||
| 51 | "kind": 34235 | 34236, | ||
| 52 | "content": "<summary / description of video>", | ||
| 53 | "tags": [ | ||
| 54 | ["d", "<UUID>"], | ||
| 55 | |||
| 56 | ["title", "<title of video>"], | ||
| 57 | ["thumb", "<thumbnail image for video>"], | ||
| 58 | ["published_at", "<unix timestamp>"], | ||
| 59 | ["alt", <description>], | ||
| 60 | |||
| 61 | // Video Data | ||
| 62 | ["url",<string with URI of file>], | ||
| 63 | ["m", <MIME type>], | ||
| 64 | ["x",<Hash SHA-256>], | ||
| 65 | ["aes-256-gcm",<key>, <iv>], | ||
| 66 | ["size", <size of file in bytes>], | ||
| 67 | ["duration", <duration of video in seconds>], | ||
| 68 | ["dim", <size of file in pixels>], | ||
| 69 | ["magnet",<magnet URI> ], | ||
| 70 | ["i",<torrent infohash>], | ||
| 71 | ["text-track", "<encoded `kind 6000` event>", "<recommended relay urls>"], | ||
| 72 | ["content-warning", "<reason>"], | ||
| 73 | ["segment", <start>, <end>, "<title>", "<thumbnail URL>"], | ||
| 74 | |||
| 75 | // Participants | ||
| 76 | ["p", "<32-bytes hex of a pubkey>", "<optional recommended relay URL>"], | ||
| 77 | ["p", "<32-bytes hex of a pubkey>", "<optional recommended relay URL>"], | ||
| 78 | |||
| 79 | // Hashtags | ||
| 80 | ["t", "<tag>"], | ||
| 81 | ["t", "<tag>"], | ||
| 82 | |||
| 83 | // Reference links | ||
| 84 | ["r", "<url>"], | ||
| 85 | ["r", "<url>"] | ||
| 86 | ] | ||
| 87 | } | ||
| 88 | ``` | ||
| 89 | |||
| 90 | ## Video View | ||
| 91 | |||
| 92 | A video event view is a response to a video event to track a user's view or progress viewing the video. | ||
| 93 | |||
| 94 | ### Format | ||
| 95 | |||
| 96 | The format uses a parameterized replaceable event kind `34237`. | ||
| 97 | |||
| 98 | The `.content` of these events is optional and could be a free-form note that acts like a bookmark for the user. | ||
| 99 | |||
| 100 | The list of tags are as follows: | ||
| 101 | * `a` (required) reference tag to kind `34235` or `34236` video event being viewed | ||
| 102 | * `d` (required) same as `a` reference tag value | ||
| 103 | * `viewed` (optional, repeated) timestamp of the user's start time in seconds, timestamp of the user's end time in seconds | ||
| 104 | |||
| 105 | |||
| 106 | ```json | ||
| 107 | { | ||
| 108 | "id": <32-bytes lowercase hex-encoded SHA-256 of the the serialized event data>, | ||
| 109 | "pubkey": <32-bytes lowercase hex-encoded public key of the event creator>, | ||
| 110 | "created_at": <Unix timestamp in seconds>, | ||
| 111 | "kind": 34237, | ||
| 112 | "content": "<note>", | ||
| 113 | "tags": [ | ||
| 114 | ["a", "<34235 | 34236>:<video event author pubkey>:<d-identifier of video event>", "<optional relay url>"], | ||
| 115 | ["e", "<event-id", "<relay-url>"] | ||
| 116 | ["d", "<34235 | 34236>:<video event author pubkey>:<d-identifier of video event>"], | ||
| 117 | ["viewed", <start>, <end>], | ||
| 118 | ] | ||
| 119 | } | ||
| 120 | ``` | ||
| @@ -72,6 +72,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos | |||
| 72 | - [NIP-58: Badges](58.md) | 72 | - [NIP-58: Badges](58.md) |
| 73 | - [NIP-59: Gift Wrap](59.md) | 73 | - [NIP-59: Gift Wrap](59.md) |
| 74 | - [NIP-65: Relay List Metadata](65.md) | 74 | - [NIP-65: Relay List Metadata](65.md) |
| 75 | - [NIP-71: Video Events](71.md) | ||
| 75 | - [NIP-72: Moderated Communities](72.md) | 76 | - [NIP-72: Moderated Communities](72.md) |
| 76 | - [NIP-75: Zap Goals](75.md) | 77 | - [NIP-75: Zap Goals](75.md) |
| 77 | - [NIP-78: Application-specific data](78.md) | 78 | - [NIP-78: Application-specific data](78.md) |
| @@ -108,6 +109,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos | |||
| 108 | | `42` | Channel Message | [28](28.md) | | 109 | | `42` | Channel Message | [28](28.md) | |
| 109 | | `43` | Channel Hide Message | [28](28.md) | | 110 | | `43` | Channel Hide Message | [28](28.md) | |
| 110 | | `44` | Channel Mute User | [28](28.md) | | 111 | | `44` | Channel Mute User | [28](28.md) | |
| 112 | | `818` | Merge Requests | [54](54.md) | | ||
| 111 | | `1021` | Bid | [15](15.md) | | 113 | | `1021` | Bid | [15](15.md) | |
| 112 | | `1022` | Bid confirmation | [15](15.md) | | 114 | | `1022` | Bid confirmation | [15](15.md) | |
| 113 | | `1040` | OpenTimestamps | [03](03.md) | | 115 | | `1040` | OpenTimestamps | [03](03.md) | |
| @@ -157,6 +159,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos | |||
| 157 | | `30002` | Relay sets | [51](51.md) | | 159 | | `30002` | Relay sets | [51](51.md) | |
| 158 | | `30003` | Bookmark sets | [51](51.md) | | 160 | | `30003` | Bookmark sets | [51](51.md) | |
| 159 | | `30004` | Curation sets | [51](51.md) | | 161 | | `30004` | Curation sets | [51](51.md) | |
| 162 | | `30005` | Video sets | [51](51.md) | | ||
| 160 | | `30008` | Profile Badges | [58](58.md) | | 163 | | `30008` | Profile Badges | [58](58.md) | |
| 161 | | `30009` | Badge Definition | [58](58.md) | | 164 | | `30009` | Badge Definition | [58](58.md) | |
| 162 | | `30015` | Interest sets | [51](51.md) | | 165 | | `30015` | Interest sets | [51](51.md) | |
| @@ -175,12 +178,16 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos | |||
| 175 | | `30403` | Draft Classified Listing | [99](99.md) | | 178 | | `30403` | Draft Classified Listing | [99](99.md) | |
| 176 | | `30617` | Repository announcements | [34](34.md) | | 179 | | `30617` | Repository announcements | [34](34.md) | |
| 177 | | `30818` | Wiki article | [54](54.md) | | 180 | | `30818` | Wiki article | [54](54.md) | |
| 181 | | `30819` | Redirects | [54](54.md) | | ||
| 178 | | `31922` | Date-Based Calendar Event | [52](52.md) | | 182 | | `31922` | Date-Based Calendar Event | [52](52.md) | |
| 179 | | `31923` | Time-Based Calendar Event | [52](52.md) | | 183 | | `31923` | Time-Based Calendar Event | [52](52.md) | |
| 180 | | `31924` | Calendar | [52](52.md) | | 184 | | `31924` | Calendar | [52](52.md) | |
| 181 | | `31925` | Calendar Event RSVP | [52](52.md) | | 185 | | `31925` | Calendar Event RSVP | [52](52.md) | |
| 182 | | `31989` | Handler recommendation | [89](89.md) | | 186 | | `31989` | Handler recommendation | [89](89.md) | |
| 183 | | `31990` | Handler information | [89](89.md) | | 187 | | `31990` | Handler information | [89](89.md) | |
| 188 | | `34235` | Video Event | [71](71.md) | | ||
| 189 | | `34236` | Short-form Portrait Video Event | [71](71.md) | | ||
| 190 | | `34237` | Video View Event | [71](71.md) | | ||
| 184 | | `34550` | Community Definition | [72](72.md) | | 191 | | `34550` | Community Definition | [72](72.md) | |
| 185 | | `39000-9` | Group metadata events | [29](29.md) | | 192 | | `39000-9` | Group metadata events | [29](29.md) | |
| 186 | 193 | ||