revert 57.md changes and add poll_option references

This commit is contained in:
toadlyBroodle 2023-04-30 10:47:38 +09:00
parent 948c9eb7f2
commit ecbf7dd24d

17
57.md
View File

@ -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: