correct nutzap kind

This commit is contained in:
Pablo Fernandez 2024-08-07 11:22:00 +01:00
parent 8ae9b9b744
commit ea8ce6589e

16
61.md
View File

@ -9,10 +9,10 @@ Alice wants to nutzap 1 sat to Bob because of an event `event-id-1` she liked.
## Alice nutzaps Bob ## Alice nutzaps Bob
1. Alice fetches event `kind:10019` from Bob to see the mints Bob trusts. 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`. 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:7337` event to the relays Bob indicated with the proofs she minted. 3. She publishes a `kind:9321` event to the relays Bob indicated with the proofs she minted.
## Bob receives the nutzap ## Bob receives the nutzap
1. At some point, Bob's client fetches `kind:7337` events p-tagging him from his relays. 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. 2. Bob's client swaps the token into his wallet.
# Nutzap informational event # Nutzap informational event
@ -36,13 +36,13 @@ Alice wants to nutzap 1 sat to Bob because of an event `event-id-1` she liked.
* `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. * `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 ## Nutzap event
Event `kind:7337` 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. 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). Clients MUST prefix the pubkey they p2pk-lock with `"02"` (for nostr<>cashu pubkey compatibility).
```jsonc ```jsonc
{ {
kind: 7337, kind: 9321,
content: "[{\"amount\":1,\"C\":\"02277c66191736eb72fce9d975d08e3191f8f96afb73ab1eec37e4465683066d3f\",\"id\":\"000a93d6f8a1d2c4\",\"secret\":\"[\\\"P2PK\\\",{\\\"nonce\\\":\\\"b00bdd0467b0090a25bdf2d2f0d45ac4e355c482c1418350f273a04fedaaee83\\\",\\\"data\\\":\\\"02eaee8939e3565e48cc62967e2fde9d8e2a4b3ec0081f29eceff5c64ef10ac1ed\\\"}]\"}]", content: "[{\"amount\":1,\"C\":\"02277c66191736eb72fce9d975d08e3191f8f96afb73ab1eec37e4465683066d3f\",\"id\":\"000a93d6f8a1d2c4\",\"secret\":\"[\\\"P2PK\\\",{\\\"nonce\\\":\\\"b00bdd0467b0090a25bdf2d2f0d45ac4e355c482c1418350f273a04fedaaee83\\\",\\\"data\\\":\\\"02eaee8939e3565e48cc62967e2fde9d8e2a4b3ec0081f29eceff5c64ef10ac1ed\\\"}]\"}]",
pubkey: "sender-pubkey", pubkey: "sender-pubkey",
tags: [ tags: [
@ -79,14 +79,14 @@ Clients should REQ for nut zaps:
Clients MIGHT choose to use some kind of filtering (e.g. WoT) to ignore spam. Clients MIGHT choose to use some kind of filtering (e.g. WoT) to ignore spam.
`{ "kinds": [7337], "#p": "my-pubkey", "#u": [ "<mint-1>", "<mint-2>"], "since": <latest-created_at-of-kind-7376> }`. `{ "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. 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 ## 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. 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:7337` events can be tagged in the same `kind:7376` event. Multiple `kind:9321` events can be tagged in the same `kind:7376` event.
```jsonc ```jsonc
{ {
@ -98,8 +98,8 @@ Multiple `kind:7337` events can be tagged in the same `kind:7376` event.
]), ]),
"tags": [ "tags": [
[ "a", "37375:<pubkey>:my-wallet" ], // an optional wallet tag [ "a", "37375:<pubkey>:my-wallet" ], // an optional wallet tag
[ "e", "<7337-event-id>", "relay-hint", "redeemed" ], // nutzap event that has been redeemed [ "e", "<9321-event-id>", "relay-hint", "redeemed" ], // nutzap event that has been redeemed
[ "p", "sender-pubkey" ] // pubkey of the author of the 7337 event (nutzap sender) [ "p", "sender-pubkey" ] // pubkey of the author of the 9321 event (nutzap sender)
] ]
} }
``` ```