nip37: non-harmful editable short notes.

NIP-55: Add intent flags to open the signer once when sending multiple events

29.md

@@ -22,6 +22,12 @@ Relays are supposed to generate the events that describe group metadata and grou
 
 A group may be identified by a string in the format `<host>'<group-id>`. For example, a group with _id_ `abcdef` hosted at the relay `wss://groups.nostr.com` would be identified by the string `groups.nostr.com'abcdef`.
 
+Group identifiers must be strings restricted to the characters `a-z0-9-_`.
+
+When encountering just the `<host>` without the `'<group-id>`, clients can choose to connect to the group with id `_`, which is a special top-level group dedicated to relay-local discussions.
+
+Group identifiers in most cases should be random or pseudo-random, as that mitigates message replay confusiong and ensures they can be migrated or forked to other relays easily without risking conflicting with other groups using the same id in these new relays. This isn't a hard rule, as, for example, in `unmanaged` and/or ephemeral relays groups might not want to migrate ever, so they might not care about this. Notably, the `_` relay-local group isn't expected to be migrated ever.
+
 ## The `h` tag
 
 Events sent by users to groups (chat messages, text notes, moderation events etc) must have an `h` tag with the value set to the group _id_.
@@ -36,8 +42,30 @@ This is a hack to prevent messages from being broadcasted to external relays tha
 
 Relays should prevent late publication (messages published now with a timestamp from days or even hours ago) unless they are open to receive a group forked or moved from another relay.
 
+## Group management
+
+Groups can have any number of users with elevated access. These users are identified by role labels which are arbitrarily defined by the relays (see also the description of `kind:39003`). What each role is capable of not defined in this NIP either, it's a relay policy that can vary. Roles can be assigned by other users (as long as they have the capability to add roles) by publishing a `kind:9000` event with that user's pubkey in a `p` tag and the roles afterwards (even if the user is already a group member a `kind:9000` can be issued and the user roles must just be updated).
+
+The roles supported by the group as to having some special privilege assigned to them should be accessible on the event `kind:39003`, but the relay may also accept other role names, arbitrarily defined by clients, and just not do anything with them.
+
+Users with any roles that have any privilege can be considered _admins_ in a broad sense and be returned in the `kind:39001` event for a group.
+
+## Unmanaged groups
+
+Unmanaged groups are impromptu groups that can be used in any public relay unaware of NIP-29 specifics. They piggyback on relays' natural white/blacklists (or lack of) but aside from that are not actively managed and won't have any admins, group state or metadata events.
+
+In `unmanaged` groups, everybody is considered to be a member.
+
+Unmanaged groups can transition to managed groups, in that case the relay master key just has to publish moderation events setting the state of all groups and start enforcing the rules they choose to.
+
 ## Event definitions
 
+These are the events expected to be found in NIP-29 groups.
+
+### Normal user-created events
+
+These events generally can be sent by all members of a group and they require the `h` tag to be present so they're attached to a specific group.
+
 - *text root note* (`kind:11`)
 
 This is the basic unit of a "microblog" root text note sent to a group.
@@ -79,6 +107,14 @@ Similar to `kind:12`, this is the basic unit of a chat message sent to a group.
 
 `kind:10` SHOULD use NIP-10 markers, just like `kind:12`.
 
+- other events:
+
+Groups may also accept other events, like long-form articles, calendar, livestream, market announcements and so on. These should be as defined in their respective NIPs, with the addition of the `h` tag.
+
+### User-related group management events
+
+These are events that can be sent by users to manage their situation in a group, they also require the `h` tag.
+
 - *join request* (`kind:9021`)
 
 Any user can send one of these events to the relay in order to be automatically or manually added to the group. If the group is `open` the relay will automatically issue a `kind:9000` in response adding this user. Otherwise group admins may choose to query for these requests and act upon them.
