make relays for nip-60 wallets explicit

2025-12-09 16:48:50 +00:00 · 2025-03-12 16:36:14 +00:00
15 changed files with 90 additions and 114 deletions
--- a/01.md
+++ b/01.md
@@ -75,7 +75,7 @@ The first element of the tag array is referred to as the tag _name_ or _key_ and

 This NIP defines 3 standard tags that can be used across all event kinds with the same meaning. They are as follows:

- The `e` tag, used to refer to an event: `["e", <32-bytes lowercase hex of the id of another event>, <recommended relay URL, optional>, <32-bytes lowercase hex of the author's pubkey, optional>]`
+- The `e` tag, used to refer to an event: `["e", <32-bytes lowercase hex of the id of another event>, <recommended relay URL, optional>]`
 - The `p` tag, used to refer to another user: `["p", <32-bytes lowercase hex of a pubkey>, <recommended relay URL, optional>]`
 - The `a` tag, used to refer to an addressable or replaceable event
    - for an addressable event: `["a", <kind integer>:<32-bytes lowercase hex of a pubkey>:<d tag value>, <recommended relay URL, optional>]`
@@ -168,10 +168,9 @@ 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`, `restricted`, and `error` for when none of that fits.
+- The standardized machine-readable prefixes for `OK` and `CLOSED` are: `duplicate`, `pow`, `blocked`, `rate-limited`, `invalid`, and `error` for when none of that fits.
--- a/05.md
+++ b/05.md
@@ -101,9 +101,3 @@ Users should ensure that their `/.well-known/nostr.json` is served with the HTTP
 The `/.well-known/nostr.json` endpoint MUST NOT return any HTTP redirects.

 Fetchers MUST ignore any HTTP redirects given by the `/.well-known/nostr.json` endpoint.
-
-### Implementing a NIP-05 server
-
-NIP-05 is designed so that `nostr.json` can be hosted as a static file. But some services may allow users to sign up and be granted a NIP-05. The `nostr.json` is then served dynamically, depending on the `name` query parameter.
-
-For these servers, the **case** of the localpart should be considered. It is recommended to make the lowercase representation unique in the database, so that two people cannot reserve the same name in different cases (eg `chad` vs `Chad`). Servers may then serve any case variation of the name, allowing users to freely change the case of their name. However, the name in the server's response MUST match the case provided by the `name` query parameter.
--- a/07.md
+++ b/07.md
@@ -17,6 +17,7 @@ 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
--- a/10.md
+++ b/10.md
@@ -10,34 +10,25 @@ 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` 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.
+`e` and `p` tags can be used to define note threads, replies and mentions. 

 Markup languages such as markdown and HTML SHOULD NOT be used. 

 ## Marked "e" tags (PREFERRED)
-
-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"`.
+ * `<marker>` is optional and if present is one of `"reply"`, `"root"`, or `"mention"`.
 * `<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 `"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.

 A direct reply to the root of a thread should have a single marked "e" tag of type "root".

--- a/17.md
+++ b/17.md
@@ -35,46 +35,6 @@ 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.
@@ -85,7 +45,7 @@ An optional `subject` tag defines the current name/topic of the conversation. An

 ## Encrypting

-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.
+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.

 ```jsonc
 {
--- a/22.md
+++ b/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](73.md).
+A comment is a threading note always scoped to a root event or an `I`-tag.

 It uses `kind:1111` with plaintext `.content` (no HTML, Markdown, or other formatting).

@@ -198,3 +198,4 @@ A reply to a podcast comment:
  // other fields
 }
 ```
+
--- a/46.md
+++ b/46.md
@@ -100,6 +100,7 @@ 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>`                                                          |
--- a/47.md
+++ b/47.md
@@ -1,7 +1,7 @@
 NIP-47
 ======

-Nostr Wallet Connect (NWC)
+Nostr Wallet Connect
 --------------------

 `draft` `optional`
@@ -17,9 +17,6 @@ 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.  
@@ -48,7 +45,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 **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.
+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](04.md), and is a JSON-RPCish object with a semi-fixed structure:
@@ -83,7 +80,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 **client**.
+The notification event SHOULD contain one `p` tag, the public key of the **user**.

 The content of notifications is encrypted with [NIP04](04.md), and is a JSON-RPCish object with a semi-fixed structure:

@@ -108,27 +105,19 @@ 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.

-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:
+The **wallet service** generates this connection URI with protocol `nostr+walletconnect://` and base path its hex-encoded `pubkey` with the following query string parameters:

 - `relay` Required. URL of the relay where the **wallet service** is connected and will be listening for events. May be more than one.
- `secret` Required. 32-byte randomly generated hex encoded string. The **client** MUST use this to sign events and encrypt payloads when communicating with the **wallet service**. The **wallet service** MUST use the corresponding public key of this secret to communicate with the **client**.
+- `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**.
    - 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, 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.
+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.

 ### Example connection string
 ```sh
--- a/51.md
+++ b/51.md
@@ -24,7 +24,6 @@ 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)                                                                 |
--- a/53.md
+++ b/53.md
@@ -35,8 +35,7 @@ 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", /*...*/],
-    ["pinned", "<event id of pinned live chat message>"],
+    ["relays", "wss://one.com", "wss://two.com", /*...*/]
  ],
  "content": "",
  // other fields...
