From ecbf7dd24d35807204b2a7f1ba4dca992e6e3b19 Mon Sep 17 00:00:00 2001 From: toadlyBroodle Date: Sun, 30 Apr 2023 10:47:38 +0900 Subject: [PATCH] revert 57.md changes and add poll_option references --- 57.md | 17 ++++------------- 1 file changed, 4 insertions(+), 13 deletions(-) diff --git a/57.md b/57.md index 8daa3f58..4dffd64d 100644 --- a/57.md +++ b/57.md @@ -37,6 +37,7 @@ In addition, the event MAY include the following tags: - `e` is an optional hex-encoded event id. Clients MUST include this if zapping an event rather than a person. - `a` is an optional NIP-33 event coordinate that allows tipping parameterized replaceable events such as NIP-23 long-form notes. +- `poll_option` is a tag used for voting by [zap poll events](69.md). Example: @@ -49,7 +50,8 @@ Example: ["amount", "21000"], ["lnurl", "lnurl1dp68gurn8ghj7um5v93kketj9ehx2amn9uh8wetvdskkkmn0wahz7mrww4excup0dajx2mrv92x9xp"], ["p", "04c915daefee38317fa734444acee390a8269fe5810b2241e5e6dd343dfbecc9"], - ["e", "9ae37aa68f48645127299e9453eb5d908a0cbb6058ff340d528ed4d37c8994fb"] + ["e", "9ae37aa68f48645127299e9453eb5d908a0cbb6058ff340d528ed4d37c8994fb"], + ["poll_option","0"] ], "pubkey": "97c70a44366a6535c145b333f973ea86dfdc2d7a99da618c40c64705ad98e322", "created_at": 1679673265, @@ -133,6 +135,7 @@ The following should be true of the zap receipt event: - The zap receipt MUST contain a `description` tag which is the JSON-encoded invoice description. - `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 MAY contain a `poll_option` tag used for voting on [zap poll events](69.md). 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. @@ -160,18 +163,6 @@ Example zap receipt: } ``` -* The zap note MUST have a `bolt11` tag containing the description hash bolt11 invoice. - -* The zap note MUST contain a `description` tag which is the invoice description. - -* `SHA256(description)` MUST match the description hash in the bolt11 invoice. - -* The zap note MAY contain a `preimage` 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 note for the legitimacy of the payment. - -* The zap note MAY contain a `poll_option` tag used for voting on [zap poll events](69.md). - -The zap note is not a proof of payment, all it proves is that some nostr user fetched an invoice. The existence of the zap note implies the invoice as paid, but it could be a lie given a rogue implementation. - ### Appendix F: Validating Zap Receipts A client can retrieve `zap receipts` on events and pubkeys using a NIP-01 filter, for example `{"kinds": [9735], "#e": [...]}`. Zaps MUST be validated using the following steps: