diff options
| author | Jon Staab <jstaab@protonmail.com> | 2023-07-31 08:26:15 -0700 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2023-07-31 08:26:15 -0700 |
| commit | 5d63b1570c490007252b10e757f7f68ef1f4b717 (patch) | |
| tree | fdc3c40ea90042c1b16b62d4ecc841bd1b671e70 | |
| parent | c2907f836db6eac805b20b6736809dc4a2186b2d (diff) | |
| parent | 4d0929b278cfc748f30be48c549cfc87ef429202 (diff) | |
Merge pull request #552 from vitorpamplona/zap-plits
Adds Zap splits to NIP-57
| -rw-r--r-- | 57.md | 12 |
1 files changed, 8 insertions, 4 deletions
| @@ -166,18 +166,22 @@ A client can retrieve `zap receipt`s on events and pubkeys using a NIP-01 filter | |||
| 166 | - The `invoiceAmount` contained in the `bolt11` tag of the `zap receipt` MUST equal the `amount` tag of the `zap request` (if present). | 166 | - The `invoiceAmount` contained in the `bolt11` tag of the `zap receipt` MUST equal the `amount` tag of the `zap request` (if present). |
| 167 | - The `lnurl` tag of the `zap request` (if present) SHOULD equal the recipient's `lnurl`. | 167 | - The `lnurl` tag of the `zap request` (if present) SHOULD equal the recipient's `lnurl`. |
| 168 | 168 | ||
| 169 | ### Appendix G: `zap` tag on zapped event | 169 | ### Appendix G: `zap` tag on other events |
| 170 | 170 | ||
| 171 | When an event includes a `zap` tag, clients SHOULD calculate the lnurl pay request based on its value instead of the profile's field. An optional third argument on the tag specifies the type of value, either `lud06` or `lud16`. | 171 | When an event includes one or more `zap` tags, clients wishing to zap it SHOULD calculate the lnurl pay request based on the tags value instead of the event author's profile field. The tag's second argument is the `hex` string of the receiver's pub key and the third argument is the relay to download the receiver's metadata (Kind-0). An optional fourth parameter specifies the weight (a generalization of a percentage) assigned to the respective receiver. Clients should parse all weights, calculate a sum, and then a percentage to each receiver. If weights are not present, CLIENTS should equally divide the zap amount to all receivers. If weights are only partially present, receivers without a weight should not be zapped (`weight = 0`). |
| 172 | 172 | ||
| 173 | ```json | 173 | ```js |
| 174 | { | 174 | { |
| 175 | "tags": [ | 175 | "tags": [ |
| 176 | [ "zap", "pablo@f7z.io", "lud16" ] | 176 | [ "zap", "82341f882b6eabcd2ba7f1ef90aad961cf074af15b9ef44a09f9d2a8fbfbe6a2", "wss://nostr.oxtr.dev", "1" ], // 25% |
| 177 | [ "zap", "fa984bd7dbb282f07e16e7ae87b26a2a7b9b90b7246a44771f0cf5ae58018f52", "wss://nostr.wine/", "1" ], // 25% | ||
| 178 | [ "zap", "460c25e682fda7832b52d1f22d3d22b3176d972f60dcdc3212ed8c92ef85065c", "wss://nos.lol/", "2" ] // 50% | ||
| 177 | ] | 179 | ] |
| 178 | } | 180 | } |
| 179 | ``` | 181 | ``` |
| 180 | 182 | ||
| 183 | Clients MAY display the zap split configuration in the note. | ||
| 184 | |||
| 181 | ## Future Work | 185 | ## Future Work |
| 182 | 186 | ||
| 183 | Zaps can be extended to be more private by encrypting `zap request` notes to the target user, but for simplicity it has been left out of this initial draft. | 187 | Zaps can be extended to be more private by encrypting `zap request` notes to the target user, but for simplicity it has been left out of this initial draft. |