recommend using "k" tag always.

Co-authored-by: fiatjaf_ <fiatjaf@gmail.com>
Co-authored-by: K <kehiiiiya@gmail.com>

01.md

@@ -168,9 +168,10 @@ This NIP defines no rules for how `NOTICE` messages should be sent or treated.
   * `["OK", "b1a649ebe8...", false, "rate-limited: slow down there chief"]`
   * `["OK", "b1a649ebe8...", false, "invalid: event creation date is too far off from the current time"]`
   * `["OK", "b1a649ebe8...", false, "pow: difficulty 26 is less than 30"]`
+  * `["OK", "b1a649ebe8...", false, "restricted: not allowed to write."]`
   * `["OK", "b1a649ebe8...", false, "error: could not connect to the database"]`
 - `CLOSED` messages MUST be sent in response to a `REQ` when the relay refuses to fulfill it. It can also be sent when a relay decides to kill a subscription on its side before a client has disconnected or sent a `CLOSE`. This message uses the same pattern of `OK` messages with the machine-readable prefix and human-readable message. Some examples:
   * `["CLOSED", "sub1", "unsupported: filter contains unknown elements"]`
   * `["CLOSED", "sub1", "error: could not connect to the database"]`
   * `["CLOSED", "sub1", "error: shutting down idle subscription"]`
-- The standardized machine-readable prefixes for `OK` and `CLOSED` are: `duplicate`, `pow`, `blocked`, `rate-limited`, `invalid`, and `error` for when none of that fits.
+- The standardized machine-readable prefixes for `OK` and `CLOSED` are: `duplicate`, `pow`, `blocked`, `rate-limited`, `invalid`, `restricted`, and `error` for when none of that fits.

07.md