@@ -88,11 +124,14 @@ Any user can send one of these events to the relay in order to be automatically
   "kind": 9021,
   "content": "optional reason",
   "tags": [
-    ["h", "<group-id>"]
+    ["h", "<group-id>"],
+    ["code", "<optional-invite-code>"]
   ]
 }
 ```
 
+The optional `code` tag may be used by the relay to preauthorize acceptances in `closed` groups, together with the `kind:9009` `create-invite` moderation event.
+
 - *leave request* (`kind:9022`)
 
 Any user can send one of these events to the relay in order to be automatically removed from the group. The relay will automatically issue a `kind:9001` in response removing this user.
@@ -107,9 +146,13 @@ Any user can send one of these events to the relay in order to be automatically
 }
 ```
 
+### Group state -- or moderation
+
+These are events expected to be sent by the relay master key or by group admins -- and relays should reject them if they don't come from an authorized admin. They also require the `h` tag.
+
 - *moderation events* (`kinds:9000-9020`) (optional)
 
-Clients can send these events to a relay in order to accomplish a moderation action. Relays must check if the pubkey sending the event is capable of performing the given action. The relay may discard the event after taking action or keep it as a moderation log.
+Clients can send these events to a relay in order to accomplish a moderation action. Relays must check if the pubkey sending the event is capable of performing the given action based on its role and the relay's internal policy (see also the description of `kind:39003`).
 
 ```json
 {
@@ -124,17 +167,20 @@ Clients can send these events to a relay in order to accomplish a moderation act
 
 Each moderation action uses a different kind and requires different arguments, which are given as tags. These are defined in the following table:
 
-| kind | name                | tags                                      |
+| kind | name                | tags                                           |
-| ---  | ---                 | ---                                       |
+| ---  | ---                 | ---                                            |
-| 9000 | `add-user`          | `p` (pubkey hex)                          |
+| 9000 | `add-user`          | `p` with pubkey hex and optional roles         |
-| 9001 | `remove-user`       | `p` (pubkey hex)                          |
+| 9001 | `remove-user`       | `p` with pubkey hex                            |
-| 9002 | `edit-metadata`     | `name`, `about`, `picture` (string)       |
+| 9002 | `edit-metadata`     | fields from `kind:39000` to be modified        |
-| 9003 | `add-permission`    | `p` (pubkey), `permission` (name)         |
+| 9005 | `delete-event`      |                                                |
-| 9004 | `remove-permission` | `p` (pubkey), `permission` (name)         |
+| 9007 | `create-group`      |                                                |
-| 9005 | `delete-event`      | `e` (id hex)                              |
+| 9008 | `delete-group`      |                                                |
-| 9006 | `edit-group-status` | `public` or `private`, `open` or `closed` |
+
-| 9007 | `create-group`      |                                           |
+It's expected that the group state (of who is an allowed member or not, who is an admin and with which permission or not, what are the group name and picture etc) can be fully reconstructed from the canonical sequence of these events.
-| 9008 | `delete-group`      |                                           |
+
+### Group metadata events
+
+These events contain the group id in a `d` tag instead of the `h` tag. They MUST be created by the relay master key only and a single instance of each (or none) should exist at all times for each group. They are merely informative but should reflect the latest group state (as it was changed by moderation events over time).
 
 - *group metadata* (`kind:39000`) (optional)
 
@@ -142,6 +188,8 @@ This event defines the metadata for the group -- basically how clients should di
 
 If the group is forked and hosted in multiple relays, there will be multiple versions of this event in each different relay and so on.
 
+When this event is not found, clients may still connect to the group, but treat it as having a different status, `unmanaged`,
+
 ```jsonc
 {
   "kind": 39000,
@@ -162,41 +210,29 @@ If the group is forked and hosted in multiple relays, there will be multiple ver
 
 - *group admins* (`kind:39001`) (optional)
 
-Similar to the group metadata, this event is supposed to be generated by relays that host the group.
+Each admin is listed along with one or more roles. These roles SHOULD have a correspondence with the roles supported by the relay, as advertised by the `kind:39003` event.
 
-Each admin gets a label that is only used for display purposes, and a list of permissions it has are listed afterwards. These permissions can inform client building UI, but ultimately are evaluated by the relay in order to become effective.
+```jsonc
-
-The list of capabilities, as defined by this NIP, for now, is the following:
-
-- `add-user`
-- `edit-metadata`
-- `delete-event`
-- `remove-user`
-- `add-permission`
-- `remove-permission`
-- `edit-group-status`
-- `delete-group`
-
-```json
 {
   "kind": 39001,
   "content": "list of admins for the pizza lovers group",
   "tags": [
     ["d", "<group-id>"],
-    ["p", "<pubkey1-as-hex>", "ceo", "add-user", "edit-metadata", "delete-event", "remove-user"],
+    ["p", "<pubkey1-as-hex>", "ceo"],
-    ["p", "<pubkey2-as-hex>", "secretary", "add-user", "delete-event"]
+    ["p", "<pubkey2-as-hex>", "secretary", "gardener"],
-  ]
+    // other pubkeys...
+  ],
   // other fields...
 }
 ```
 
 - *group members* (`kind:39002`) (optional)
 
-Similar to *group admins*, this event is supposed to be generated by relays that host the group.
+It's a list of pubkeys that are members of the group. Relays might choose to not to publish this information, to restrict what pubkeys can fetch it or to only display a subset of the members in it.
 
-It's a NIP-51-like list of pubkeys that are members of the group. Relays might choose to not to publish this information or to restrict what pubkeys can fetch it.
+Clients should not assume this will always be present or that it will contain a full list of members.
 
-```json
+```jsonc
 {
   "kind": 39002,
   "content": "list of members for the pizza lovers group",
@@ -205,10 +241,48 @@ It's a NIP-51-like list of pubkeys that are members of the group. Relays might c
     ["p", "<admin1>"],
     ["p", "<member-pubkey1>"],
     ["p", "<member-pubkey2>"],
-  ]
+    // other pubkeys...
+  ],
+  // other fields...
 }
 ```
 
