add token reserve kind

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

37.md

@@ -1,59 +0,0 @@
-NIP-37
-======
-
-Editable Short Notes
---------------------
-
-`draft` `optional`
-
-This NIP describes a flow for editing `kind:1` notes that is mostly backwards-compatible (as long as clients support [NIP-09](./09.md) properly).
-
-The flow for editing a `kind:1` note consists of creating a new `kind:1` note to be published in its place, then issuing a `kind:5` delete request for the first, in both cases attaching special tags that denote the nature of the operation to clients that want to support a more rich edit flow.
-
-## Example flow
-
-Support `<bob>` publishes
-
-```jsonc
-{
-  "id": "aaaaa",
-  "kind": 1,
-  "pubkey": "<bob>",
-  "content": "ehllo"
-}
-```
-
-And now, for whatever, reason, he wants to edit the note to say "hello", so his client will publish the following two events:
-
-```jsonc
-{
-  "id": "bbbbbb",
-  "kind": 1,
-  "pubkey": "<bob>",
-  "content": "hello",
-  "tags": [
-    ["s", "aaaaaa"] // this indicates the note that is being replaced
-  ]
-}
-
-{
-  "kind": 5,
-  "pubkey": "<bob>",
-  "tags": [
-    ["e", "aaaaaa"], // this indicates the note that will be deleted in all non-upgraded clients
-    ["edit", "bbbbbb"], // this indicates the notes that replaced the one just deleted
-  ]
-}
-```
-
-## Backwards-compatibility
-
-For all non-upgraded clients, this operation will look like a normal delete-and-replace. Replies, likes and everything else sent to node `aaaaaa` will be lost, but the feed will be intact and fine, with no need for any custom handling or  complex replaceability.
-
-## Progressive enhancement
-
-Progressive enhancement may be applied, for example: when a user clicks to open note `bbbbbb` the client might try to query for `{"ids": ["aaaaaa"]}` upon seeing the `s` tag. And vice-versa, upon opening any other note a client might query for `{"#s": ["..."]}` to check if any edit is available. Both operations can enhance the focused note screen, but they don't have to be performed while loading a feed, and they remain strictly optional regardless.
-
-## Full-blown upgrade
-
-More complex clients that want to treat edits as pure edits and note as standalone notes may choose to hide any `kind:1` note that contains an `s` tag as a standalone entity, instead choosing to attach it to its "parent" that was edited. That must be combined with a refusal to _actually_ delete notes whenever the `kind:5` deletion request includes an `edit` tag. Such deletion request would then be only used as hints that an edit was performed, so it can be fetched and the note contents replaced in-place.

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

@@ -12,10 +12,12 @@ The purpose of this NIP is:
 
 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.
+# Event Kinds
+- `kind:37375` contains relevant info for a wallet. Clients **SHOULD** check the current info event when loading the wallet.
+- `kind:7373` wallet's reserved proofs. The proofs **MUST** be nip44-encrypted with the user's private key.
+- `kind:7374` tracks pending quotes from a mint. This event **MAY** be used to keep track of the quote ID and its expiration.
+- `kind:7375` represents the wallet's unspent proofs. The proofs **MUST** be nip44-encrypted with the user's private key.
+- `kind:7376` provides the wallet's transaction history. The history is provided only for informational purposes and is not part of the wallet state.
 
 ## Wallet Event
 ```jsonc
@@ -57,7 +59,7 @@ Any tag, other than the `d` tag, can be [[NIP-44]] encrypted into the `.content`
 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.
+Token events are used to store proofs of a wallet.
 
 There can be multiple `kind:7375` events for the same mint, and multiple proofs inside each `kind:7375` event.
 
@@ -87,6 +89,9 @@ There can be multiple `kind:7375` events for the same mint, and multiple proofs
 ### 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.
 
+### Reserving proofs
+A wallet can reserve proofs by deleting them from a `kind:7375` event and creating a `kind:7373` event. `kind:7373` and `kind:7375` events have the same structure.
+
 ## Spending History Event
 Clients SHOULD publish `kind:7376` events to create a transaction history when their balance changes.
 
@@ -203,3 +208,6 @@ Application developers are encouraged to use local state when possible and only
 
 ## 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.
+
+## Appendix 2: Validating relays
+Clients might want to optionally check that the relays the user chooses to store the proofs respond well to [[NIP-09]] event deletion requests and, periodically, check that the different relays are consistent with the state they report. These checks are left up to particular implementations to decide when and why to do them.

README.md

@@ -142,7 +142,8 @@ 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)                            |
+| `7373`        | Reserved Cashu Wallet Tokens    | [60](60.md)                            |
+| `7374`        | Pending minting quotes          | [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)                            |