@@ -76,8 +75,6 @@ Event `kind:1311` is live chat's channel message. Clients MUST include the `a` t
 }
 ```

-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).
--- a/55.md
+++ b/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 (to accept/reject permissions manually) and Content Resolvers (to accept/reject permissions automatically in background if the user allowed it) to communicate between applications.
+The Android signer uses Intents and Content Resolvers 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 after you receive the response from **get_public_key** method:
+Set the Signer package name:

 ```kotlin
 intent.`package` = "com.example.signer"
@@ -114,6 +114,7 @@ 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(
@@ -129,7 +130,7 @@ launcher.launch(intent)
    context.startActivity(intent)
    ```
  - result:
-    - If the user approved the intent it will return the **pubkey** in the result field and the signer packageName in the **package** field
+    - If the user approved intent it will return the **pubkey** in the result field

      ```kotlin
      val pubkey = intent.data?.getStringExtra("result")
@@ -261,6 +262,29 @@ 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:

@@ -315,8 +339,6 @@ 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
@@ -342,8 +364,6 @@ 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")
@@ -370,8 +390,6 @@ 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)
@@ -396,8 +414,6 @@ 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)
@@ -422,8 +438,6 @@ 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)
@@ -448,14 +462,36 @@ 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:

@@ -474,8 +510,6 @@ 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)
@@ -538,6 +572,13 @@ 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:

--- a/57.md
+++ b/57.md
@@ -132,7 +132,7 @@ The following should be true of the `zap receipt` event:
 - `tags` MUST include the `p` tag (zap recipient) AND optional `e` tag from the `zap request` AND optional `a` tag from the `zap request` AND optional `P` tag from the pubkey of the zap request (zap sender).
 - The `zap receipt` MUST have a `bolt11` tag containing the description hash bolt11 invoice.
 - The `zap receipt` MUST contain a `description` tag which is the JSON-encoded zap request.
- `SHA256(description)` SHOULD match the description hash in the bolt11 invoice.
+- `SHA256(description)` MUST match the description hash in the bolt11 invoice.
 - The `zap receipt` MAY contain a `preimage` tag to match against the payment hash of the bolt11 invoice. This isn't really a payment proof, there is no real way to prove that the invoice is real or has been paid. You are trusting the author of the `zap receipt` for the legitimacy of the payment.

 The `zap receipt` is not a proof of payment, all it proves is that some nostr user fetched an invoice. The existence of the `zap receipt` implies the invoice as paid, but it could be a lie given a rogue implementation.
--- a/60.md
+++ b/60.md
@@ -28,7 +28,9 @@ This NIP doesn't deal with users' *receiving* money from someone else, it's just
    "content": nip44_encrypt([
        [ "privkey", "hexkey" ],
        [ "mint", "https://mint1" ],
-        [ "mint", "https://mint2" ]
+        [ "mint", "https://mint2" ],
+        [ "relay", "wss://relay1" ],
+        [ "relay", "wss://relay2" ]
    ]),
    "tags": []
 }
@@ -39,6 +41,7 @@ The wallet event is an replaceable event `kind:17375`.
 Tags:
 * `mint` - Mint(s) this wallet uses -- there MUST be one or more mint tags.
 * `privkey` - Private key used to unlock P2PK ecash. MUST be stored encrypted in the `.content` field. **This is a different private key exclusively used for the wallet, not associated in any way to the user's Nostr private key** -- This is only used for receiving [NIP-61](61.md) nutzaps.
+* `relay` - Relay(s) where wallet events should be published. If present, clients SHOULD publish all wallet-related events (`kind:7375`, `kind:7376`, etc.) to these relays. There MAY be multiple `relay` entries. If no `relay` entries are present, clients SHOULD fall back to using the user's [NIP-65](65.md) relays.

 ## Token Event
 Token events are used to record unspent proofs.
--- a/61.md
+++ b/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", "<nutzapped-event-id>", "<relay-hint>" ],
+        [ "e", "<zapped-event-id>", "<relay-hint>" ],
        [ "p", "e9fbced3a42dcf551486650cc752ab354347dd413b307484e4fd1818ab53f991" ], // recipient of nutzap
    ]
 }
@@ -94,11 +94,12 @@ Multiple `kind:9321` events can be tagged in the same `kind:7376` event.
    "content": nip44_encrypt([
        [ "direction", "in" ], // in = received, out = sent
        [ "amount", "1" ],
-        [ "e", "<7375-event-id>", "<relay-hint>", "created" ] // new token event that was created
+        [ "e", "<7375-event-id>", "relay-hint", "created" ] // new token event that was created
    ]),
    "tags": [
-        [ "e", "<9321-event-id>", "<relay-hint>", "redeemed" ], // nutzap event that has been redeemed
-        [ "p", "<sender-pubkey>" ] // pubkey of the author of the 9321 event (nutzap sender)
+        [ "a", "37375:<pubkey>:my-wallet" ], // an optional wallet tag
+        [ "e", "<9321-event-id>", "relay-hint", "redeemed" ], // nutzap event that has been redeemed
+        [ "p", "sender-pubkey" ] // pubkey of the author of the 9321 event (nutzap sender)
    ]
 }
 ```
--- a/README.md
+++ b/README.md
@@ -119,7 +119,6 @@ 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)                            |
@@ -169,7 +168,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), [51](51.md)               |
+| `10002`       | Relay List Metadata             | [65](65.md)                            |
 | `10003`       | Bookmark list                   | [51](51.md)                            |
 | `10004`       | Communities list                | [51](51.md)                            |
 | `10005`       | Public chats list               | [51](51.md)                            |