draft NIP-54 podcasts NIP.

README: add q tag

01.md

@@ -14,7 +14,7 @@ Each user has a keypair. Signatures, public key, and encodings are done accordin
 
 The only object type that exists is the `event`, which has the following format on the wire:
 
-```json
+```jsonc
 {
   "id": <32-bytes lowercase hex-encoded sha256 of the serialized event data>,
   "pubkey": <32-bytes lowercase hex-encoded public key of the event creator>,
@@ -22,7 +22,7 @@ The only object type that exists is the `event`, which has the following format
   "kind": <integer between 0 and 65535>,
   "tags": [
     [<arbitrary string>...],
-    ...
+    // ...
   ],
   "content": <arbitrary string>,
   "sig": <64-bytes lowercase hex of the signature of the sha256 hash of the serialized event data, which is the same as the "id" field>
@@ -58,17 +58,16 @@ To prevent implementation differences from creating a different event ID for the
 
 Each tag is an array of strings of arbitrary size, with some conventions around them. Take a look at the example below:
 
-```json
+```jsonc
 {
-  ...,
   "tags": [
     ["e", "5c83da77af1dec6d7289834998ad7aafbd9e2191396d75ec3cc27f5a77226f36", "wss://nostr.example.com"],
     ["p", "f7234bd4c1394dda46d09f35bd384dd30cc552ad5541990f98844fb06676e9ca"],
     ["a", "30023:f7234bd4c1394dda46d09f35bd384dd30cc552ad5541990f98844fb06676e9ca:abcd", "wss://nostr.example.com"],
     ["alt", "reply"],
-    ...
+    // ...
   ],
-  ...
+  // ...
 }
 ```
 
@@ -125,7 +124,7 @@ Clients can send 3 types of messages, which must be JSON arrays, according to th
   "ids": <a list of event ids>,
   "authors": <a list of lowercase pubkeys, the pubkey of an event must be one of these>,
   "kinds": <a list of a kind numbers>,
-  "#<single-letter (a-zA-Z)>": <a list of tag values, for #e — a list of event ids, for #p — a list of event pubkeys etc>,
+  "#<single-letter (a-zA-Z)>": <a list of tag values, for #e — a list of event ids, for #p — a list of pubkeys, etc.>,
   "since": <an integer unix timestamp in seconds, events must be newer than this to pass>,
   "until": <an integer unix timestamp in seconds, events must be older than this to pass>,
   "limit": <maximum number of events relays SHOULD return in the initial query>
@@ -148,7 +147,7 @@ The `limit` property of a filter is only valid for the initial query and MUST be
 
 ### From relay to client: sending events and notices
 
-Relays can send 4 types of messages, which must also be JSON arrays, according to the following patterns:
+Relays can send 5 types of messages, which must also be JSON arrays, according to the following patterns:
 
   * `["EVENT", <subscription_id>, <event JSON as defined above>]`, used to send events requested by clients.
   * `["OK", <event_id>, <true|false>, <message>]`, used to indicate acceptance or denial of an `EVENT` message.

07.md

@@ -20,6 +20,8 @@ Aside from these two basic above, the following functions can also be implemente
 async window.nostr.getRelays(): { [url: string]: {read: boolean, write: boolean} } // returns a basic map of relay urls to relay policies
 async window.nostr.nip04.encrypt(pubkey, plaintext): string // returns ciphertext and iv as specified in nip-04 (deprecated)
 async window.nostr.nip04.decrypt(pubkey, ciphertext): string // takes ciphertext and iv as specified in nip-04 (deprecated)
+async window.nostr.nip44.encrypt(pubkey, plaintext): string // returns ciphertext as specified in nip-44
+async window.nostr.nip44.decrypt(pubkey, ciphertext): string // takes ciphertext as specified in nip-44
 ```
 
 ### Implementation

15.md

@@ -56,7 +56,7 @@ A merchant can publish these events:
       "id": <string, id of the shipping zone, generated by the merchant>,
       "name": <string (optional), zone name>,
       "cost": <float, base cost for shipping. The currency is defined at the stall level>,
-      "regions": [<string, regions included in this zone>],
+      "regions": [<string, regions included in this zone>]
     }
   ]
 }
@@ -101,7 +101,7 @@ Fields that are not self-explanatory:
   "shipping": [
     {
       "id": <string, id of the shipping zone (must match one of the zones defined for the stall)>,
-      "cost": <float, extra cost for shipping. The currency is defined at the stall level>,
+      "cost": <float, extra cost for shipping. The currency is defined at the stall level>
     }
   ]
 }
@@ -139,7 +139,7 @@ Fields that are not self-explanatory:
 
 ## Checkout events
 