-## Storing the list of groups a user belongs to
+- *group roles* (`kind:39003`) (optional)
 
-A definition for kind `10009` was included in [NIP-51](51.md) that allows clients to store the list of groups a user wants to remember being in.
+This is an event that MAY be published by the relay informing users and clients about what are the roles supported by this relay according to its internal logic.
+
+For example, a relay may choose to support the roles `"admin"` and `"moderator"`, in which the `"admin"` will be allowed to edit the group metadata, delete messages and remove users from the group, while the `"moderator"` can only delete messages (or the relay may choose to call these roles `"ceo"` and `"secretary"` instead, the exact role name is not relevant).
+
+The process through which the relay decides what roles to support and how to handle moderation events internally based on them is specific to each relay and not specified here.
+
+```jsonc
+{
+  "kind": 39003,
+  "content": "list of roles supported by this group",
+  "tags": [
+    ["d", "<group-id>"],
+    ["role", "<role-name>", "<optional-description>"],
+    ["role", "<role-name>", "<optional-description>"],
+    // other roles...
+  ],
+  // other fields...
+}
+```
+
+## Implementation quirks
+
+### Checking your own membership in a group
+
+The latest of either `kind:9000` or `kind:9001` events present in a group should tell a user that they are currently members of the group or if they were removed. In case none of these exist the user is assumed to not be a member of the group -- unless the group is `unmanaged`, in which case the user is assumed to be a member.
+
+### Adding yourself to a group
+
+When a group is `open`, anyone can send a `kind:9021` event to it in order to be added, then expect a `kind:9000` event to be emitted confirming that the user was added. The same happens with `closed` groups, except in that case a user may only send a `kind:9021` if it has an invite code.
+
+### Storing your list of groups
+
+A definition for `kind:10009` was included in [NIP-51](51.md) that allows clients to store the list of groups a user wants to remember being in.
+
+### Using `unmanaged` relays
+
+To prevent event leakage, replay and confusion, when using `unmanaged` relays, clients should include the [NIP-70](70.md) `-` tag, as just the `previous` tag won't be checked by other `unmanaged` relays.

37.md

