Merge branch 'master' into vending-machine

1 files changed, 9 insertions, 5 deletions

diff --git a/57.md b/57.md
index 438a0f8..ace4a03 100644
--- a/57.md
+++ b/57.md
@@ -126,7 +126,7 @@ When receiving a payment, the following steps are executed:
 
 The following should be true of the `zap receipt` event:
 
-- The content SHOULD be empty.
+- The `content` SHOULD be empty.
 - The `created_at` date SHOULD be set to the invoice `paid_at` date for idempotency.
 - `tags` MUST include the `p` tag AND optional `e` tag from the `zap request`.
 - The `zap receipt` MUST have a `bolt11` tag containing the description hash bolt11 invoice.
@@ -166,18 +166,22 @@ A client can retrieve `zap receipt`s on events and pubkeys using a NIP-01 filter
 - The `invoiceAmount` contained in the `bolt11` tag of the `zap receipt` MUST equal the `amount` tag of the `zap request` (if present).
 - The `lnurl` tag of the `zap request` (if present) SHOULD equal the recipient's `lnurl`.
 
-### Appendix G: `zap` tag on zapped event
+### Appendix G: `zap` tag on other events
 
-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`.
+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`).
 
-```json
+```js
 {
     "tags": [
-        [ "zap", "pablo@f7z.io", "lud16" ]
+        [ "zap", "82341f882b6eabcd2ba7f1ef90aad961cf074af15b9ef44a09f9d2a8fbfbe6a2", "wss://nostr.oxtr.dev", "1" ],  // 25%
+        [ "zap", "fa984bd7dbb282f07e16e7ae87b26a2a7b9b90b7246a44771f0cf5ae58018f52", "wss://nostr.wine/",    "1" ],  // 25%
+        [ "zap", "460c25e682fda7832b52d1f22d3d22b3176d972f60dcdc3212ed8c92ef85065c", "wss://nos.lol/",       "2" ]   // 50%
     ]
 }
 ```
 
+Clients MAY display the zap split configuration in the note.
+
 ## Future Work
 
 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.