-All checkout events are sent as JSON strings using ([NIP04](https://github.com/nostr-protocol/nips/blob/master/04.md)).
+All checkout events are sent as JSON strings using ([NIP-04](https://github.com/nostr-protocol/nips/blob/master/04.md)).
 
 The `merchant` and the `customer` can exchange JSON messages that represent different actions. Each `JSON` message `MUST` have a `type` field indicating the what the JSON represents. Possible types:
 
@@ -150,19 +150,19 @@ The `merchant` and the `customer` can exchange JSON messages that represent diff
 | 2            | Merchant | Order Status Update |
 
 ### Step 1: `customer` order (event)
-The below json goes in content of [NIP04](https://github.com/nostr-protocol/nips/blob/master/04.md).
+The below JSON goes in content of [NIP-04](https://github.com/nostr-protocol/nips/blob/master/04.md).
 
 ```json
 {
   "id": <string, id generated by the customer>,
   "type": 0,
   "name": <string (optional), ???>,
-  "address": <string (optional), for physical goods an address should be provided>
+  "address": <string (optional), for physical goods an address should be provided>,
   "message": "<string (optional), message for merchant>,
   "contact": {
     "nostr": <32-bytes hex of a pubkey>,
     "phone": <string (optional), if the customer wants to be contacted by phone>,
-    "email": <string (optional), if the customer wants to be contacted by email>,
+    "email": <string (optional), if the customer wants to be contacted by email>
   },
   "items": [
     {
@@ -182,7 +182,7 @@ _Open_: is `contact.nostr` required?
 
 Sent back from the merchant for payment. Any payment option is valid that the merchant can check.
 
-The below json goes in `content` of [NIP04](https://github.com/nostr-protocol/nips/blob/master/04.md).
+The below JSON goes in `content` of [NIP-04](https://github.com/nostr-protocol/nips/blob/master/04.md).
 
 `payment_options`/`type` include:
 
@@ -217,7 +217,7 @@ The below json goes in `content` of [NIP04](https://github.com/nostr-protocol/ni
 
 Once payment has been received and processed.
 
-The below json goes in `content` of [NIP04](https://github.com/nostr-protocol/nips/blob/master/04.md).
+The below JSON goes in `content` of [NIP-04](https://github.com/nostr-protocol/nips/blob/master/04.md).
 
 ```json
 {
@@ -275,7 +275,7 @@ This event leverages naddr to enable comprehensive customization and sharing of
     "shipping": [
         {
             "id": <String, UUID of the shipping zone. Must match one of the zones defined for the stall>,
-            "cost": <float, extra cost for shipping. The currency is defined at the stall level>,
+            "cost": <float, extra cost for shipping. The currency is defined at the stall level>
         }
     ]
 }
@@ -310,7 +310,7 @@ Bids are simply events of kind `1021` with a `content` field specifying the amou
 {
     "status": <String, "accepted" | "rejected" | "pending" | "winner">,
     "message": <String (optional)>,
-    "duration_extended": <int (optional), number of seconds>,
+    "duration_extended": <int (optional), number of seconds>
 }
 ```
 

18.md

@@ -20,9 +20,10 @@ reposted.
 
 ## Quote Reposts
 
-Quote reposts are `kind 1` events with an embedded `e` tag
-(see [NIP-08](08.md) and [NIP-27](27.md)). Because a quote repost includes
-an `e` tag, it may show up along replies to the reposted note.
+Quote reposts are `kind 1` events with an embedded `q` tag of the note being
+quote reposted. The `q` tag ensures quote reposts are not pulled and included
+as replies in threads. It also allows you to easily pull and count all of the
+quotes for a post.
 
 ## Generic Reposts
 

30.md

@@ -6,7 +6,7 @@ Custom Emoji
 
 `draft` `optional`
 
-Custom emoji may be added to **kind 0** and **kind 1** events by including one or more `"emoji"` tags, in the form:
+Custom emoji may be added to **kind 0**, **kind 1**, **kind 7** ([NIP-25](25.md)) and **kind 30315** ([NIP-38](38.md)) events by including one or more `"emoji"` tags, in the form:
 
 ```
 ["emoji", <shortcode>, <image-url>]

46.md

@@ -1,99 +1,222 @@
-NIP-46
-======
+# NIP-46 - Nostr Remote Signing
 
-Nostr Connect
--------------
+## Rationale
 
-`draft` `optional`
+Private keys should be exposed to as few systems - apps, operating systems, devices - as possible as each system adds to the attack surface.
 
-This NIP describes a method for 2-way communication between a **remote signer** and a normal Nostr client. The remote signer could be, for example, a hardware device dedicated to signing Nostr events, while the client is a normal Nostr client.
+This NIP describes a method for 2-way communication between a remote signer and a Nostr client. The remote signer could be, for example, a hardware device dedicated to signing Nostr events, while the client is a normal Nostr client.
 
-## Signer Discovery
+## Terminology
 
-The client always starts by generating a random key which is used to communicate with the signer, then it one of the methods below is used to allow the client to know what is the signer public key for the session and which relays to use.
+- **Local keypair**: A local public and private key-pair used to encrypt content and communicate with the remote signer. Usually created by the client application.
+- **Remote user pubkey**: The public key that the user wants to sign as. The remote signer has control of the private key that matches this public key.
+- **Remote signer pubkey**: This is the public key of the remote signer itself. This is needed in both `create_account` command because you don't yet have a remote user pubkey.
 
-### Started by the signer (nsecBunker)
+All pubkeys specified in this NIP are in hex format.
 
-The remote signer generates a connection token in the form
+## Initiating a connection
+
+To initiate a connection between a client and a remote signer there are a few different options.
+
+### Direct connection initiated by remote signer
+
+This is most common in a situation where you have your own nsecbunker or other type of remote signer and want to connect through a client that supports remote signing.
+
+The remote signer would provide a connection token in the form:
 
 ```
-<npub1...>#<optional-secret>?relay=wss://...&relay=wss://...
+bunker://<remote-pubkey>?relay=<wss://relay-to-connect-on>&relay=<wss://another-relay-to-connect-on>&secret=<optional-secret-value>
 ```
 
-The user copies that token and pastes it in the client UI somehow. Then the client can send events of kind `24133` to the specified relays and wait for responses from the remote signer.
+This token is pasted into the client by the user and the client then uses the details to connect to the remote signer via the specified relay(s).
 
-### Started by the client
+### Direct connection initiated by the client
 
-The client generates a QR code in the following form (URL-encoded):
+In this case, basically the opposite direction of the first case, the client provides a connection token (or encodes the token in a QR code) and the signer initiates a connection to the client via the specified relay(s).
 
 ```
-nostrconnect://<client-key-hex>?relay=wss://...&metadata={"name":"...", "url": "...", "description": "..."}
+nostrconnect://<local-keypair-pubkey>?relay=<wss://relay-to-connect-on>&metadata=<json metadata in the form: {"name":"...", "url": "...", "description": "..."}>
 ```
 
-The signer scans the QR code and sends a `connect` message to the client in the specified relays.
+## The flow
 
-## Event payloads
+1. Client creates a local keypair. This keypair doesn't need to be communicated to the user since it's largely disposable (i.e. the user doesn't need to see this pubkey). Clients might choose to store it locally and they should delete it when the user logs out.
+2. Client gets the remote user pubkey (either via a `bunker://` connection string or a NIP-05 login-flow; shown below)
+3. Clients use the local keypair to send requests to the remote signer by `p`-tagging and encrypting to the remote user pubkey.
+4. The remote signer responds to the client by `p`-tagging and encrypting to the local keypair pubkey.
 
-Event payloads are [NIP-04](04.md)-encrypted JSON blobs that look like JSONRPC messages (their format is specified inside the `.content` of the event formats below).
+### Example flow for signing an event
 
-Events sent by the client to the remote signer have the following format:
+- Remote user pubkey (e.g. signing as) `fa984bd7dbb282f07e16e7ae87b26a2a7b9b90b7246a44771f0cf5ae58018f52`
+- Local pubkey is `eff37350d839ce3707332348af4549a96051bd695d3223af4aabce4993531d86`
 
-```js
+#### Signature request
+
+```json
 {
-  "pubkey": "<client-key-hex>"
-  "kind": 24133,
-  "tags": [
-    ["p", "<signer-key-hex>"]
-  ],
-  "content": "nip04_encrypted_json({id: <random-string>, method: <see-below>, params: [array_of_strings]})",
-  ...
+    "kind": 24133,
+    "pubkey": "eff37350d839ce3707332348af4549a96051bd695d3223af4aabce4993531d86",
+    "content": nip04({
+        "id": <random_string>,
+        "method": "sign_event",
+        "params": [json_stringified(<{
+            content: "Hello, I'm signing remotely",
+            pubkey: "fa984bd7dbb282f07e16e7ae87b26a2a7b9b90b7246a44771f0cf5ae58018f52",
+            // ...the rest of the event data
+        }>)]
+    }),
+    "tags": [["p", "fa984bd7dbb282f07e16e7ae87b26a2a7b9b90b7246a44771f0cf5ae58018f52"]], // p-tags the remote user pubkey
 }
 ```
 
-And the events the remote signer sends to the client have the following format:
+#### Response event
 
-```js
-  "pubkey": "<signer-key-hex>"
-  "kind": 24133,
-  "tags": [
-    ["p", "<client-key-hex>"]
-  ],
-  "content": "nip04_encrypted_json({id: <request-id>, result: <string>, error: <reason-string>})",
-  ...
+```json
+{
+    "kind": 24133,
+    "pubkey": "fa984bd7dbb282f07e16e7ae87b26a2a7b9b90b7246a44771f0cf5ae58018f52",
+    "content": nip04({
+        "id": <random_string>,
+        "result": json_stringified(<signed-event>)
+    }),
+    "tags": [["p", "eff37350d839ce3707332348af4549a96051bd695d3223af4aabce4993531d86"]], // p-tags the local keypair pubkey
+}
 ```
 
-The signer key will always be the key of the user who controls the signer device.
+#### Diagram
 
-### Methods
+![signing-example](https://i.nostr.build/P3gW.png)
 
-- **connect**
-  - params: [`pubkey`, `secret`]
-  - result: `"ack"`
-- **get_public_key**
-  - params: []
-  - result: `pubkey-hex`
-- **sign_event**
-  - params: [`event`]
-  - result: `json_string(event_with_pubkey_id_and_signature)`
-- **get_relays**
-  - params: []
-  - result: `json_string({[url: string]: {read: boolean, write: boolean}})`
-- **nip04_encrypt**
-  - params: [`third-party-pubkey`, `plaintext`]
-  - result: `nip04-ciphertext`
-- **nip04_decrypt**
-  - params: [`third-party-pubkey`, `nip04-ciphertext`]
-  - result: `plaintext`
-- **nip44_get_key**
-  - params: [`third-party-pubkey`]
-  - result: `nip44-conversation-key`
-- **nip44_encrypt**
-  - params: [`third-party-pubkey`, `plaintext`]
-  - result: `nip44-ciphertext`
-- **nip44_decrypt**
-  - params: [`third-party-pubkey`, `nip44-ciphertext`]
-  - result: `plaintext`
-- **ping**
-  - params: []
-  - result: `"pong"`
+## Request Events `kind: 24133`
 
+```json
+{
+    "id": <id>,
+    "kind": 24133,
+    "pubkey": <local_keypair_pubkey>,
+    "content": <nip04(<request>)>,
+    "tags": [["p", <remote_user_pubkey>]], // NB: in the `create_account` event, the remote signer pubkey should be `p` tagged.
+    "created_at": <unix timestamp in seconds>
+}
+```
+
+The `content` field is a JSON-RPC-like message that is [NIP-04](https://github.com/nostr-protocol/nips/blob/master/04.md) encrypted and has the following structure:
+
+```json
+{
+    "id": <random_string>,
+    "method": <method_name>,
+    "params": [array_of_strings]
+}
+```
+
+- `id` is a random string that is a request ID. This same ID will be sent back in the response payload.
+- `method` is the name of the method/command (detailed below).
+- `params` is a positional array of string parameters.
+
+### Methods/Commands
+
+Each of the following are methods that the client sends to the remote signer.
+
+| Command                  | Params                                            | Result                                                                 |
+| ------------------------ | ------------------------------------------------- | ---------------------------------------------------------------------- |
+| `connect`                | `[<remote_user_pubkey>, <optional_secret>]`       | "ack"                                                                  |
+| `sign_event`             | `[<json_stringified_event_to_sign>]`              | `json_stringified(<signed_event>)`                                     |
+| `ping`                   | `[]`                                              | "pong"                                                                 |
+| `get_relays`             | `[]`                                              | `json_stringified({<relay_url>: {read: <boolean>, write: <boolean>}})` |
+| `get_public_key`         | `[]`                                              | `<hex-pubkey>`                                                         |
+| `nip04_encrypt`          | `[<third_party_pubkey>, <plaintext_to_encrypt>]`  | `<nip04_ciphertext>`                                                   |
+| `nip04_decrypt`          | `[<third_party_pubkey>, <nip04_ciphertext_to_decrypt>]` | `<plaintext>`                                                    |
+| `nip44_encrypt`          | `[<third_party_pubkey>, <plaintext_to_encrypt>]`  | `<nip44_ciphertext>`                                                   |
+| `nip44_decrypt`          | `[<third_party_pubkey>, <nip44_ciphertext_to_decrypt>]` | `<plaintext>`                                                    |
+
+## Response Events `kind:24133`
+
+```json
+{
+    "id": <id>,
+    "kind": 24133,
+    "pubkey": <remote_signer_pubkey>,
+    "content": <nip04(<response>)>,
+    "tags": [["p", <local_keypair_pubkey>]],
+    "created_at": <unix timestamp in seconds>
+}
+```
+
+The `content` field is a JSON-RPC-like message that is [NIP-04](https://github.com/nostr-protocol/nips/blob/master/04.md) encrypted and has the following structure:
+
+```json
+{
+    "id": <request_id>,
+    "result": <results_string>,
+    "error": <error_string>
+}
+```
+
+- `id` is the request ID that this response is for.
+- `results` is a string of the result of the call (this can be either a string or a JSON stringified object)
+- `error` is an error in string form.
+
+### Auth Challenges
+
+An Auth Challenge is a response that a remote signer can send back when it needs the user to authenticate via other means. This is currently used in the OAuth-like flow enabled by signers like [Nsecbunker](https://github.com/kind-0/nsecbunkerd/). The response `content` object will take the following form:
+
+```json
+{
+    "id": <request_id>,
+    "result": "auth_url",
+    "error": <URL_to_display_to_end_user>
+}
+```
+
+Clients should display (in a popup or new tab) the URL from the `error` field and then subscribe/listen for another response from the remote signer (reusing the same request ID). This event will be sent once the user authenticates in the other window (or will never arrive if the user doesn't authenticate). It's also possible to add a `redirect_uri` url parameter to the auth_url, which is helpful in situations when a client cannot open a new window or tab to display the auth challenge.
+
+#### Example event signing request with auth challenge
+
+![signing-example-with-auth-challenge](https://i.nostr.build/W3aj.png)
+
+## Remote Signer Commands
+
+Remote signers might support additional commands when communicating directly with it. These commands follow the same flow as noted above, the only difference is that when the client sends a request event, the `p`-tag is the pubkey of the remote signer itself and the `content` payload is encrypted to the same remote signer pubkey.
+
+### Methods/Commands
+
+Each of the following are methods that the client sends to the remote signer.
+
+| Command          | Params                                     | Result                               |
+| ---------------- | ------------------------------------------ | ------------------------------------ |
+| `create_account` | `[<username>, <domain>, <optional_email>]` | `<newly_created_remote_user_pubkey>` |
+
+## Appendix
+
+### NIP-05 Login Flow
+
+Clients might choose to present a more familiar login flow, so users can type a NIP-05 address instead of a `bunker://` string.
+
+When the user types a NIP-05 the client:
+
+- Queries the `/.well-known/nostr.json` file from the domain for the NIP-05 address provided to get the user's pubkey (this is the **remote user pubkey**)
+- In the same `/.well-known/nostr.json` file, queries for the `nip46` key to get the relays that the remote signer will be listening on.
+- Now the client has enough information to send commands to the remote signer on behalf of the user.
+
+### OAuth-like Flow
+
+#### Remote signer discovery via NIP-89
+
+In this last case, most often used to fascilitate an OAuth-like signin flow, the client first looks for remote signers that have announced themselves via NIP-89 application handler events.
+
+First the client will query for `kind: 31990` events that have a `k` tag of `24133`.
+
+These are generally shown to a user, and once the user selects which remote signer to use and provides the remote user pubkey they want to use (via npub, pubkey, or nip-05 value), the client can initiate a connection. Note that it's on the user to select the remote signer that is actually managing the remote key that they would like to use in this case. If the remote user pubkey is managed on another remote signer, the connection will fail.
+
+In addition, it's important that clients validate that the pubkey of the announced remote signer matches the pubkey of the `_` entry in the `/.well-known/nostr.json` file of the remote signer's announced domain.
+
+Clients that allow users to create new accounts should also consider validating the availability of a given username in the namespace of remote signer's domain by checking the `/.well-known/nostr.json` file for existing usernames. Clients can then show users feedback in the UI before sending a `create_account` event to the remote signer and receiving an error in return. Ideally, remote signers would also respond with understandable error messages if a client tries to create an account with an existing username.
+
+#### Example Oauth-like flow to create a new user account with Nsecbunker
+
+Coming soon...
+
+## References
+
+- [NIP-04 - Encryption](https://github.com/nostr-protocol/nips/blob/master/04.md)

47.md

@@ -17,7 +17,7 @@ This NIP describes a way for clients to access a remote Lightning wallet through
 * **wallet service**: Nostr app that typically runs on an always-on computer (eg. in the cloud or on a Raspberry Pi).  This app has access to the APIs of the wallets it serves.
 
 ## Theory of Operation
- 1. **Users** who which to use this NIP to send lightning payments to other nostr users must first acquire a special "connection" URI from their NIP-47 compliant wallet application.  The wallet application may provide this URI using a QR screen, or a pasteable string, or some other means. 
+ 1. **Users** who wish to use this NIP to send lightning payments to other nostr users must first acquire a special "connection" URI from their NIP-47 compliant wallet application.  The wallet application may provide this URI using a QR screen, or a pasteable string, or some other means. 
  
  2. The **user** should then copy this URI into their **client(s)** by pasting, or scanning the QR, etc.  The **client(s)** should save this URI and use it later whenever the **user** makes a payment.  The **client** should then request an `info` (13194) event from the relay(s) specified in the URI.  The **wallet service** will have sent that event to those relays earlier, and the relays will hold it as a replaceable event.  
  
@@ -36,6 +36,7 @@ The info event should be a replaceable event that is published by the **wallet s
 a plaintext string with the supported commands, space-separated, eg. `pay_invoice get_balance`. Only the `pay_invoice` command is described in this NIP, but other commands might be defined in different NIPs.
 
 Both the request and response events SHOULD contain one `p` tag, containing the public key of the **wallet service** if this is a request, and the public key of the **user** if this is a response. The response event SHOULD contain an `e` tag with the id of the request event it is responding to.
+Optionally, a request can have an `expiration` tag that has a unix timestamp in seconds. If the request is received after this timestamp, it should be ignored.
 
 The content of requests and responses is encrypted with [NIP04](https://github.com/nostr-protocol/nips/blob/master/04.md), and is a JSON-RPCish object with a semi-fixed structure:
 
@@ -108,7 +109,8 @@ Request:
 {
     "method": "pay_invoice",
     "params": {
-        "invoice": "lnbc50n1..." // bolt11 invoice
+        "invoice": "lnbc50n1...", // bolt11 invoice
+        "amount": 123, // invoice amount in msats, optional
     }
 }
 ```
@@ -126,6 +128,278 @@ Response:
 Errors:
 - `PAYMENT_FAILED`: The payment failed. This may be due to a timeout, exhausting all routes, insufficient capacity or similar.
 
+### `multi_pay_invoice`
+
+Description: Requests payment of multiple invoices.
+
+Request:
+```jsonc
+{
+    "method": "multi_pay_invoice",
+    "params": {
+        "invoices": [
+          {"id":"4da52c32a1", "invoice": "lnbc1...", "amount": 123}, // bolt11 invoice and amount in msats, amount is optional
+          {"id":"3da52c32a1", "invoice": "lnbc50n1..."},
+        ],
+    }
+}
+```
+
+Response:
+
+For every invoice in the request, a separate response event is sent. To differentiate between the responses, each
+response event contains an `d` tag with the id of the invoice it is responding to, if no id was given, then the
+payment hash of the invoice should be used.
+
+```jsonc
+{
+    "result_type": "multi_pay_invoice",
+    "result": {
+        "preimage": "0123456789abcdef..." // preimage of the payment
+    }
+}
+```
+
+Errors:
+- `PAYMENT_FAILED`: The payment failed. This may be due to a timeout, exhausting all routes, insufficient capacity or similar.
+
+### `pay_keysend`
+
+Request:
+```jsonc
+{
+    "method": "pay_keysend",
+    "params": {
+        "amount": 123, // invoice amount in msats, required
+        "pubkey": "03...", // payee pubkey, required
+        "preimage": "0123456789abcdef...", // preimage of the payment, optional
+        "tlv_records: [ // tlv records, optional
+            {
+                "type": 5482373484, // tlv type
+                "value": "0123456789abcdef" // hex encoded tlv value
+            }
+        ]
+    }
+}
+```
+
+Response:
+```jsonc
+{
+    "result_type": "pay_keysend",
+    "result": {
+        "preimage": "0123456789abcdef...", // preimage of the payment
+    }
+}
+```
+
+Errors:
+- `PAYMENT_FAILED`: The payment failed. This may be due to a timeout, exhausting all routes, insufficient capacity or similar.
+
+### `multi_pay_keysend`
+
+Description: Requests multiple keysend payments.
+
+Has an array of keysends, these follow the same semantics as `pay_keysend`, just done in a batch
+
+Request:
+```jsonc
+{
+    "method": "multi_pay_keysend",
+    "params": {
+        "keysends": [
+          {"id": "4c5b24a351", pubkey": "03...", "amount": 123},
+          {"id": "3da52c32a1", "pubkey": "02...", "amount": 567, "preimage": "abc123..", "tlv_records": [{"type": 696969, "value": "77616c5f6872444873305242454d353736"}]},
+        ],
+    }
+}
+```
+
+Response:
+
+For every keysend in the request, a separate response event is sent. To differentiate between the responses, each
+response event contains an `d` tag with the id of the keysend it is responding to, if no id was given, then the
+pubkey should be used.
+
+```jsonc
+{
+    "result_type": "multi_pay_keysend",
+    "result": {
+        "preimage": "0123456789abcdef..." // preimage of the payment
+    }
+}
+```
+
+Errors:
+- `PAYMENT_FAILED`: The payment failed. This may be due to a timeout, exhausting all routes, insufficient capacity or similar.
+
+### `make_invoice`
+
+Request:
+```jsonc
+{
+    "method": "make_invoice",
+    "params": {
+        "amount": 123, // value in msats
+        "description": "string", // invoice's description, optional
+        "description_hash": "string", // invoice's description hash, optional
+        "expiry": 213 // expiry in seconds from time invoice is created, optional
+    }
+}
+```
+
+Response:
+```jsonc
+{
+    "result_type": "make_invoice",
+    "result": {
+        "type": "incoming", // "incoming" for invoices, "outgoing" for payments
+        "invoice": "string", // encoded invoice, optional
+        "description": "string", // invoice's description, optional
+        "description_hash": "string", // invoice's description hash, optional
+        "preimage": "string", // payment's preimage, optional if unpaid
+        "payment_hash": "string", // Payment hash for the payment
+        "amount": 123, // value in msats
+        "fees_paid": 123, // value in msats
+        "created_at": unixtimestamp, // invoice/payment creation time
+        "expires_at": unixtimestamp, // invoice expiration time, optional if not applicable
+        "metadata": {} // generic metadata that can be used to add things like zap/boostagram details for a payer name/comment/etc.
+    }
+}
+```
+
+### `lookup_invoice`
+
+Request:
+```jsonc
+{
+    "method": "lookup_invoice",
+    "params": {
+        "payment_hash": "31afdf1..", // payment hash of the invoice, one of payment_hash or invoice is required
+        "invoice": "lnbc50n1..." // invoice to lookup
+    }
+}
+```
+
+Response:
+```jsonc
+{
+    "result_type": "lookup_invoice",
+    "result": {
+        "type": "incoming", // "incoming" for invoices, "outgoing" for payments
+        "invoice": "string", // encoded invoice, optional
+        "description": "string", // invoice's description, optional
+        "description_hash": "string", // invoice's description hash, optional
+        "preimage": "string", // payment's preimage, optional if unpaid
+        "payment_hash": "string", // Payment hash for the payment
+        "amount": 123, // value in msats
+        "fees_paid": 123, // value in msats
+        "created_at": unixtimestamp, // invoice/payment creation time
+        "expires_at": unixtimestamp, // invoice expiration time, optional if not applicable
+        "settled_at": unixtimestamp, // invoice/payment settlement time, optional if unpaid
+        "metadata": {} // generic metadata that can be used to add things like zap/boostagram details for a payer name/comment/etc.
+    }
+}
+```
+
+Errors:
+- `NOT_FOUND`: The invoice could not be found by the given parameters.
+
+### `list_transactions`
+
+Lists invoices and payments. If `type` is not specified, both invoices and payments are returned.
+The `from` and `until` parameters are timestamps in seconds since epoch. If `from` is not specified, it defaults to 0.
+If `until` is not specified, it defaults to the current time. Transactions are returned in descending order of creation
+time.
+
+Request:
+```jsonc
+{
+    "method": "list_transactions",
+    "params": {
+        "from": 1693876973, // starting timestamp in seconds since epoch (inclusive), optional
+        "until": 1703225078, // ending timestamp in seconds since epoch (inclusive), optional
+        "limit": 10, // maximum number of invoices to return, optional
+        "offset": 0, // offset of the first invoice to return, optional
+        "unpaid": true, // include unpaid invoices, optional, default false
+        "type": "incoming", // "incoming" for invoices, "outgoing" for payments, undefined for both
+    }
+}
+```
+
+Response:
+```jsonc
+{
+    "result_type": "list_transactions",
+    "result": {
+        "transactions": [
+            {
+               "type": "incoming", // "incoming" for invoices, "outgoing" for payments
+               "invoice": "string", // encoded invoice, optional
+               "description": "string", // invoice's description, optional
+               "description_hash": "string", // invoice's description hash, optional
+               "preimage": "string", // payment's preimage, optional if unpaid
+               "payment_hash": "string", // Payment hash for the payment
+               "amount": 123, // value in msats
+               "fees_paid": 123, // value in msats
+               "created_at": unixtimestamp, // invoice/payment creation time
+               "expires_at": unixtimestamp, // invoice expiration time, optional if not applicable
+               "settled_at": unixtimestamp, // invoice/payment settlement time, optional if unpaid
+               "metadata": {} // generic metadata that can be used to add things like zap/boostagram details for a payer name/comment/etc.
+           }
+        ],
+    },
+}
+```
+
+### `get_balance`
+
+Request:
+```jsonc
+{
+    "method": "get_balance",
+    "params": {
+    }
+}
+```
+
+Response:
+```jsonc
+{
+    "result_type": "get_balance",
+    "result": {
+        "balance": 10000, // user's balance in msats
+    }
+}
+```
+
+### `get_info`
+
+Request:
+```jsonc
+{
+    "method": "get_info",
+    "params": {
+    }
+}
+```
+
+Response:
+```jsonc
+{
+    "result_type": "get_info",
+    "result": {
+            "alias": "string",
+            "color": "hex string",
+            "pubkey": "hex string",
+            "network": "string", // mainnet, testnet, signet, or regtest
+            "block_height": 1,
+            "block_hash": "hex string",
+            "methods": ["pay_invoice", "get_balance", "make_invoice", "lookup_invoice", "list_transactions", "get_info"], // list of supported methods for this connection
+    }
+}
+```
+
 ## Example pay invoice flow
 
 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.

49.md

@@ -0,0 +1,126 @@
+
+NIP-49
+======
+
+Private Key Encryption
+----------------------
+
+`draft` `optional`
+
+This NIP defines a method by which clients can encrypt (and decrypt) a user's private key with a password.
+
+Symmetric Encryption Key derivation
+-----------------------------------
+
+PASSWORD = Read from the user. The password should be unicode normalized to NFKC format to ensure that the password can be entered identically on other computers/clients.
+
+LOG\_N = Let the user or implementer choose one byte representing a power of 2 (e.g. 18 represents 262,144) which is used as the number of rounds for scrypt. Larger numbers take more time and more memory, and offer better protection:
+
+    | LOG_N | MEMORY REQUIRED | APPROX TIME ON FAST COMPUTER |
+    |-------|-----------------|----------------------------- |
+    | 16    | 64 MiB          | 100 ms                       |
+    | 18    | 256 MiB         |                              |
+    | 20    | 1 GiB           | 2 seconds                    |
+    | 21    | 2 GiB           |                              |
+    | 22    | 4 GiB           |                              |
+
+SALT = 16 random bytes
+
+SYMMETRIC_KEY = scrypt(password=PASSWORD, salt=SALT, log\_n=LOG\_N, r=8, p=1)
+
+The symmetric key should be 32 bytes long.
+
+This symmetric encryption key is temporary and should be zeroed and discarded after use and not stored or reused for any other purpose.
+
+
+Encrypting a private key
+------------------------
+
+The private key encryption process is as follows:
+
+PRIVATE\_KEY = User's private (secret) secp256k1 key as 32 raw bytes (not hex or bech32 encoded!)
+
+KEY\_SECURITY\_BYTE = one of:
+
+*  0x00 - if the key has been known to have been handled insecurely (stored unencrypted, cut and paste unencrypted, etc)
+*  0x01 - if the key has NOT been known to have been handled insecurely (stored unencrypted, cut and paste unencrypted, etc)
+ * 0x02 - if the client does not track this data
+
+ASSOCIATED\_DATA = KEY\_SECURITY\_BYTE
+
+NONCE = 24 byte random nonce
+
+CIPHERTEXT = XChaCha20-Poly1305(
+    plaintext=PRIVATE\_KEY,
+    associated_data=ASSOCIATED\_DATA,
+    nonce=NONCE,
+    key=SYMMETRIC\_KEY
+)
+
+VERSION\_NUMBER = 0x02
+
+CIPHERTEXT_CONCATENATION = concat(
+    VERSION\_NUMBER,
+    LOG\_N,
+    SALT,
+    NONCE,
+    ASSOCIATED\_DATA,
+    CIPHERTEXT
+)
+
+ENCRYPTED\_PRIVATE\_KEY = bech32_encode('ncryptsec', CIPHERTEXT\_CONCATENATION)
+
+The output prior to bech32 encoding should be 91 bytes long.
+
+The decryption process operates in the reverse.
+
+
+Test Data
+---------
+
+## Password Unicode Normalization
+
+The following password input: "ÅΩẛ̣"
+- Unicode Codepoints: U+212B U+2126 U+1E9B U+0323
+- UTF-8 bytes: [0xE2, 0x84, 0xAB, 0xE2, 0x84, 0xA6, 0xE1, 0xBA, 0x9B, 0xCC, 0xA3]
+
+Should be converted into the unicode normalized NFKC format prior to use in scrypt: "ÅΩẛ̣"
+- Unicode Codepoints: U+00C5 U+03A9 U+1E69
+- UTF-8 bytes: [0xC3, 0x85, 0xCE, 0xA9, 0xE1, 0xB9, 0xA9]
+
+## Encryption
+
+The encryption process is non-deterministic due to the random nonce.
+
+## Decryption
+
+The following encrypted private key:
+
+`ncryptsec1qgg9947rlpvqu76pj5ecreduf9jxhselq2nae2kghhvd5g7dgjtcxfqtd67p9m0w57lspw8gsq6yphnm8623nsl8xn9j4jdzz84zm3frztj3z7s35vpzmqf6ksu8r89qk5z2zxfmu5gv8th8wclt0h4p`
+
+When decrypted with password='nostr' and log_n=16 yields the following hex-encoded private key:
+
+`3501454135014541350145413501453fefb02227e449e57cf4d3a3ce05378683`
+
+Discussion
+----------
+
+### On Key Derivation
+
+Passwords make poor cryptographic keys. Prior to use as a cryptographic key, two things need to happen:
+
+1. An encryption key needs to be deterministically created from the password such that is has a uniform functionally random distribution of bits, such that the symmetric encryption algorithm's assumptions are valid, and
+2. A slow irreversible algorithm should be injected into the process, so that brute-force attempts to decrypt by trying many passwords are severely hampered.
+
+These are achieved using a password-based key derivation function. We use scrypt, which has been proven to be maximally memory hard and which several cryptographers have indicated to the author is better than argon2 even though argon2 won a competition in 2015.
+
+### On the symmetric encryption algorithm
+
+XChaCha20-Poly1305 is typically favored by cryptographers over AES and is less associated with the U.S. government.  It (or it's earlier variant without the 'X') is gaining wide usage, is used in TLS and OpenSSH, and is available in most modern crypto libraries.
+
+Recommendations
+---------
+
+It is not recommended that users publish these encrypted private keys to nostr, as cracking a key may become easier when an attacker can amass many encrypted private keys.
+
+It is recommended that clients zero out the memory of passwords and private keys before freeing that memory.

51.md

@@ -18,18 +18,18 @@ When new items are added to an existing list, clients SHOULD append them to the
 
 Standard lists use non-parameterized replaceable events, meaning users may only have a single list of each kind. They have special meaning and clients may rely on them to augment a user's profile or browsing experience.
 
-For example, _mute lists_ can contain the public keys of spammers and bad actors users don't want to see in their feeds or receive annoying notifications from.
+For example, _mute list_ can contain the public keys of spammers and bad actors users don't want to see in their feeds or receive annoying notifications from.
 
 | name           | kind  | description                                                 | expected tag items                                                                |
 | ---            | ---   | ---                                                         | ---                                                                               |
 | Mute list      | 10000 | things the user doesn't want to see in their feeds          | `"p"` (pubkeys), `"t"` (hashtags), `"word"` (lowercase string), `"e"` (threads)   |
 | Pinned notes   | 10001 | events the user intends to showcase in their profile page   | `"e"` (kind:1 notes)                                                              |
-| Bookmarks      | 10003 | uncategorized, "global" list of things a user wants to save | `"e"` (kind:1 notes), `"a"` (kind:30023 articles), `"t"` (hashtags), `"r" (URLs)` |
+| Bookmarks      | 10003 | uncategorized, "global" list of things a user wants to save | `"e"` (kind:1 notes), `"a"` (kind:30023 articles), `"t"` (hashtags), `"r"` (URLs) |
 | Communities    | 10004 | [NIP-72](72.md) communities the user belongs to             | `"a"` (kind:34550 community definitions)                                          |
-| Public chats   | 10005 | [NIP-28](28.md) chat channels the user is in                | `"e"` (kind:40 channel definitions)                                             |
+| Public chats   | 10005 | [NIP-28](28.md) chat channels the user is in                | `"e"` (kind:40 channel definitions)                                               |
 | Blocked relays | 10006 | relays clients should never connect to                      | `"relay"` (relay URLs)                                                            |
 | Search relays  | 10007 | relays clients should use when performing search queries    | `"relay"` (relay URLs)                                                            |
-| Interests      | 10015 | topics a user may be interested in and pointers             | `"t"` (hashtags) and `"a" (kind:30015 interest set)`                              |
+| Interests      | 10015 | topics a user may be interested in and pointers             | `"t"` (hashtags) and `"a"` (kind:30015 interest set)                              |
 | Emojis         | 10030 | user preferred emojis and pointers to emoji sets            | `"emoji"` (see [NIP-30](30.md)) and `"a"` (kind:30030 emoji set)                  |
 
 ## Sets
@@ -44,11 +44,12 @@ Aside from their main identifier, the `"d"` tag, sets can optionally have a `"ti
 | ---           | ---   | ---                                                                                          | ---                                                                               |
 | Follow sets   | 30000 | categorized groups of users a client may choose to check out in different circumstances      | `"p"` (pubkeys)                                                                   |
 | Relay sets    | 30002 | user-defined relay groups the user can easily pick and choose from during various operations | `"relay"` (relay URLs)                                                            |
-| Bookmark sets | 30003 | user-defined bookmarks categories , for when bookmarks must be in labeled separate groups    | `"e"` (kind:1 notes), `"a"` (kind:30023 articles), `"t"` (hashtags), `"r" (URLs)` |
+| Bookmark sets | 30003 | user-defined bookmarks categories , for when bookmarks must be in labeled separate groups    | `"e"` (kind:1 notes), `"a"` (kind:30023 articles), `"t"` (hashtags), `"r"` (URLs) |
 | Curation sets | 30004 | groups of articles picked by users as interesting and/or belonging to the same category      | `"a"` (kind:30023 articles), `"e"` (kind:1 notes)                                 |
-| Curation sets | 30005 | groups of videos picked by users as interesting and/or belonging to the same category      | `"a"` (kind:34235 videos)                               |
+| Curation sets | 30005 | groups of videos picked by users as interesting and/or belonging to the same category        | `"a"` (kind:34235 videos)                                                         |
 | Interest sets | 30015 | interest topics represented by a bunch of "hashtags"                                         | `"t"` (hashtags)                                                                  |
 | Emoji sets    | 30030 | categorized emoji groups                                                                     | `"emoji"` (see [NIP-30](30.md))                                                   |
+| Release artifact sets | 30063 | groups of files of a software release  | `"e"` (kind:1063 [file metadata](94.md) events), `"i"` (application identifier, typically reverse domain notation), `"version"`  |
 
 ## Deprecated standard lists
 
@@ -82,7 +83,7 @@ Some clients have used these lists in the past, but they should work on transiti
 
 ### A _curation set_ of articles and notes about yaks
 
-```
+```json
 {
   "id": "567b41fc9060c758c4216fe5f8d3df7c57daad7ae757fa4606f0c39d4dd220ef",
   "pubkey": "d6dc95542e18b8b7aec2f14610f55c335abebec76f3db9e58c254661d0593a0c",
@@ -103,6 +104,30 @@ Some clients have used these lists in the past, but they should work on transiti
 }
 ```
 
+### A _release artifact set_ of an Example App
+
+```json
+{
+  "id": "567b41fc9060c758c4216fe5f8d3df7c57daad7ae757fa4606f0c39d4dd220ef",
+  "pubkey": "d6dc95542e18b8b7aec2f14610f55c335abebec76f3db9e58c254661d0593a0c",
+  "created_at": 1695327657,
+  "kind": 30063,
+  "tags": [
+    ["d", "ak8dy3v7"],
+    ["i", "com.example.app"],
+    ["version", "0.0.1"],
+    ["title", "Example App"],
+    ["image", "http://cdn.site/p/com.example.app/icon.png"],
+    ["e", "d78ba0d5dce22bfff9db0a9e996c9ef27e2c91051de0c4e1da340e0326b4941e"], // Windows exe
+    ["e", "f27e2c91051de0c4e1da0d5dce22bfff9db0a9340e0326b4941ed78bae996c9e"], // MacOS dmg
+    ["e", "9d24ddfab95ba3ff7c03fbd07ad011fff245abea431fb4d3787c2d04aad02332"], // Linux AppImage
+    ["e", "340e0326b340e0326b4941ed78ba340e0326b4941ed78ba340e0326b49ed78ba"] // PWA
+  ],
+  "content": "Example App is a decentralized marketplace for apps",
+  "sig": "a9a4e2192eede77e6c9d24ddfab95ba3ff7c03fbd07ad011fff245abea431fb4d3787c2d04aad001cb039cb8de91d83ce30e9a94f82ac3c5a2372aa1294a96bd"
+}
+```
+
 ## Encryption process pseudocode
 
 ```scala

52.md

@@ -35,7 +35,10 @@ The list of tags are as follows:
 * `t` (optional, repeated) hashtag to categorize calendar event
 * `r` (optional, repeated) references / links to web pages, documents, video calls, recorded videos, etc.
 
-```json
+The following tags are deprecated:
+* `name` name of the calendar event. Use only if `title` is not available.
+
+```jsonc
 {
   "id": <32-bytes lowercase hex-encoded SHA-256 of the the serialized event data>,
   "pubkey": <32-bytes lowercase hex-encoded public key of the event creator>,
@@ -46,8 +49,6 @@ The list of tags are as follows:
     ["d", "<UUID>"],
 
     ["title", "<title of calendar event>"],
-    ["image", "<image url>"],
-    ["banner", "<image url>"],
 
     // Dates
     ["start", "<YYYY-MM-DD>"],
@@ -95,7 +96,10 @@ The list of tags are as follows:
 * `t` (optional, repeated) hashtag to categorize calendar event
 * `r` (optional, repeated) references / links to web pages, documents, video calls, recorded videos, etc.
 
-```json
+The following tags are deprecated:
+* `name` name of the calendar event. Use only if `title` is not available.
+
+```jsonc
 {
   "id": <32-bytes lowercase hex-encoded SHA-256 of the the serialized event data>,
   "pubkey": <32-bytes lowercase hex-encoded public key of the event creator>,
@@ -106,8 +110,6 @@ The list of tags are as follows:
     ["d", "<UUID>"],
 
     ["title", "<title of calendar event>"],
-    ["image", "<image url>"],
-    ["banner", "<image url>"],
 
     // Timestamps
     ["start", "<Unix timestamp in seconds>"],
@@ -185,10 +187,8 @@ The `.content` of these events is optional and should be a free-form note that a
 The list of tags are as follows:
 * `a` (required) reference tag to kind `31922` or `31923` calendar event being responded to.
 * `d` (required) universally unique identifier. Generated by the client creating the calendar event RSVP.
-* `L` (required) label namespace of `status` per [NIP-32](32.md)
-* `l` (required) label of `accepted`, `declined`, or `tentative` under the label namespace of `status` per [NIP-32](32.md). Determines attendance status to the referenced calendar event.
-* `L` (optional) label namespace of `freebusy` per [NIP-32](32.md). Exists if and only if corresponding `l` tag under the same label namespace exists.
-* `l` (optional) label of `free` or `busy` under the label namespace of `freebusy` per [NIP-32](32.md). Determines if the user would be free or busy for the duration of the calendar event. This tag must be omitted or ignored if the `status` label is set to `declined`. Exists if and only if corresponding `l` tag under the same label namespace exists.
+* `status` (required) `accepted`, `declined`, or `tentative`. Determines attendance status to the referenced calendar event.
+* `fb` (optional) `free` or `busy`. Determines if the user would be free or busy for the duration of the calendar event. This tag must be omitted or ignored if the `status` label is set to `declined`.
 
 ```json
 {
@@ -200,15 +200,19 @@ The list of tags are as follows:
   "tags": [
     ["a", "<31922 or 31923>:<calendar event author pubkey>:<d-identifier of calendar event>", "<optional relay url>"],
     ["d", "<UUID>"],
-    ["L", "status"],
-    ["l", "<accepted/declined/tentative>", "status"],
-    ["L", "freebusy"],
-    ["l", "<free/busy>", "freebusy"]
+    ["status", "<accepted/declined/tentative>"],
+    ["fb", "<free/busy>"],
   ]
 }
 ```
 
-## Recurring Calendar Events
+## Unsolved Limitations
+
+* No private events
+
+## Intentionally Unsupported Scenarios
+
+### Recurring Calendar Events
 
 Recurring calendar events come with a lot of complexity, making it difficult for software and humans to deal with. This complexity includes time zone differences between invitees, daylight savings, leap years, multiple calendar systems, one-off changes in schedule or other metadata, etc.
 

54.md

@@ -0,0 +1,80 @@
+NIP-54
+======
+
+Podcasts
+--------
+
+`draft` `optional`
+
+This NIP defines how podcast episodes can be fetched from relays. It's intended to fit easily into existing podcast players.
+
+## Rationale
+
+RSS feeds are great, but they have some problems that are solved by moving feeds from RSS URLs to multiple Nostr events, one for each episode:
+
+- they depend on a URL and that is hard for most people, so podcasters tend to use service providers that can
+   - charge money -- which isn't a bad thing per se but it turns out that with a Nostr-native podcast feed protocol it would be much simpler to host feeds and infinitely cheaper to host the media, so the ecosystem could be more decentralized
+   - seal them into their walled gardens (like Spotify has been doing), slowly turning a previously open ecosystem into a centralized system captured by big corporations
+   - censor podcasters and prevent them from migrating (on Nostr this wouldn't be a problem even if a relay banned someone as moving to other relays would be trivial as long as the podcaster held their key and podcast clients could easily discover the new relay URLs)
+- they can only be loaded in full, with no pagination or filtering of any kind, which means that
+   - the sync process in normal RSS clients is slow and cumbersome (which also nudges people into using centralized solutions)
+     - this has also led to the creation of broken schemes like [Podping](https://podping.org/), which wouldn't be necessary in a Nostr-native podcast feed
+   - It's impossible to reference a single episode directly (since it only exists as a member in the full RSS list of episodes), this means there is no way to share a podcast episode with friends or on social media, so people tend to share links to centralized platforms or to YouTube videos of the same podcast content, which is an antipattern
+- they cannot be interacted with in any way: listeners cannot "like" or comment or signal that they have listened to the episode, which is also another factor in the push towards centralized closed platforms: better analytics and insights and possibilities of engagement with the public
+
+## Event definitions
+
+### Podcast Profile
+
+Podcasts have their own key and their own [NIP-01](01.md) `kind:0` profile, but with a tag `["type", "podcast"]` that can be used to signal that they have podcast episodes published.
+
+### Podcast Episodes
+
+Podcast episodes are `kind:54` with some tags:
+
+```jsonc
+{
+  "id": "55807e7d5cd90d0303d7dce7397f996fdbaed8697903f326c7cf8ad999b9de3d",
+  "pubkey": "79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798",
+  "kind": 54,
+  "created_at": 1700682555,
+  "tags": [
+    ["title", "<episode title>"],
+    ["image", "<optional episode image>"],
+    ["description", "<a brief description>"],
+    ["audio", "https://.../", "<optional_media_type>"], // can be specified multiple times
+    ["t", "<optional tag>"], // can be specified multiple times
+    ["alt", "<optional NIP-31 short description for displaying in incompatible clients>"]
+  ],
+  "content": "<markdown content (or what is supported in RSS feeds content nowadays?)>",
+  "sig": "...",
+}
+```
+
+### Podcast Comments
+
+These are normal text comments like `kind:1`, but specific for podcast episodes.
+
+```jsonc
+{
+  "id": "606f6c703f04c70806a5c2830e3853bd83c44985b1f282a070ba894add3724b0",
+  "pubkey": "b2c5d5bf69d14d35c25fa47d5c67896b13394136734065a371c5bf2c62f905d2",
+  "kind": 55,
+  "created_at": 1700682556,
+  "tags": [
+    ["e", "55807e7d5cd90d0303d7dce7397f996fdbaed8697903f326c7cf8ad999b9de3d"],
+  ],
+  "content": "<plain text content>",
+  "sig": "...",
+}
+```
+
+(It's unclear if it's best to use this or a generic kind for commenting on stuff that isn't `kind:1`.)
+
+### Reactions (likes), zaps and reposts
+
+These work normally according to their own NIPs.
+
+### To be added:
+
+- "read" events, signaling that a user has listened to a given podcast, perhaps just use https://github.com/nostr-protocol/nips/pull/933

59.md

@@ -0,0 +1,252 @@
+NIP-59
+======
+
+Gift Wrap
+---------
+
+`optional`
+
+This NIP defines a protocol for encapsulating any nostr event. This makes it possible to obscure most metadata
+for a given event, perform collaborative signing, and more.
+
+This NIP *does not* define any messaging protocol. Applications of this NIP should be defined separately.
+
+This NIP relies on [NIP-44](./44.md)'s versioned encryption algorithms.
+
+# Overview
+
+This protocol uses three main concepts to protect the transmission of a target event: `rumor`s, `seal`s, and `gift wrap`s.
+
+- A `rumor` is a regular nostr event, but is **not signed**. This means that if it is leaked, it cannot be verified.
+- A `rumor` is serialized to JSON, encrypted, and placed in the `content` field of a `seal`. The `seal` is then
+  signed by the author of the note. The only information publicly available on a `seal` is who signed it, but not what was said.
+- A `seal` is serialized to JSON, encrypted, and placed in the `content` field of a `gift wrap`.
+
+This allows the isolation of concerns across layers:
+
+- A rumor carries the content but is unsigned, which means if leaked it will be rejected by relays and clients,
+  and can't be authenticated. This provides a measure of deniability.
+- A seal identifies the author without revealing the content or the recipient.
+- A gift wrap can add metadata (recipient, tags, a different author) without revealing the true author.
+
+# Protocol Description
+
+## 1. The Rumor Event Kind
+
+A `rumor` is the same thing as an unsigned event. Any event kind can be made a `rumor` by removing the signature.
+
+## 2. The Seal Event Kind
+
+A `seal` is a `kind:13` event that wraps a `rumor` with the sender's regular key. The `seal` is **always** encrypted
+to a receiver's pubkey but there is no `p` tag pointing to the receiver. There is no way to know who the rumor is for
+without the receiver's or the sender's private key. The only public information in this event is who is signing it.
+
+```js
+{
+  "id": "<id>",
+  "pubkey": "<real author's pubkey>",
+  "content": "<encrypted rumor>",
+  "kind": 13,
+  "created_at": 1686840217,
+  "tags": [],
+  "sig": "<real author's pubkey signature>"
+}
+```
+
+Tags MUST must always be empty in a `kind:13`. The inner event MUST always be unsigned.
+
+## 3. Gift Wrap Event Kind
+
+A `gift wrap` event is a `kind:1059` event that wraps any other event. `tags` SHOULD include any information
+needed to route the event to its intended recipient, including the recipient's `p` tag or [NIP-13](13.md) proof of work.
+
+```js
+{
+  "id": "<id>",
+  "pubkey": "<random, one-time-use pubkey>",
+  "content": "<encrypted kind 13>",
+  "kind": 1059,
+  "created_at": 1686840217,
+  "tags": [["p", "<recipient pubkey>"]],
+  "sig": "<random, one-time-use pubkey signature>"
+}
+```
+
+# Encrypting Payloads
+
+Encryption is done following [NIP-44](44.md) on the JSON-encoded event. Place the encryption payload in the `.content`
+of the wrapper event (either a `seal` or a `gift wrap`).
+
+# Other Considerations
+
+If a `rumor` is intended for more than one party, or if the author wants to retain an encrypted copy, a single
+`rumor` may be wrapped and addressed for each recipient individually.
+
+The canonical `created_at` time belongs to the `rumor`. All other timestamps SHOULD be tweaked to thwart
+time-analysis attacks. Note that some relays don't serve events dated in the future, so all timestamps
+SHOULD be in the past.
+
+Relays may choose not to store gift wrapped events due to them not being publicly useful. Clients MAY choose
+to attach a certain amount of proof-of-work to the wrapper event per [NIP-13](13.md) in a bid to demonstrate that
+the event is not spam or a denial-of-service attack.
+
+To protect recipient metadata, relays SHOULD guard access to `kind 1059` events based on user AUTH. When
+possible, clients should only send wrapped events to relays that offer this protection.
+
+To protect recipient metadata, relays SHOULD only serve `kind 1059` events intended for the marked recipient.
+When possible, clients should only send wrapped events to `read` relays for the recipient that implement
+AUTH, and refuse to serve wrapped events to non-recipients.
+
+# An Example
+
+Let's send a wrapped `kind 1` message between two parties asking "Are you going to the party tonight?"
+
+- Author private key: `0beebd062ec8735f4243466049d7747ef5d6594ee838de147f8aab842b15e273`
+- Recipient private key: `e108399bd8424357a710b606ae0c13166d853d327e47a6e5e038197346bdbf45`
+- Ephemeral wrapper key: `4f02eac59266002db5801adc5270700ca69d5b8f761d8732fab2fbf233c90cbd`
+
+Note that this messaging protocol should not be used in practice, this is just an example. Refer to other
+NIPs for concrete messaging protocols that depend on gift wraps.
+
+## 1. Create an event
+
+Create a `kind 1` event with the message, the receivers, and any other tags you want, signed by the author.
+Do not sign the event.
+
+```json
+{
+  "created_at": 1691518405,
+  "content": "Are you going to the party tonight?",
+  "tags": [],
+  "kind": 1,
+  "pubkey": "611df01bfcf85c26ae65453b772d8f1dfd25c264621c0277e1fc1518686faef9",
+  "id": "9dd003c6d3b73b74a85a9ab099469ce251653a7af76f523671ab828acd2a0ef9"
+}
+```
+
+## 2. Seal the rumor
+
+Encrypt the JSON-encoded `rumor` with a conversation key derived using the author's private key and
+the recipient's public key. Place the result in the `content` field of a `kind 13` `seal` event. Sign
+it with the author's key.
+
+```json
+{
+  "content": "AqBCdwoS7/tPK+QGkPCadJTn8FxGkd24iApo3BR9/M0uw6n4RFAFSPAKKMgkzVMoRyR3ZS/aqATDFvoZJOkE9cPG/TAzmyZvr/WUIS8kLmuI1dCA+itFF6+ULZqbkWS0YcVU0j6UDvMBvVlGTzHz+UHzWYJLUq2LnlynJtFap5k8560+tBGtxi9Gx2NIycKgbOUv0gEqhfVzAwvg1IhTltfSwOeZXvDvd40rozONRxwq8hjKy+4DbfrO0iRtlT7G/eVEO9aJJnqagomFSkqCscttf/o6VeT2+A9JhcSxLmjcKFG3FEK3Try/WkarJa1jM3lMRQqVOZrzHAaLFW/5sXano6DqqC5ERD6CcVVsrny0tYN4iHHB8BHJ9zvjff0NjLGG/v5Wsy31+BwZA8cUlfAZ0f5EYRo9/vKSd8TV0wRb9DQ=",
+  "kind": 13,
+  "created_at": 1703015180,
+  "pubkey": "611df01bfcf85c26ae65453b772d8f1dfd25c264621c0277e1fc1518686faef9",
+  "tags": [],
+  "id": "28a87d7c074d94a58e9e89bb3e9e4e813e2189f285d797b1c56069d36f59eaa7",
+  "sig": "02fc3facf6621196c32912b1ef53bac8f8bfe9db51c0e7102c073103586b0d29c3f39bdaa1e62856c20e90b6c7cc5dc34ca8bb6a528872cf6e65e6284519ad73"
+}
+```
+
+## 3. Wrap the seal
+
+Encrypt the JSON-encoded `kind 13` event with your ephemeral, single-use random key. Place the result
+in the `content` field of a `kind 1059`. Add a single `p` tag containing the recipient's public key.
+Sign the `gift wrap` using the random key generated in the previous step.
+
+```json
+{
+  "content": "AhC3Qj/QsKJFWuf6xroiYip+2yK95qPwJjVvFujhzSguJWb/6TlPpBW0CGFwfufCs2Zyb0JeuLmZhNlnqecAAalC4ZCugB+I9ViA5pxLyFfQjs1lcE6KdX3euCHBLAnE9GL/+IzdV9vZnfJH6atVjvBkNPNzxU+OLCHO/DAPmzmMVx0SR63frRTCz6Cuth40D+VzluKu1/Fg2Q1LSst65DE7o2efTtZ4Z9j15rQAOZfE9jwMCQZt27rBBK3yVwqVEriFpg2mHXc1DDwHhDADO8eiyOTWF1ghDds/DxhMcjkIi/o+FS3gG1dG7gJHu3KkGK5UXpmgyFKt+421m5o++RMD/BylS3iazS1S93IzTLeGfMCk+7IKxuSCO06k1+DaasJJe8RE4/rmismUvwrHu/HDutZWkvOAhd4z4khZo7bJLtiCzZCZ74lZcjOB4CYtuAX2ZGpc4I1iOKkvwTuQy9BWYpkzGg3ZoSWRD6ty7U+KN+fTTmIS4CelhBTT15QVqD02JxfLF7nA6sg3UlYgtiGw61oH68lSbx16P3vwSeQQpEB5JbhofW7t9TLZIbIW/ODnI4hpwj8didtk7IMBI3Ra3uUP7ya6vptkd9TwQkd/7cOFaSJmU+BIsLpOXbirJACMn+URoDXhuEtiO6xirNtrPN8jYqpwvMUm5lMMVzGT3kMMVNBqgbj8Ln8VmqouK0DR+gRyNb8fHT0BFPwsHxDskFk5yhe5c/2VUUoKCGe0kfCcX/EsHbJLUUtlHXmTqaOJpmQnW1tZ/siPwKRl6oEsIJWTUYxPQmrM2fUpYZCuAo/29lTLHiHMlTbarFOd6J/ybIbICy2gRRH/LFSryty3Cnf6aae+A9uizFBUdCwTwffc3vCBae802+R92OL78bbqHKPbSZOXNC+6ybqziezwG+OPWHx1Qk39RYaF0aFsM4uZWrFic97WwVrH5i+/Nsf/OtwWiuH0gV/SqvN1hnkxCTF/+XNn/laWKmS3e7wFzBsG8+qwqwmO9aVbDVMhOmeUXRMkxcj4QreQkHxLkCx97euZpC7xhvYnCHarHTDeD6nVK+xzbPNtzeGzNpYoiMqxZ9bBJwMaHnEoI944Vxoodf51cMIIwpTmmRvAzI1QgrfnOLOUS7uUjQ/IZ1Qa3lY08Nqm9MAGxZ2Ou6R0/Z5z30ha/Q71q6meAs3uHQcpSuRaQeV29IASmye2A2Nif+lmbhV7w8hjFYoaLCRsdchiVyNjOEM4VmxUhX4VEvw6KoCAZ/XvO2eBF/SyNU3Of4SO",
+  "kind": 1059,
+  "created_at": 1703021488,
+  "pubkey": "18b1a75918f1f2c90c23da616bce317d36e348bcf5f7ba55e75949319210c87c",
+  "id": "5c005f3ccf01950aa8d131203248544fb1e41a0d698e846bd419cec3890903ac",
+  "sig": "35fabdae4634eb630880a1896a886e40fd6ea8a60958e30b89b33a93e6235df750097b04f9e13053764251b8bc5dd7e8e0794a3426a90b6bcc7e5ff660f54259"
+  "tags": [["p", "166bf3765ebd1fc55decfe395beff2ea3b2a4e0a8946e7eb578512b555737c99"]],
+}
+```
+
+## 4. Broadcast Selectively
+
+Broadcast the `kind 1059` event to the recipient's relays only. Delete all the other events.
+
+# Code Samples
+
+## JavaScript
+
+```javascript
+import {bytesToHex} from "@noble/hashes/utils"
+import type {EventTemplate, UnsignedEvent, Event} from "nostr-tools"
+import {getPublicKey, getEventHash, nip19, nip44, finalizeEvent, generateSecretKey} from "nostr-tools"
+
+type Rumor = UnsignedEvent & {id: string}
+
+const TWO_DAYS = 2 * 24 * 60 * 60
+
+const now = () => Math.round(Date.now() / 1000)
+const randomNow = () => Math.round(now() - (Math.random() * TWO_DAYS))
+
+const nip44ConversationKey = (privateKey: Uint8Array, publicKey: string) =>
+  nip44.v2.utils.getConversationKey(bytesToHex(privateKey), publicKey)
+
+const nip44Encrypt = (data: EventTemplate, privateKey: Uint8Array, publicKey: string) =>
+  nip44.v2.encrypt(JSON.stringify(data), nip44ConversationKey(privateKey, publicKey))
+
+const nip44Decrypt = (data: Event, privateKey: Uint8Array) =>
+  JSON.parse(nip44.v2.decrypt(data.content, nip44ConversationKey(privateKey, data.pubkey)))
+
+const createRumor = (event: Partial<UnsignedEvent>, privateKey: Uint8Array) => {
+  const rumor = {
+    created_at: now(),
+    content: "",
+    tags: [],
+    ...event,
+    pubkey: getPublicKey(privateKey),
+  } as any
+
+  rumor.id = getEventHash(rumor)
+
+  return rumor as Rumor
+}
+
+const createSeal = (rumor: Rumor, privateKey: Uint8Array, recipientPublicKey: string) => {
+  return finalizeEvent(
+    {
+      kind: 13,
+      content: nip44Encrypt(rumor, privateKey, recipientPublicKey),
+      created_at: randomNow(),
+      tags: [],
+    },
+    privateKey
+  ) as Event
+}
+
+const createWrap = (event: Event, recipientPublicKey: string) => {
+  const randomKey = generateSecretKey()
+
+  return finalizeEvent(
+    {
+      kind: 1059,
+      content: nip44Encrypt(event, randomKey, recipientPublicKey),
+      created_at: randomNow(),
+      tags: [["p", recipientPublicKey]],
+    },
+    randomKey
+  ) as Event
+}
+
+// Test case using the above example
+const senderPrivateKey = nip19.decode(`nsec1p0ht6p3wepe47sjrgesyn4m50m6avk2waqudu9rl324cg2c4ufesyp6rdg`).data
+const recipientPrivateKey = nip19.decode(`nsec1uyyrnx7cgfp40fcskcr2urqnzekc20fj0er6de0q8qvhx34ahazsvs9p36`).data
+const recipientPublicKey = getPublicKey(recipientPrivateKey)
+
+const rumor = createRumor(
+  {
+    kind: 1,
+    content: "Are you going to the party tonight?",
+  },
+  senderPrivateKey
+)
+
+const seal = createSeal(rumor, senderPrivateKey, recipientPublicKey)
+const wrap = createWrap(seal, recipientPublicKey)
+
+// Recipient unwraps with his/her private key.
+
+const unwrappedSeal = nip44Decrypt(wrap, recipientPrivateKey)
+const unsealedRumor = nip44Decrypt(unwrappedSeal, recipientPrivateKey)
+```

65.md

@@ -19,7 +19,7 @@ The `.content` is not used.
     ["r", "wss://alicerelay.example.com"],
     ["r", "wss://brando-relay.com"],
     ["r", "wss://expensive-relay.example2.com", "write"],
-    ["r", "wss://nostr-relay.example.com", "read"],
+    ["r", "wss://nostr-relay.example.com", "read"]
   ],
   "content": "",
   ...other fields

72.md

@@ -12,7 +12,7 @@ The goal of this NIP is to create moderator-approved public communities around a
 
 `kind:34550` SHOULD include any field that helps define the community and the set of moderators. `relay` tags MAY be used to describe the preferred relay to download requests and approvals.
 
-```json
+```jsonc
 {
   "created_at": <Unix timestamp in seconds>,
   "kind": 34550,
@@ -42,14 +42,14 @@ The goal of this NIP is to create moderator-approved public communities around a
 
 Any Nostr event can be submitted to a community by anyone for approval. Clients MUST add the community's `a` tag to the new post event in order to be presented for the moderator's approval.
 
-```json
+```jsonc
 {
   "kind": 1,
   "tags": [
     ["a", "34550:<community event author pubkey>:<community-d-identifier>", "<optional-relay-url>"],
   ],
   "content": "hello world",
-  ...
+  // ...
 }
 ```
 
@@ -59,7 +59,7 @@ Community management clients MAY filter all mentions to a given `kind:34550` eve
 
 The post-approval event MUST include `a` tags of the communities the moderator is posting into (one or more), the `e` tag of the post and `p` tag of the author of the post (for approval notifications). The event SHOULD also include the stringified `post request` event inside the `.content` ([NIP-18-style](18.md)) and a `k` tag with the original post's event kind to allow filtering of approved posts by kind.
 
-```json
+```jsonc
 {
   "pubkey": "<32-bytes lowercase hex-encoded public key of the event creator>",
   "kind": 4550,
@@ -70,7 +70,7 @@ The post-approval event MUST include `a` tags of the communities the moderator i
     ["k", "<post-request-kind>"]
   ],
   "content": "<the full approved event, JSON-encoded>",
-  ...
+  // ...
 }
 ```
 

92.md

@@ -0,0 +1,45 @@
+NIP-92
+======
+
+Media Attachments
+-----------------
+
+Media attachments (images, videos, and other files) may be added to events by including a URL in the event content, along with a matching `imeta` tag.
+
+`imeta` ("inline metadata") tags add information about media URLs in the event's content. Each `imeta` tag SHOULD match a URL in the event content. Clients may replace imeta URLs with rich previews.
+
+The `imeta` tag is variadic, and each entry is a space-delimited key/value pair.
+Each `imeta` tag MUST have a `url`, and at least one other field. `imeta` may include
+any field specified by [NIP 94](./94.md). There SHOULD be only one `imeta` tag per URL.
+
+## Example
+
+```json
+{
+  "content": "More image metadata tests don’t mind me https://nostr.build/i/my-image.jpg",
+  "kind": 1,
+  "tags": [
+    [
+      "imeta",
+      "url https://nostr.build/i/my-image.jpg",
+      "m image/jpeg",
+      "blurhash eVF$^OI:${M{o#*0-nNFxakD-?xVM}WEWB%iNKxvR-oetmo#R-aen$",
+      "dim 3024x4032",
+      "alt A scenic photo overlooking the coast of Costa Rica",
+      "x <sha256 hash as specified in NIP 94>",
+      "fallback https://nostrcheck.me/alt1.jpg",
+      "fallback https://void.cat/alt1.jpg"
+    ]
+  ]
+}
+```
+
+## Recommended client behavior
+
+When uploading files during a new post, clients MAY include this metadata
+after the file is uploaded and included in the post.
+
+When pasting URLs during post composition, the client MAY download the file
+and add this metadata before the post is sent.
+
+The client MAY ignore `imeta` tags that do not match the URL in the event content.

94.md

@@ -25,6 +25,7 @@ This NIP specifies the use of the `1063` event type, having in `content` a descr
 * `image` (optional) url of preview image with same dimensions
 * `summary` (optional) text excerpt
 * `alt` (optional) description for accessibility
+* `fallback` (optional) zero or more fallback file sources in case `url` fails
 
 ```json
 {

96.md

@@ -189,7 +189,7 @@ Note that if the server didn't apply any transformation to the received file, bo
 `Clients` may upload the same file to one or many `servers`.
 After 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.
 
-Alternatively, instead of using NIP-94, the `client` can share or embed on a nostr note just the above url with added "ox" [NIP-54](54.md) inline metadata field and optionally other ones.
+Alternatively, instead of using NIP-94, the `client` can share or embed on a nostr note just the above url.
 
 ### Delayed Processing
 
@@ -273,7 +273,7 @@ The `server` should reject deletes from users other than the original uploader.
 It 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
 in the same file hash).
 
-The successfull response is a 200 OK one with just basic JSON fields:
+The successful response is a 200 OK one with just basic JSON fields:
 
 ```
 {

99.md

@@ -40,6 +40,7 @@ The following tags, used for structured metadata, are standardized and SHOULD be
   - `"<number>"` is the amount in numeric format (but included in the tag as a string)
   - `"<currency>"` is the currency unit in 3-character ISO 4217 format or ISO 4217-like currency code (e.g. `"btc"`, `"eth"`).
   - `"<frequency>"` is optional and can be used to describe recurring payments. SHOULD be in noun format (hour, day, week, month, year, etc.)
+- - `"status"` (optional), the status of the listing. SHOULD be either "active" or "sold".
 
 #### `price` examples
 

BREAKING.md

@@ -0,0 +1,45 @@
+# Breaking Changes
+
+This is a history of NIP changes that potentially break pre-existing implementations, in
+reverse chronological order.
+
+| Date        | Commit    | NIP      | Change |
+| ----------- | --------- | -------- | ------ |
+| 2024-02-16  | [cbec02ab](https://github.com/nostr-protocol/nips/commit/cbec02ab) | [NIP-49](49.md) | Password first normalized to NFKC |
+| 2024-02-15  | [afbb8dd0](https://github.com/nostr-protocol/nips/commit/afbb8dd0) | [NIP-39](39.md) | PGP identity was removed |
+| 2024-02-07  | [d3dad114](https://github.com/nostr-protocol/nips/commit/d3dad114) | [NIP-46](46.md) | Connection token format was changed |
+| 2024-01-30  | [1a2b21b6](https://github.com/nostr-protocol/nips/commit/1a2b21b6) | [NIP-59](59.md) | 'p' tag became optional |
+| 2023-01-27  | [c2f34817](https://github.com/nostr-protocol/nips/commit/c2f34817) | [NIP-47](47.md) | optional expiration tag should be honored |
+| 2024-01-10  | [3d8652ea](https://github.com/nostr-protocol/nips/commit/3d8652ea) | [NIP-02](02.md) | list entries should be chronological |
+| 2024-01-10  | [3d8652ea](https://github.com/nostr-protocol/nips/commit/3d8652ea) | [NIP-51](51.md) | list entries should be chronological |
+| 2023-12-30  | [29869821](https://github.com/nostr-protocol/nips/commit/29869821) | [NIP-52](52.md) | 'name' tag was removed (use 'title' tag instead) |
+| 2023-12-27  | [17c67ef5](https://github.com/nostr-protocol/nips/commit/17c67ef5) | [NIP-94](94.md) | 'aes-256-gcm' tag was removed |
+| 2023-12-03  | [0ba45895](https://github.com/nostr-protocol/nips/commit/0ba45895) | [NIP-01](01.md) | WebSocket status code `4000` was replaced by 'CLOSED' message |
+| 2023-11-28  | [6de35f9e](https://github.com/nostr-protocol/nips/commit/6de35f9e) | [NIP-89](89.md) | 'client' tag value was changed |
+| 2023-11-20  | [7822a8b1](https://github.com/nostr-protocol/nips/commit/7822a8b1) | [NIP-51](51.md) | `kind: 30000` and `kind: 30001` were deprecated |
+| 2023-11-11  | [cbdca1e9](https://github.com/nostr-protocol/nips/commit/cbdca1e9) | [NIP-84](84.md) | 'range' tag was removed |
+| 2023-11-07  | [108b7f16](https://github.com/nostr-protocol/nips/commit/108b7f16) | [NIP-01](01.md) | 'OK' message must have 4 items |
+| 2023-10-17  | [cf672b76](https://github.com/nostr-protocol/nips/commit/cf672b76) | [NIP-03](03.md) | 'block' tag was removed |
+| 2023-09-29  | [7dc6385f](https://github.com/nostr-protocol/nips/commit/7dc6385f) | [NIP-57](57.md) | optional 'a' tag was included in `zap receipt` |
+| 2023-08-21  | [89915e02](https://github.com/nostr-protocol/nips/commit/89915e02) | [NIP-11](11.md) | 'min_prefix' was removed |
+| 2023-08-20  | [37c4375e](https://github.com/nostr-protocol/nips/commit/37c4375e) | [NIP-01](01.md) | replaceable events with same timestamp should be retained event with lowest id |
+| 2023-08-15  | [88ee873c](https://github.com/nostr-protocol/nips/commit/88ee873c) | [NIP-15](15.md) | 'countries' tag was renamed to 'regions' |
+| 2023-08-14  | [72bb8a12](https://github.com/nostr-protocol/nips/commit/72bb8a12) | [NIP-12](12.md) | NIP-12, 16, 20 and 33 were merged into NIP-01 |
+| 2023-08-14  | [72bb8a12](https://github.com/nostr-protocol/nips/commit/72bb8a12) | [NIP-16](16.md) | NIP-12, 16, 20 and 33 were merged into NIP-01 |
+| 2023-08-14  | [72bb8a12](https://github.com/nostr-protocol/nips/commit/72bb8a12) | [NIP-20](20.md) | NIP-12, 16, 20 and 33 were merged into NIP-01 |
+| 2023-08-14  | [72bb8a12](https://github.com/nostr-protocol/nips/commit/72bb8a12) | [NIP-33](33.md) | NIP-12, 16, 20 and 33 were merged into NIP-01 |
+| 2023-08-11  | [d87f8617](https://github.com/nostr-protocol/nips/commit/d87f8617) | [NIP-25](25.md) | empty `content` should be considered as "+" |
+| 2023-08-01  | [5d63b157](https://github.com/nostr-protocol/nips/commit/5d63b157) | [NIP-57](57.md) | 'zap' tag was changed |
+| 2023-07-15  | [d1814405](https://github.com/nostr-protocol/nips/commit/d1814405) | [NIP-01](01.md) | `since` and `until` filters should be `since <= created_at <= until` |
+| 2023-07-12  | [a1cd2bd8](https://github.com/nostr-protocol/nips/commit/a1cd2bd8) | [NIP-25](25.md) | custom emoji was supported |
+| 2023-06-18  | [83cbd3e1](https://github.com/nostr-protocol/nips/commit/83cbd3e1) | [NIP-11](11.md) | 'image' was renamed to 'icon' |
+| 2023-04-13  | [bf0a0da6](https://github.com/nostr-protocol/nips/commit/bf0a0da6) | [NIP-15](15.md) | different NIP was re-added as NIP-15 |
+| 2023-04-09  | [fb5b7c73](https://github.com/nostr-protocol/nips/commit/fb5b7c73) | [NIP-15](15.md) | NIP-15 was merged into NIP-01 |
+| 2023-03-15  | [e1004d3d](https://github.com/nostr-protocol/nips/commit/e1004d3d) | [NIP-19](19.md) | `1: relay` was changed to optionally |
+
+Breaking changes prior to 2023-03-01 are not yet documented.
+
+## NOTES
+
+- If it isn't clear that a change is breaking or not, we list it.
+- The date is the date it was merged, not necessarily the date of the commit.

README.md

@@ -15,6 +15,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 - [Criteria for acceptance of NIPs](#criteria-for-acceptance-of-nips)
 - [Is this repository a centralizing factor?](#is-this-repository-a-centralizing-factor)
 - [How this repository works](#how-this-repository-works)
+- [Breaking Changes](#breaking-changes)
 - [License](#license)
 
 ---
@@ -57,6 +58,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 - [NIP-46: Nostr Connect](46.md)
 - [NIP-47: Wallet Connect](47.md)
 - [NIP-48: Proxy Tags](48.md)
+- [NIP-49: Private Key Encryption](49.md)
 - [NIP-50: Search Capability](50.md)
 - [NIP-51: Lists](51.md)
 - [NIP-52: Calendar Events](52.md)
@@ -64,6 +66,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 - [NIP-56: Reporting](56.md)
 - [NIP-57: Lightning Zaps](57.md)
 - [NIP-58: Badges](58.md)
+- [NIP-59: Gift Wrap](59.md)
 - [NIP-65: Relay List Metadata](65.md)
 - [NIP-72: Moderated Communities](72.md)
 - [NIP-75: Zap Goals](75.md)
@@ -71,6 +74,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 - [NIP-84: Highlights](84.md)
 - [NIP-89: Recommended Application Handlers](89.md)
 - [NIP-90: Data Vending Machines](90.md)
+- [NIP-92: Media Attachments](92.md)
 - [NIP-94: File Metadata](94.md)
 - [NIP-96: HTTP File Storage Integration](96.md)
 - [NIP-98: HTTP Auth](98.md)
@@ -88,13 +92,17 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `6`           | Repost                     | [18](18.md)              |
 | `7`           | Reaction                   | [25](25.md)              |
 | `8`           | Badge Award                | [58](58.md)              |
+| `13`          | Seal                       | [59](59.md)              |
 | `16`          | Generic Repost             | [18](18.md)              |
 | `40`          | Channel Creation           | [28](28.md)              |
 | `41`          | Channel Metadata           | [28](28.md)              |
 | `42`          | Channel Message            | [28](28.md)              |
 | `43`          | Channel Hide Message       | [28](28.md)              |
 | `44`          | Channel Mute User          | [28](28.md)              |
+| `1021`        | Bid                        | [15](15.md)              |
+| `1022`        | Bid confirmation           | [15](15.md)              |
 | `1040`        | OpenTimestamps             | [03](03.md)              |
+| `1059`        | Gift Wrap                  | [59](59.md)              |
 | `1063`        | File Metadata              | [94](94.md)              |
 | `1311`        | Live Chat Message          | [53](53.md)              |
 | `1971`        | Problem Tracker            | [nostrocket][nostrocket] |
@@ -118,6 +126,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `10007`       | Search relays list         | [51](51.md)              |
 | `10015`       | Interests list             | [51](51.md)              |
 | `10030`       | User emoji list            | [51](51.md)              |
+| `10096`       | File storage server list   | [96](96.md)              |
 | `13194`       | Wallet Info                | [47](47.md)              |
 | `21000`       | Lightning Pub RPC          | [Lightning.Pub][lnpub]   |
 | `22242`       | Client Authentication      | [42](42.md)              |
@@ -135,9 +144,12 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `30015`       | Interest sets              | [51](51.md)              |
 | `30017`       | Create or update a stall   | [15](15.md)              |
 | `30018`       | Create or update a product | [15](15.md)              |
+| `30019`       | Marketplace UI/UX          | [15](15.md)              |
+| `30020`       | Product sold as an auction | [15](15.md)              |
 | `30023`       | Long-form Content          | [23](23.md)              |
 | `30024`       | Draft Long-form Content    | [23](23.md)              |
 | `30030`       | Emoji sets                 | [51](51.md)              |
+| `30063`       | Release artifact sets      | [51](51.md)              |
 | `30078`       | Application-specific Data  | [78](78.md)              |
 | `30311`       | Live Event                 | [53](53.md)              |
 | `30315`       | User Statuses              | [38](38.md)              |
@@ -194,6 +206,7 @@ Please update these lists when proposing NIPs introducing new event kinds.
 | `l`               | label, label namespace               | annotations          | [32](32.md)                           |
 | `L`               | label namespace                      | --                   | [32](32.md)                           |
 | `m`               | MIME type                            | --                   | [94](94.md)                           |
+| `q`               | event id (hex)                       | relay URL    | [18](18.md)                           |
 | `r`               | a reference (URL, etc)               | petname              |                                       |
 | `r`               | relay url                            | marker               | [65](65.md)                           |
 | `t`               | hashtag                              | --                   |                                       |
@@ -210,6 +223,7 @@ Please update these lists when proposing NIPs introducing new event kinds.
 | `expiration`      | unix timestamp (string)              | --                   | [40](40.md)                           |
 | `goal`            | event id (hex)                       | relay URL            | [75](75.md)                           |
 | `image`           | image URL                            | dimensions in pixels | [23](23.md), [58](58.md)              |
+| `imeta`           | inline metadata                      | --                   | [92](92.md)                           |
 | `lnurl`           | `bech32` encoded `lnurl`             | --                   | [57](57.md)                           |
 | `location`        | location string                      | --                   | [52](52.md), [99](99.md)              |
 | `name`            | badge name                           | --                   | [58](58.md)                           |
@@ -220,6 +234,7 @@ Please update these lists when proposing NIPs introducing new event kinds.
 | `published_at`    | unix timestamp (string)              | --                   | [23](23.md)                           |
 | `relay`           | relay url                            | --                   | [42](42.md)                           |
 | `relays`          | relay list                           | --                   | [57](57.md)                           |
+| `server`          | file storage server url              | --                   | [96](96.md)                           |
 | `subject`         | subject                              | --                   | [14](14.md)                           |
 | `summary`         | article summary                      | --                   | [23](23.md)                           |
 | `thumb`           | badge thumbnail                      | dimensions in pixels | [58](58.md)                           |
@@ -248,6 +263,10 @@ Standards may emerge in two ways: the first way is that someone starts doing som
 
 These two ways of standardizing things are supported by this repository. Although the second is preferred, an effort will be made to codify standards emerged outside this repository into NIPs that can be later referenced and easily understood and implemented by others -- but obviously as in any human system discretion may be applied when standards are considered harmful.
 
+## Breaking Changes
+
+[Breaking Changes](BREAKING.md)
+
 ## License
 
 All NIPs are public domain.