@@ -0,0 +1,38 @@
+NIP-37
+======
+
+Editable Short Notes
+--------------------
+
+`draft` `optional`
+
+This NIP describes a flow for clients that want to support editable short notes without breaking the experience of clients that don't and keeping `kind:1` a safe place.
+
+The idea is that editable notes are published as `kind:31000` notes that follow all the same rules of `kind:1`, except for the fact that they can be replaceable anytime.
+
+```jsonc
+{
+  "kind": 31000,
+  "created_at": 1730820000,
+  "content": "I like dogs",
+  "tags": [
+    ["d", "c2huy3f"],
+    // other kind1 tags
+  ]
+}
+```
+
+Clients that want to support edits would automatically only publish `kind:31000` notes, then immediately publish `kind:1` notes that quote the `kind:31000` note.
+
+```jsonc
+{
+  "kind": 1,
+  "created_at": 1730820000,
+  "content": "naddr1...",
+  "tags": [
+    ["q", "31000:...:c2huy3f"]
+  ]
+}
+```
+
+Clients that support this NIP would then fetch the `kind:31000` and display it normally in place of the `kind:1`. Other clients would display the editable event embedded inside the `kind:1`.

55.md

@@ -72,6 +72,35 @@ Set the Signer package name:
 intent.`package` = "com.example.signer"
 ```
 
+If you are sending multiple intents without awaiting you can add some intent flags to sign all events without opening multiple times the signer
+
+```kotlin
+intent.addFlags(Intent.FLAG_ACTIVITY_SINGLE_TOP or Intent.FLAG_ACTIVITY_CLEAR_TOP)
+```
+
+If you are developing a signer application them you need to add this to your AndroidManifest.xml so clients can use the intent flags above
+
+```kotlin
+android:launchMode="singleTop"
+```
+
+Signer MUST answer multiple permissions with an array of results
+
+```kotlin
+
+val results = listOf(
+  Result(
+    package = signerPackageName,
+    result = eventSignture,
+    id = intentId
+  )
+)
+
+val json = results.toJson()
+
+intent.putExtra("results", json)
+```
+
 Send the Intent:
 
 ```kotlin

60.md

