From e6a3683d204e696672330d3b25bd75513ab7614b Mon Sep 17 00:00:00 2001 From: Acea Spades Date: Sat, 14 Dec 2024 20:41:44 -0800 Subject: [PATCH] Update 15.md --- 15.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/15.md b/15.md index cec6c4c..f9fa48d 100644 --- a/15.md +++ b/15.md @@ -233,7 +233,11 @@ The below JSON goes in `content` of [NIP-04](04.md). In the Merchant Delegation paradigm, a different Nostr account effectively controls all commerce-related events on behalf of the Merchant. The delegated account creates every Stall and Product, receives all Checkout events, and handles checkout-related communication with the Customer. -The Merchant signs a Merchant Delegate Token, which is placed in a tag on every event signed by the delegate account. Clients parse the tag, verify the signature is valid, and cause non-checkout events (ie. follows, zaps, direct messages, etc.) to target the Delegator automatically. +Clients implementing Merchant Delegation automatically re-target non-checkout events to the Merchant Root Account (aka Delegator). + +By using Merchant Delegation, the Merchant's Root Account remains free to engage solely in social graph activities (ie. posting short-form / long-form content creation and engagement, non-checkout communications with Customers, etc), without the checkout-related events spamming their inbox. + +The Merchant signs a Merchant Delegate Token, which is placed in a tag on every event signed by the delegate account. Clients parse the tag, verify the signature is valid, and cause non-checkout events (ie. follows, zaps, direct messages, etc.) to target the Merchant Root Account (aka Delegator) automatically. As an extra layer of validation, a NIP-05 identifier may be included. When an identifier is present, clients will verify its validity, and reject delegation if the Npub is not properly identified. This provides the ability to invalidate the delegation, if need be.