@@ -17,7 +17,6 @@ async window.nostr.signEvent(event: { created_at: number, kind: number, tags: st
 
 Aside from these two basic above, the following functions can also be implemented optionally:
 ```
-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

10.md

@@ -10,25 +10,34 @@ This NIP defines `kind:1` as a simple plaintext note.
 
 ## Abstract
 
-This NIP describes how to use "e" and "p" tags in text events, especially those that are replies to other text events. It helps clients thread the replies into a tree rooted at the original event.
-
 The `.content` property contains some human-readable text. 
 
-`e` and `p` tags can be used to define note threads, replies and mentions. 
+`e` tags can be used to define note thread roots and replies. They SHOULD be sorted by the reply stack from root to the direct parent.
+
+`q` tags MAY be used when citing events in the `.content` with [NIP-21](21.md).
+
+```json
+["q", "<event-id> or <event-address>", "<relay-url>", "<pubkey-if-a-regular-event>"]
+```
+
+Authors of the `e` and `q` tags SHOULD be added as `p` tags to notify of a new reply or quote.
 
 Markup languages such as markdown and HTML SHOULD NOT be used. 
 
 ## Marked "e" tags (PREFERRED)
+
+Kind 1 events with `e` tags are replies to other kind 1 events. Kind 1 replies MUST NOT be used to reply to other kinds, use [NIP-22](22.md) instead. 
+
 `["e", <event-id>, <relay-url>, <marker>, <pubkey>]`
 
 Where:
 
  * `<event-id>` is the id of the event being referenced.
  * `<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 `""`.
- * `<marker>` is optional and if present is one of `"reply"`, `"root"`, or `"mention"`.
+ * `<marker>` is optional and if present is one of `"reply"`, `"root"`.
  * `<pubkey>` is optional, SHOULD be the pubkey of the author of the referenced event
 
-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.
+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. 
 
 A direct reply to the root of a thread should have a single marked "e" tag of type "root".
 

17.md

@@ -35,6 +35,46 @@ Tags that mention, quote and assemble threading structures MUST follow [NIP-10](
 
 Kind `14`s MUST never be signed. If it is signed, the message might leak to relays and become **fully public**.
 
+## File Message Kind
+
+```jsonc
+{
+  "id": "<usual hash>",
+  "pubkey": "<sender-pubkey>",
+  "created_at": "<current-time>",
+  "kind": 15,
+  "tags": [
+    ["p", "<receiver-1-pubkey>", "<relay-url>"],
+    ["p", "<receiver-2-pubkey>", "<relay-url>"],
+    ["e", "<kind-14-id>", "<relay-url>", "reply"], // if this is a reply
+    ["subject", "<conversation-title>"],
+    ["file-type", "<file-mime-type>"],
+    ["encryption-algorithm", "<encryption-algorithm>"],
+    ["decryption-key", "<decryption-key>"],
+    ["decryptiion-nonce", "<decryption-nonce>"],
+    ["x", "<the SHA-256 hexencoded string of the file>"],
+    // rest of tags...
+  ],
+  "content": "<file-url>"
+}
+```
+
+Kind 15 is used for sending encrypted file event messages:
+
+- `file-type`: Specifies the MIME type of the attached file (e.g., `image/jpeg`, `audio/mpeg`, etc.).
+- `encryption-algorithm`: Indicates the encryption algorithm used for encrypting the file. Supported algorithms may include `aes-gcm`, `chacha20-poly1305`,`aes-cbc` etc.
+- `decryption-key`: The decryption key that will be used by the recipient to decrypt the file.
+- `decryption-nonce`: The decryption nonce that will be used by the recipient to decrypt the file.
+- `content`: The URL of the file (`<file-url>`).
+- `x` containing the SHA-256 hexencoded string of the file.
+- `size` (optional) size of file in bytes
+- `dim` (optional) size of file in pixels in the form `<width>x<height>`
+- `blurhash`(optional) the [blurhash](https://github.com/woltapp/blurhash) to show while the file is being loaded by the client
+- `thumb` (optional) url of thumbnail with same aspect ratio
+- `fallback` (optional) zero or more fallback file sources in case `url` fails
+
+Just like kind 14, kind `15`s MUST never be signed.
+
 ## Chat Rooms
 
 The set of `pubkey` + `p` tags defines a chat room. If a new `p` tag is added or a current one is removed, a new room is created with clean message history.
@@ -45,7 +85,7 @@ An optional `subject` tag defines the current name/topic of the conversation. An
 
 ## Encrypting
 
-Following [NIP-59](59.md), the **unsigned** `kind:14` chat message must be sealed (`kind:13`) and then gift-wrapped (`kind:1059`) to each receiver and the sender individually.
+Following [NIP-59](59.md), the **unsigned** `kind:14` & `kind:15` chat message must be sealed (`kind:13`) and then gift-wrapped (`kind:1059`) to each receiver and the sender individually.
 
 ```jsonc
 {

22.md

@@ -6,7 +6,7 @@ Comment
 
 `draft` `optional`
 
-A comment is a threading note always scoped to a root event or an `I`-tag.
+A comment is a threading note always scoped to a root event or an [`I`-tag](73.md).
 
 It uses `kind:1111` with plaintext `.content` (no HTML, Markdown, or other formatting).
 
@@ -198,4 +198,3 @@ A reply to a podcast comment:
   // other fields
 }
 ```
-

25.md

@@ -25,26 +25,21 @@ consider it a "+".
 Tags
 ----
 
-The reaction event SHOULD include `e` and `p` tags from the note the user is reacting to (and optionally `a` tags if the target is a replaceable event). This allows users to be notified of reactions to posts they were mentioned in. Including the `e` tags enables clients to pull all the reactions associated with individual posts or all the posts in a thread. `a` tags enables clients to seek reactions for all versions of a replaceable event.
+There MUST be always an `e` tag set to the `id` of the event that is being reacted to. The `e` tag SHOULD include a relay hint pointing to a relay where the event being reacted to can be found. If a client decides to include other `e`, which not recommended, the target event `id` should be last of the `e` tags.
 
-The last `e` tag MUST be the `id` of the note that is being reacted to.
+The SHOULD be a `p` tag set to the `pubkey` of the event being reacted to. If a client decides to include other `p` tags, which not recommended, the target event `pubkey` should be last the `p` tags.
 
-The last `p` tag MUST be the `pubkey` of the event being reacted to.
+If the event being reacted to is an addressable event, an `a` SHOULD be included together with the `e` tag, it must be set to the coordinates (`kind:pubkey:d-tag`) of the event being reacted to.
 
-The `a` tag MUST contain the coordinates (`kind:pubkey:d-tag`) of the replaceable being reacted to.
+The reaction SHOULD include a `k` tag with the stringified kind number of the reacted event as its value.
 
-The reaction event MAY include a `k` tag with the stringified kind number of the reacted event as its value.
-
-Example code
+**Example code**
 
 ```swift
 func make_like_event(pubkey: String, privkey: String, liked: NostrEvent) -> NostrEvent {
-    var tags: [[String]] = liked.tags.filter {
-    	tag in tag.count >= 2 && (tag[0] == "e" || tag[0] == "p")
-    }
-    tags.append(["e", liked.id])
+    tags.append(["e", liked.id, liked.source_relays.first ?? ""])
     tags.append(["p", liked.pubkey])
-    tags.append(["k", liked.kind])
+    tags.append(["k", String(liked.kind)])
     let ev = NostrEvent(content: "+", pubkey: pubkey, kind: 7, tags: tags)
     ev.calculate_id()
     ev.sign(privkey: privkey)

27.md

@@ -10,7 +10,7 @@ This document standardizes the treatment given by clients of inline references o
 
 When creating an event, clients should include mentions to other profiles and to other events in the middle of the `.content` using [NIP-21](21.md) codes, such as `nostr:nprofile1qqsw3dy8cpu...6x2argwghx6egsqstvg`.
 
-Including [NIP-10](10.md)-style tags (`["e", <hex-id>, <relay-url>, <marker>]`) for each reference is optional, clients should do it whenever they want the profile being mentioned to be notified of the mention, or when they want the referenced event to recognize their mention as a reply.
+Including [NIP-18](18.md)'s quote tags (`["q", "<event-id> or <event-address>", "<relay-url>", "<pubkey-if-a-regular-event>"]`) for each reference is optional, clients should do it whenever they want the profile being mentioned to be notified of the mention, or when they want the referenced event to recognize their mention as a reply.
 
 A reader client that receives an event with such `nostr:...` mentions in its `.content` can do any desired context augmentation (for example, linking to the profile or showing a preview of the mentioned event contents) it wants in the process. If turning such mentions into links, they could become internal links, [NIP-21](21.md) links or direct links to web clients that will handle these references.
 

34.md

@@ -22,9 +22,10 @@ Git repositories are hosted in Git-enabled servers, but their existence can be a
     ["description", "brief human-readable project description>"],
     ["web", "<url for browsing>", ...], // a webpage url, if the git server being used provides such a thing
     ["clone", "<url for git-cloning>", ...], // a url to be given to `git clone` so anyone can clone it
-    ["relays", "<relay-url>", ...] // relays that this repository will monitor for patches and issues
-    ["r", "<earliest-unique-commit-id>", "euc"]
-    ["maintainers", "<other-recognized-maintainer>", ...]
+    ["relays", "<relay-url>", ...], // relays that this repository will monitor for patches and issues
+    ["r", "<earliest-unique-commit-id>", "euc"],
+    ["maintainers", "<other-recognized-maintainer>", ...],
+    ["t", "<arbitrary string>"], // hashtags labelling the repository
   ]
 }
 ```

46.md

@@ -100,7 +100,6 @@ Each of the following are methods that the _client_ sends to the _remote-signer_
 | `connect`                | `[<remote-signer-pubkey>, <optional_secret>, <optional_requested_permissions>]`        | "ack" OR `<required-secret-value>`                                                                  |
 | `sign_event`             | `[<{kind, content, tags, created_at}>]`                                       | `json_stringified(<signed_event>)`                                     |
 | `ping`                   | `[]`                                                                          | "pong"                                                                 |
-| `get_relays`             | `[]`                                                                          | `json_stringified({<relay_url>: {read: <boolean>, write: <boolean>}})` |
 | `get_public_key`         | `[]`                                                                          | `<user-pubkey>`                                                         |
 | `nip04_encrypt`          | `[<third_party_pubkey>, <plaintext_to_encrypt>]`                              | `<nip04_ciphertext>`                                                   |
 | `nip04_decrypt`          | `[<third_party_pubkey>, <nip04_ciphertext_to_decrypt>]`                       | `<plaintext>`                                                          |

47.md

@@ -1,7 +1,7 @@
 NIP-47
 ======
 
-Nostr Wallet Connect
+Nostr Wallet Connect (NWC)
 --------------------
 
 `draft` `optional`
@@ -17,6 +17,9 @@ 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
+
+Fundamentally NWC is communication between a **client** and **wallet service** by the means of E2E-encrypted direct messages over a nostr relay. The relay knows the kinds and tags of notes, but not the content of the encrypted payloads. The **user**'s identity key is not used to avoid linking payment activity to the user. Ideally unique keys are used for each individual connection.
+
  1. **Users** who wish to use this NIP to allow **client(s)** to interact with their wallet 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** (or the **client** on the user's behalf) wants to interact with the wallet.  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.  
@@ -45,7 +48,7 @@ If the **wallet service** supports notifications, the info event SHOULD contain
 
 ### Request and Response Events
 
-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.
+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 **client** 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](04.md), and is a JSON-RPCish object with a semi-fixed structure:
@@ -80,7 +83,7 @@ If the command was successful, the `error` field must be null.
 
 ### Notification Events
 
-The notification event SHOULD contain one `p` tag, the public key of the **user**.
+The notification event SHOULD contain one `p` tag, the public key of the **client**.
 
 The content of notifications is encrypted with [NIP04](04.md), and is a JSON-RPCish object with a semi-fixed structure:
 
@@ -105,19 +108,27 @@ The content of notifications is encrypted with [NIP04](04.md), and is a JSON-RPC
 - `OTHER`: Other error.
 
 ## Nostr Wallet Connect URI
-**client** discovers **wallet service** by scanning a QR code, handling a deeplink or pasting in a URI.
 
-The **wallet service** generates this connection URI with protocol `nostr+walletconnect://` and base path its hex-encoded `pubkey` with the following query string parameters:
+Communication between the **client** and **wallet service** requires two keys in order to encrypt and decrypt messages. The connection URI includes the secret key of the **client** and only the public key of the **wallet service**.
+
+The **client** discovers **wallet service** by scanning a QR code, handling a deeplink or pasting in a URI.
+
+The **wallet service** generates this connection URI with protocol `nostr+walletconnect://` and base path its 32-byte hex-encoded `pubkey`, which SHOULD be unique per client connection.
+
+The connection URI contains the following query string parameters:
 
 - `relay` Required. URL of the relay where the **wallet service** is connected and will be listening for events. May be more than one.
-- `secret` Required. 32-byte randomly generated hex encoded string. The **client** MUST use this to sign events and encrypt payloads when communicating with the **wallet service**.
+- `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**. The **wallet service** MUST use the corresponding public key of this secret to communicate with the **client**.
     - Authorization does not require passing keys back and forth.
     - The user can have different keys for different applications. Keys can be revoked and created at will and have arbitrary constraints (eg. budgets).
     - The key is harder to leak since it is not shown to the user and backed up.
     - It improves privacy because the user's main key would not be linked to their payments.
 - `lud16` Recommended. A lightning address that clients can use to automatically setup the `lud16` field on the user's profile if they have none configured.
 
-The **client** should then store this connection and use it when the user wants to perform actions like paying an invoice. Due to this NIP using ephemeral events, it is recommended to pick relays that do not close connections on inactivity to not drop events.
+The **client** should then store this connection and use it when the user wants to perform actions like paying an invoice. Due to this NIP using ephemeral events, it is recommended to pick relays that do not close connections on inactivity to not drop events, and ideally retain the events until they are either consumed or become stale.
+
+- When the **client** sends or receives a message it will use the `secret` from the connection URI and **wallet service**'s `pubkey` to encrypt or decrypt.
+- When the **wallet service** sends or receives a message it will use its own secret and the corresponding pubkey of the **client's** `secret` to encrypt or decrypt. The **wallet service** SHOULD NOT store the secret it generates for the client and MUST NOT rely on the knowing the **client** secret for general operation.
 
 ### Example connection string
 ```sh

51.md

@@ -24,6 +24,7 @@ For example, _mute list_ can contain the public keys of spammers and bad actors
 | ---               | ---   | ---                                                         | ---                                                                                                 |
 | 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)                                                                                |
+| Read/write relays | 10002 | where a user publishes to and where they expect mentions    | see [NIP-65](65.md)                                                                                 |
 | 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)                                                                 |

53.md

@@ -35,7 +35,8 @@ For example:
     ["p", "91cf9..4e5ca", "wss://provider1.com/", "Host", "<proof>"],
     ["p", "14aeb..8dad4", "wss://provider2.com/nostr", "Speaker"],
     ["p", "612ae..e610f", "ws://provider3.com/ws", "Participant"],
-    ["relays", "wss://one.com", "wss://two.com", /*...*/]
+    ["relays", "wss://one.com", "wss://two.com", /*...*/],
+    ["pinned", "<event id of pinned live chat message>"],
   ],
   "content": "",
   // other fields...
@@ -62,7 +63,7 @@ This feature is important to avoid malicious event owners adding large account h
 
 ### Live Chat Message
 
-Event `kind:1311` is live chat's channel message. Clients MUST include the `a` tag of the activity with a `root` marker. Other Kind-1 tags such as `reply` and `mention` can also be used.
+Event `kind:1311` is live chat's channel message. Clients MUST include the `a` tag of the activity. An `e` tag denotes the direct parent message this post is replying to. 
 
 ```jsonc
 {
@@ -75,6 +76,14 @@ Event `kind:1311` is live chat's channel message. Clients MUST include the `a` t
 }
 ```
 
+`q` tags MAY be used when citing events in the `.content` with [NIP-21](21.md).
+
+```json
+["q", "<event-id> or <event-address>", "<relay-url>", "<pubkey-if-a-regular-event>"]
+```
+
+Hosts may choose to pin one or more live chat messages by updating the `pinned` tags in the live event kind `30311`.
+
 ## Use Cases
 
 Common use cases include meeting rooms/workshops, watch-together activities, or event spaces, such as [zap.stream](https://zap.stream).

55.md

@@ -10,7 +10,7 @@ This NIP describes a method for 2-way communication between an Android signer an
 
 # Usage for Android applications
 
-The Android signer uses Intents and Content Resolvers to communicate between applications.
+The Android signer uses Intents (to accept/reject permissions manually) and Content Resolvers (to accept/reject permissions automatically in background if the user allowed it) to communicate between applications.
 
 To be able to use the Android signer in your application you should add this to your AndroidManifest.xml:
 
@@ -66,7 +66,7 @@ Create the Intent using the **nostrsigner** scheme:
 val intent = Intent(Intent.ACTION_VIEW, Uri.parse("nostrsigner:$content"))
 ```
 
-Set the Signer package name:
+Set the Signer package name after you receive the response from **get_public_key** method:
 
 ```kotlin
 intent.`package` = "com.example.signer"
@@ -114,7 +114,6 @@ launcher.launch(intent)
 
     ```kotlin
     val intent = Intent(Intent.ACTION_VIEW, Uri.parse("nostrsigner:"))
-    intent.`package` = "com.example.signer"
     intent.putExtra("type", "get_public_key")
     // You can send some default permissions for the user to authorize for ever
     val permissions = listOf(
@@ -130,7 +129,7 @@ launcher.launch(intent)
     context.startActivity(intent)
     ```
   - result:
-    - If the user approved intent it will return the **pubkey** in the result field
+    - If the user approved the intent it will return the **pubkey** in the result field and the signer packageName in the **package** field
 
       ```kotlin
       val pubkey = intent.data?.getStringExtra("result")
@@ -262,29 +261,6 @@ launcher.launch(intent)
       val id = intent.data?.getStringExtra("id")
       ```
 
-- **get_relays**
-  - params:
-
-    ```kotlin
-    val intent = Intent(Intent.ACTION_VIEW, Uri.parse("nostrsigner:"))
-    intent.`package` = "com.example.signer"
-    intent.putExtra("type", "get_relays")
-    // to control the result in your application in case you are not waiting the result before sending another intent
-    intent.putExtra("id", "some_id")
-    // Send the current logged in user pubkey
-    intent.putExtra("current_user", account.keyPair.pubkey)
-
-    context.startActivity(intent)
-    ```
-  - result:
-    - If the user approved intent it will return the **result** and **id** fields
-
-      ```kotlin
-      val relayJsonText = intent.data?.getStringExtra("result")
-      // the id you sent
-      val id = intent.data?.getStringExtra("id")
-      ```
-
 - **decrypt_zap_event**
   - params:
 
@@ -339,6 +315,8 @@ If the user chose to always reject the event, signer application will return the
       ```kotlin
         if (result == null) return
 
+        if (it.getColumnIndex("rejected") > -1) return
+
         if (result.moveToFirst()) {
             val index = it.getColumnIndex("result")
             if (index < 0) return
@@ -364,6 +342,8 @@ If the user chose to always reject the event, signer application will return the
       ```kotlin
         if (result == null) return
 
+        if (it.getColumnIndex("rejected") > -1) return
+
         if (result.moveToFirst()) {
             val index = it.getColumnIndex("result")
             val indexJson = it.getColumnIndex("event")
@@ -390,6 +370,8 @@ If the user chose to always reject the event, signer application will return the
       ```kotlin
         if (result == null) return
 
+        if (it.getColumnIndex("rejected") > -1) return
+
         if (result.moveToFirst()) {
             val index = it.getColumnIndex("result")
             val encryptedText = it.getString(index)
@@ -414,6 +396,8 @@ If the user chose to always reject the event, signer application will return the
       ```kotlin
         if (result == null) return
 
+        if (it.getColumnIndex("rejected") > -1) return
+
         if (result.moveToFirst()) {
             val index = it.getColumnIndex("result")
             val encryptedText = it.getString(index)
@@ -438,6 +422,8 @@ If the user chose to always reject the event, signer application will return the
       ```kotlin
         if (result == null) return
 
+        if (it.getColumnIndex("rejected") > -1) return
+
         if (result.moveToFirst()) {
             val index = it.getColumnIndex("result")
             val encryptedText = it.getString(index)
@@ -462,36 +448,14 @@ If the user chose to always reject the event, signer application will return the
       ```kotlin
         if (result == null) return
 
+        if (it.getColumnIndex("rejected") > -1) return
+
         if (result.moveToFirst()) {
             val index = it.getColumnIndex("result")
             val encryptedText = it.getString(index)
         }
       ```
 
-- **get_relays**
-  - params:
-
-    ```kotlin
-    val result = context.contentResolver.query(
-        Uri.parse("content://com.example.signer.GET_RELAYS"),
-        listOf("${logged_in_user_pubkey}"),
-        null,
-        null,
-        null
-    )
-    ```
-  - result:
-    - Will return the **result** column
-
-      ```kotlin
-        if (result == null) return
-
-        if (result.moveToFirst()) {
-            val index = it.getColumnIndex("result")
-            val relayJsonText = it.getString(index)
-        }
-      ```
-
 - **decrypt_zap_event**
   - params:
 
@@ -510,6 +474,8 @@ If the user chose to always reject the event, signer application will return the
       ```kotlin
         if (result == null) return
 
+        if (it.getColumnIndex("rejected") > -1) return
+
         if (result.moveToFirst()) {
             val index = it.getColumnIndex("result")
             val eventJson = it.getString(index)
@@ -572,13 +538,6 @@ Android intents and browser urls have limitations, so if you are using the `retu
     window.href = `nostrsigner:${encryptedText}?pubkey=${hex_pub_key}&compressionType=none&returnType=signature&type=nip44_decrypt&callbackUrl=https://example.com/?event=`;
     ```
 
-- **get_relays**
-  - params:
-
-    ```js
-    window.href = `nostrsigner:?compressionType=none&returnType=signature&type=get_relays&callbackUrl=https://example.com/?event=`;
-    ```
-
 - **decrypt_zap_event**
   - params:
 

61.md

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

62.md

@@ -0,0 +1,61 @@
+NIP-62
+======
+
+Request to Vanish
+-----------------
+
+`draft` `optional`
+
+This NIP offers a Nostr-native way to request a complete reset of a key's fingerprint on the web. This procedure is legally binding in some jurisdictions, and thus, supporters of this NIP should truly delete events from their database. 
+
+## Request to Vanish from Relay
+
+Kind `62` requests a specific relay to delete everything, including [NIP-09](09.md) Deletion Events, from the `.pubkey` until its `.created_at`. 
+
+```jsonc
+{
+  "kind": 62,
+  "pubkey": <32-byte hex-encoded public key of the event creator>,
+  "tags": [
+    ["relay", "<relay url>"]
+  ],
+  "content": "<reason or note>",
+  //...other fields
+}
+```
+
+The tag list MUST include at least one `relay` value. 
+
+Content MAY include a reason or a legal notice to the relay operator. 
+
+Relays MUST fully delete any events from the `.pubkey` if their service URL is tagged in the event. 
+
+Relays SHOULD delete all [NIP-59](59.md) Gift Wraps that p-tagged the `.pubkey` if their service URL is tagged in the event, deleting all DMs to the pubkey.
+
+Relays MUST ensure the deleted events cannot be re-broadcasted into the relay. 
+
+Relays MAY store the signed request to vanish for bookkeeping.
+
+Paid relays or relays that restrict who can post MUST also follow the request to vanish regardless of the user's status. 
+
+Publishing a deletion request event (Kind `5`) against a request to vanish has no effect. Clients and relays are not obliged to support "unrequest vanish" functionality.
+
+Clients SHOULD send this event to the target relays only. 
+
+## Global Request to Vanish
+
+To request ALL relays to delete everything, the event MUST include a `relay` tag with the value `ALL_RELAYS` in uppercase. 
+
+```jsonc
+{
+  "kind": 62,
+  "pubkey": <32-byte hex-encoded public key of the event creator>,
+  "tags": [
+    ["relay", "ALL_RELAYS"]
+  ],
+  "content": "<reason>",
+  //...other fields
+}
+```
+
+Clients SHOULD broadcast this event to as many relays as possible. 

BREAKING.md

@@ -5,6 +5,8 @@ reverse chronological order.
 
 | Date        | Commit    | NIP      | Change |
 | ----------- | --------- | -------- | ------ |
+| 2025-02-14  | [81908b6e](https://github.com/nostr-protocol/nips/commit/81908b6e) | [07](07.md), [46](46.md), [55](55.md) | `getRelays` and `get_relays` were removed |
+| 2025-02-07  | [0023ca81](https://github.com/nostr-protocol/nips/commit/0023ca81) | [10](10.md) | `"mention"` marker was removed |
 | 2025-01-31  | [6a4b125a](https://github.com/nostr-protocol/nips/commit/6a4b125a) | [71](71.md) | video events were changed to regular |
 | 2024-12-05  | [6d16019e](https://github.com/nostr-protocol/nips/commit/6d16019e) | [46](46.md) | message encryption was changed to NIP-44 |
 | 2024-11-12  | [2838e3bd](https://github.com/nostr-protocol/nips/commit/2838e3bd) | [29](29.md) | `kind: 12` and `kind: 10` were removed (use `kind: 1111` instead) |

README.md

@@ -77,6 +77,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 - [NIP-59: Gift Wrap](59.md)
 - [NIP-60: Cashu Wallet](60.md)
 - [NIP-61: Nutzaps](61.md)
+- [NIP-62: Request to Vanish](62.md)
 - [NIP-64: Chess (PGN)](64.md)
 - [NIP-65: Relay List Metadata](65.md)
 - [NIP-68: Picture-first feeds](68.md)
@@ -119,6 +120,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `12`          | Group Thread Reply              | 29 (deprecated)                        |
 | `13`          | Seal                            | [59](59.md)                            |
 | `14`          | Direct Message                  | [17](17.md)                            |
+| `15`          | File Message                    | [17](17.md)                            |
 | `16`          | Generic Repost                  | [18](18.md)                            |
 | `17`          | Reaction to a website           | [25](25.md)                            |
 | `20`          | Picture                         | [68](68.md)                            |
@@ -129,6 +131,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `42`          | Channel Message                 | [28](28.md)                            |
 | `43`          | Channel Hide Message            | [28](28.md)                            |
 | `44`          | Channel Mute User               | [28](28.md)                            |
+| `62`          | Request to Vanish               | [62](62.md)                            |
 | `64`          | Chess (PGN)                     | [64](64.md)                            |
 | `818`         | Merge Requests                  | [54](54.md)                            |
 | `1018`        | Poll Response                   | [88](88.md)                            |
@@ -168,7 +171,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `9802`        | Highlights                      | [84](84.md)                            |
 | `10000`       | Mute list                       | [51](51.md)                            |
 | `10001`       | Pin list                        | [51](51.md)                            |
-| `10002`       | Relay List Metadata             | [65](65.md)                            |
+| `10002`       | Relay List Metadata             | [65](65.md), [51](51.md)               |
 | `10003`       | Bookmark list                   | [51](51.md)                            |
 | `10004`       | Communities list                | [51](51.md)                            |
 | `10005`       | Public chats list               | [51](51.md)                            |
@@ -298,7 +301,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `s`               | status                               | --                              | [69](69.md)                                        |
 | `t`               | hashtag                              | --                              | [24](24.md), [34](34.md), [35](35.md)              |
 | `u`               | url                                  | --                              | [61](61.md), [98](98.md)                           |
-| `x`               | infohash                             | --                              | [35](35.md)                                        |
+| `x`               | hash                                 | --                              | [35](35.md), [56](56.md)                           |
 | `y`               | platform                             | --                              | [69](69.md)                                        |
 | `z`               | order number                         | --                              | [69](69.md)                                        |
 | `-`               | --                                   | --                              | [70](70.md)                                        |