@@ -0,0 +1,205 @@
+# NIP-60
+## Cashu Wallet
+`draft` `optional`
+
+This NIP defines the operations of a cashu-based wallet.
+
+A cashu wallet is a wallet which information is stored in relays to make it accessible across applications.
+
+The purpose of this NIP is:
+* ease-of-use: new users immediately are able to receive funds without creating accounts with other services.
+* interoperability: users' wallets follows them across applications.
+
+This NIP doesn't deal with users' *receiving* money from someone else, it's just to keep state of the user's wallet.
+
+# High-level flow
+1. A user has a `kind:37375` event that represents a wallet.
+2. A user has `kind:7375` events that represent the unspent proofs of the wallet. -- The proofs are encrypted with the user's private key.
+3. A user has `kind:7376` events that represent the spending history of the wallet -- This history is for informational purposes only and is completely optional.
+
+## Wallet Event
+```jsonc
+{
+    "kind": 37375,
+    "content": nip44_encrypt([
+        [ "balance", "100", "sat" ],
+        [ "privkey", "hexkey" ] // explained in NIP-61
+    ]),
+    "tags": [
+        [ "d", "my-wallet" ],
+        [ "mint", "https://mint1" ],
+        [ "mint", "https://mint2" ],
+        [ "mint", "https://mint3" ],
+        [ "name", "my shitposting wallet" ],
+        [ "unit", "sat" ],
+        [ "description", "a wallet for my day-to-day shitposting" ],
+        [ "relay", "wss://relay1" ],
+        [ "relay", "wss://relay2" ],
+    ]
+}
+```
+
+The wallet event is a parameterized replaceable event `kind:37375`.
+
+Tags:
+* `d` - wallet ID.
+* `mint` - Mint(s) this wallet uses -- there MUST be one or more mint tags.
+* `relay` - Relays where the wallet and related events can be found. -- one ore more relays SHOULD be specified. If missing, clients should follow [[NIP-65]].
+* `unit` - Base unit of the wallet (e.g. "sat", "usd", etc).
+* `name` - Optional human-readable name for the wallet.
+* `description` - Optional human-readable description of the wallet.
+* `balance` - Optional best-effort balance of the wallet that can serve as a placeholder while an accurate balance is computed from fetching all unspent proofs.
+* `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 when receiving funds from others, described in NIP-61.
+
+Any tag, other than the `d` tag, can be [[NIP-44]] encrypted into the `.content` field.
+
+### Deleting a wallet event
+Due to PRE being hard to delete, if a user wants to delete a wallet, they should empty the event and keep just the `d` identifier and add a `deleted` tag.
+
+## Token Event
+Token events are used to record the unspent proofs that come from the mint.
+
+There can be multiple `kind:7375` events for the same mint, and multiple proofs inside each `kind:7375` event.
+
+```jsonc
+{
+    "kind": 7375,
+    "content": nip44_encrypt({
+        "mint": "https://stablenut.umint.cash",
+        "proofs": [
+            {
+                "id": "005c2502034d4f12",
+                "amount": 1,
+                "secret": "z+zyxAVLRqN9lEjxuNPSyRJzEstbl69Jc1vtimvtkPg=",
+                "C": "0241d98a8197ef238a192d47edf191a9de78b657308937b4f7dd0aa53beae72c46"
+            }
+        ]
+    }),
+    "tags": [
+        [ "a", "37375:<pubkey>:my-wallet" ]
+    ]
+}
+```
+
+`.content` is a [[NIP-44]] encrypted payload storing the mint and the unencoded proofs.
+* `a` an optional tag linking the token to a specific wallet.
+
+### Spending proofs
+When one or more proofs of a token are spent, the token event should be [[NIP-09]]-deleted and, if some proofs are unspent from the same token event, a new token event should be created rolling over the unspent proofs and adding any change outputs to the new token event.
+
+## Spending History Event
+Clients SHOULD publish `kind:7376` events to create a transaction history when their balance changes.
+
+```jsonc
+{
+    "kind": 7376,
+    "content": nip44_encrypt([
+        [ "direction", "in" ], // in = received, out = sent
+        [ "amount", "1", "sat" ],
+        [ "e", "<event-id-of-spent-token>", "<relay-hint>", "created" ],
+    ]),
+    "tags": [
+        [ "a", "37375:<pubkey>:my-wallet" ],
+    ]
+}
+```
+
+* `direction` - The direction of the transaction; `in` for received funds, `out` for sent funds.
+* `a` - The wallet the transaction is related to.
+
+Clients MUST add `e` tags to create references of destroyed and created token events along with the marker of the meaning of the tag:
+* `created` - A new token event was created.
+* `destroyed` - A token event was destroyed.
+* `redeemed` - A [[NIP-61]] nutzap was redeemed.
+
+All tags can be [[NIP-44]] encrypted. Clients SHOULD leave `e` tags with a `redeemed` marker unencrypted.
+
+Multiple `e` tags can be added to a `kind:7376` event.
+
+# Flow
+A client that wants to check for user's wallets information starts by fetching `kind:10019` events from the user's relays, if no event is found, it should fall back to using the user's [[NIP-65]] relays.
+
+## Fetch wallet and token list
+From those relays, the client should fetch wallet and token events.
+
+`"kinds": [37375, 7375], "authors": ["<my-pubkey>"]`
+
+## Fetch proofs
+While the client is fetching (and perhaps validating) proofs it can use the optional `balance` tag of the wallet event to display a estimate of the balance of the wallet.
+
+## Spending token
+If Alice spends 4 sats from this token event
+```jsonconc
+{
+    "kind": 7375,
+    "id": "event-id-1",
+    "content": nip44_encrypt({
+        "mint": "https://stablenut.umint.cash",
+        "proofs": [
+            { "id": "1", "amount": 1 },
+            { "id": "2", "amount": 2 },
+            { "id": "3", "amount": 4 },
+            { "id": "4", "amount": 8 },
+        ]
+    }),
+    "tags": [
+        [ "a", "37375:<pubkey>:my-wallet" ]
+    ]
+}
+```
+
+Her client:
+* MUST roll over the unspent proofs:
+```jsonconc
+{
+    "kind": 7375,
+    "id": "event-id-2",
+    "content": nip44_encrypt({
+        "mint": "https://stablenut.umint.cash",
+        "proofs": [
+            { "id": "1", "amount": 1 },
+            { "id": "2", "amount": 2 },
+            { "id": "4", "amount": 8 },
+        ]
+    }),
+    "tags": [
+        [ "a", "37375:<pubkey>:my-wallet" ]
+    ]
+}
+```
+* MUST delete event `event-id-1`
+* SHOULD create a `kind:7376` event to record the spend
+```jsonconc
+{
+    "kind": 7376,
+    "content": nip44_encrypt([
+        [ "direction", "out" ],
+        [ "amount", "4", "sats" ],
+        [ "e", "<event-id-1>", "<relay-hint>", "destroyed" ],
+        [ "e", "<event-id-2>", "<relay-hint>", "created" ],
+    ]),
+    "tags": [
+        [ "a", "37375:<pubkey>:my-wallet" ],
+    ]
+}
+```
+
+## Redeeming a quote (optional)
+When creating a quote at a mint, an event can be used to keep the state of the quote ID, which will be used to check when the quote has been paid. These events should be created with an expiration tag [[NIP-40]] matching the expiration of the bolt11 received from the mint; this signals to relays when they can safely discard these events.
+
+Application developers are encouraged to use local state when possible and only publish this event when it makes sense in the context of their application.
+
+```jsonc
+{
+    "kind": 7374,
+    "content": nip44_encrypt("quote-id"),
+    "tags": [
+        [ "expiration", "<expiration-timestamp>" ],
+        [ "mint", "<mint-url>" ],
+        [ "a", "37375:<pubkey>:my-wallet" ]
+    ]
+}
+```
+
+## Appendix 1: Validating proofs
+Clients can optionally validate proofs to make sure they are not working from an old state; this logic is left up to particular implementations to decide when and why to do it, but if some proofs are checked and deemed to have been spent, the client should delete the token and roll over any unspent proof.

61.md

@@ -0,0 +1,132 @@
+# NIP-61:
+## Nut Zaps
+
+A Nut Zap is a P2PK cashu token where the payment itself is the receipt.
+
+# High-level flow
+Alice wants to nutzap 1 sat to Bob because of an event `event-id-1` she liked.
+
+## Alice nutzaps Bob
+1. Alice fetches event `kind:10019` from Bob to see the mints Bob trusts.
+2. She mints a token at that mint (or swaps some tokens she already had in that mint) p2pk-locked to the pubkey Bob has listed in his `kind:10019`.
+3. She publishes a `kind:9321` event to the relays Bob indicated with the proofs she minted.
+
+## Bob receives the nutzap
+1. At some point, Bob's client fetches `kind:9321` events p-tagging him from his relays.
+2. Bob's client swaps the token into his wallet.
+
+# Nutzap informational event
+```jsonc
+{
+    "kind": 10019,
+    "tags": [
+        [ "relay", "wss://relay1" ],
+        [ "relay", "wss://relay2" ],
+        [ "mint", "https://mint1", "usd", "sat" ],
+        [ "mint", "https://mint2", "sat" ],
+        [ "pubkey", "<p2pk-pubkey>" ]
+    ]
+}
+```
+
+`kind:10019` is an event that is useful for others to know how to send money to the user.
+
+* `relay` - Relays where the user will be reading token events from. If a user wants to send money to the user, they should write to these relays.
+* `mint` - Mints the user is explicitly agreeing to use to receive funds on. Clients SHOULD not send money on mints not listed here or risk burning their money. Additional markers can be used to list the supported base units of the mint.
+* `pubkey` - Pubkey that SHOULD be used to P2PK-lock receiving nutzaps. If not present, clients SHOULD use the pubkey of the recipient. This is explained in Appendix 1.
+
+## Nutzap event
+Event `kind:9321` is a nutzap event published by the sender, p-tagging the recipient. The outputs are P2PK-locked to the pubkey the recipient indicated in their `kind:10019` event or to the recipient pubkey if the `kind:10019` event doesn't have a explicit pubkey.
+
+Clients MUST prefix the pubkey they p2pk-lock with `"02"` (for nostr<>cashu pubkey compatibility).
+
+```jsonc
+{
+    kind: 9321,
+    content: "Thanks for this great idea.",
+    pubkey: "sender-pubkey",
+    tags: [
+        [ "amount", "1" ],
+        [ "unit", "sat" ],
+        [ "proof", "{\"amount\":1,\"C\":\"02277c66191736eb72fce9d975d08e3191f8f96afb73ab1eec37e4465683066d3f\",\"id\":\"000a93d6f8a1d2c4\",\"secret\":\"[\\\"P2PK\\\",{\\\"nonce\\\":\\\"b00bdd0467b0090a25bdf2d2f0d45ac4e355c482c1418350f273a04fedaaee83\\\",\\\"data\\\":\\\"02eaee8939e3565e48cc62967e2fde9d8e2a4b3ec0081f29eceff5c64ef10ac1ed\\\"}]\"}" ],
+        [ "u", "https://stablenut.umint.cash", ],
+        [ "e", "<zapped-event-id>", "<relay-hint>" ],
+        [ "p", "e9fbced3a42dcf551486650cc752ab354347dd413b307484e4fd1818ab53f991" ], // recipient of nut zap
+    ]
+}
+```
+
+* `.content` is an optional comment for the nutzap
+* `amount` is a shorthand for the combined amount of all outputs. -- Clients SHOULD validate that the sum of the amounts in the outputs matches.
+* `unit` is the base unit of the amount.
+* `proof` is one ore more proofs p2pk-locked to the pubkey the recipient specified in their `kind:10019` event.
+* `u` is the mint the URL of the mint EXACTLY as specified by the recipient's `kind:10019`.
+* `e` zero or one event that is being nutzapped.
+* `p` exactly one pubkey, specifying the recipient of the nutzap.
+
+WIP: Clients SHOULD embed a DLEQ proof in the nutzap event to make it possible to verify nutzaps without talking to the mint.
+
+# Sending a nutzap
+
+* The sender fetches the recipient's `kind:10019`.
+* The sender mints/swaps ecash on one of the recipient's listed mints.
+* The sender p2pk locks to the recipient's specified pubkey in their
+
+# Receiving nutzaps
+
+Clients should REQ for nut zaps:
+* Filtering with `#u` for mints they expect to receive ecash from.
+  * this is to prevent even interacting with mints the user hasn't explicitly signaled.
+* Filtering with `since` of the most recent `kind:7376` event the same user has created.
+  * this can be used as a marker of the nut zaps that have already been swaped by the user -- clients might choose to use other kinds of markers, including internal state -- this is just a guidance of one possible approach.
+
+Clients MIGHT choose to use some kind of filtering (e.g. WoT) to ignore spam.
+
+`{ "kinds": [9321], "#p": "my-pubkey", "#u": [ "<mint-1>", "<mint-2>"], "since": <latest-created_at-of-kind-7376> }`.
+
+Upon receiving a new nut zap, the client should swap the tokens into a wallet the user controls, either a [[NIP-60]] wallet, their own LN wallet or anything else.
+
+## Updating nutzap-redemption history
+When claiming a token the client SHOULD create a `kind:7376` event and `e` tag the original nut zap event. This is to record that this token has already been claimed (and shouldn't be attempted again) and as signaling to the recipient that the ecash has been redeemed.
+
+Multiple `kind:9321` events can be tagged in the same `kind:7376` event.
+
+```jsonc
+{
+    "kind": 7376,
+    "content": nip44_encrypt([
+        [ "direction", "in" ], // in = received, out = sent
+        [ "amount", "1", "sat" ],
+        [ "e", "<7375-event-id>", "relay-hint", "created" ] // new token event that was created
+    ]),
+    "tags": [
+        [ "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)
+    ]
+}
+```
+
+Events that redeem a nutzap SHOULD be published to the sender's [[NIP-65]] relays.
+
+## Verifying a Cashu Zap
+* Clients SHOULD check that the receiving user has issued a `kind:10019` tagging the mint where the cashu has been minted.
+* Clients SHOULD check that the token is locked to the pubkey the user has listed in their `kind:10019`.
+
+## Final Considerations
+
+1. Clients SHOULD guide their users to use NUT-11 (P2PK) compatible-mints in their `kind:10019` event to avoid receiving nut zaps anyone can spend
+
+2. Clients SHOULD normalize and deduplicate mint URLs as described in NIP-65.
+
+3. A nut zap MUST be sent to a mint the recipient has listed in their `kind:10019` event or to the NIP-65 relays of the recipient, failure to do so may result in the recipient donating the tokens to the mint since the recipient might never see the event.
+
+## Appendix 1: Alternative P2PK pubkey
+Clients might not have access to the user's private key (i.e. NIP-07, NIP-46 signing) and, as such, the private key to sign cashu spends might not be available, which would make spending the P2PK incoming nutzaps impossible.
+
+For this scenarios clients can:
+
+* add a `pubkey` tag to the `kind:10019` (indicating which pubkey senders should P2PK to)
+* store the private key in the `kind:37375` event in the nip44-encrypted `content` field.
+
+This is to avoid depending on NIP-07/46 adaptations to sign cashu payloads.

README.md

@@ -73,6 +73,8 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 - [NIP-57: Lightning Zaps](57.md)
 - [NIP-58: Badges](58.md)
 - [NIP-59: Gift Wrap](59.md)
+- [NIP-60: Cashu Wallet](60.md)
+- [NIP-61: Nutzaps](61.md)
 - [NIP-64: Chess (PGN)](64.md)
 - [NIP-65: Relay List Metadata](65.md)
 - [NIP-70: Protected Events](70.md)
@@ -140,8 +142,12 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `5000`-`5999` | Job Request                     | [90](90.md)                            |
 | `6000`-`6999` | Job Result                      | [90](90.md)                            |
 | `7000`        | Job Feedback                    | [90](90.md)                            |
+| `7374`        | Reserved Cashu Wallet Tokens    | [60](60.md)                            |
+| `7375`        | Cashu Wallet Tokens             | [60](60.md)                            |
+| `7376`        | Cashu Wallet History            | [60](60.md)                            |
 | `9000`-`9030` | Group Control Events            | [29](29.md)                            |
 | `9041`        | Zap Goal                        | [75](75.md)                            |
+| `9321`        | Nutzap                          | [61](61.md)                            |
 | `9467`        | Tidal login                     | [Tidal-nostr]                          |
 | `9734`        | Zap Request                     | [57](57.md)                            |
 | `9735`        | Zap                             | [57](57.md)                            |
@@ -156,6 +162,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `10007`       | Search relays list              | [51](51.md)                            |
 | `10009`       | User groups                     | [51](51.md), [29](29.md)               |
 | `10015`       | Interests list                  | [51](51.md)                            |
+| `10019`       | Nutzap Mint Recommendation      | [61](61.md)                            |
 | `10030`       | User emoji list                 | [51](51.md)                            |
 | `10050`       | Relay list to receive DMs       | [51](51.md), [17](17.md)               |
 | `10063`       | User server list                | [Blossom][blossom]                     |
@@ -209,6 +216,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `34235`       | Video Event                     | [71](71.md)                            |
 | `34236`       | Short-form Portrait Video Event | [71](71.md)                            |
 | `34550`       | Community Definition            | [72](72.md)                            |
+| `37375`       | Cashu Wallet Event              | [60](60.md)                            |
 | `39000-9`     | Group metadata events           | [29](29.md)                            |
 
 [NUD: Custom Feeds]: https://wikifreedia.xyz/cip-01/