From dd0ca43d247bdc5604cf5e82ea1e6ecc66866014 Mon Sep 17 00:00:00 2001 From: Acea Spades Date: Sat, 14 Dec 2024 20:32:49 -0800 Subject: [PATCH] Merchant Delegation Tags --- 15.md | 58 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 56 insertions(+), 2 deletions(-) diff --git a/15.md b/15.md index 80d3243..cec6c4c 100644 --- a/15.md +++ b/15.md @@ -229,8 +229,62 @@ The below JSON goes in `content` of [NIP-04](04.md). } ``` -## Merchant Delegation Tags -(WIP) +## Merchant Delegation + +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. + +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. + +To use Merchant Delegation Tags: + +- Clients MUST treat events with a `merchant-delegation` tag in the following manner: + - Validate the `delegation token` signature + - If `retarget_while<` and/or `retarget_while>` is present in the conditions query string, only perform event re-targeting within the given time window + - If `nip_05_identifier` is present in the conditions query string, only perform re-targeting if the Npub of the event's creator is verifiable as-per the NIP-05 spec + +- Clients SHOULD display a relevant visual indicator that a Stall and/or Product's Checkout process is handled by a Merchant Delegate. + +Merchant Delegation tags are described as follows: + +```json +[ + "merchant-delegation", + , + , + +] +``` + +The **merchant-delegation token** should be a 64-byte Schnorr signature of the sha256 hash of the following string: + +**nostr:delegation::\ + +##### Conditions Query String + +The following fields and operators are supported in the above query string: + +*Fields*: +1. `retarget_while` + - *Operators*: + - `<${TIMESTAMP}` - clients must only redirect event targets for events created ***before*** the specified timestamp + - `>${TIMESTAMP}` - clients must only redirect event targets for events created ***after*** the specified timestamp + +2. `nip_05_identifier` + - *Operators*: + - `<${TIMESTAMP}` - clients must only redirect event targets for events created ***before*** the specified timestamp + - `>${TIMESTAMP}` - clients must only redirect event targets for events created ***after*** the specified timestamp + +In order to create a single condition, you must use a supported field and operator. Multiple conditions can be used in a single query string, including on the same field. Conditions must be combined with `&`. + +For example, the following condition strings are valid: + +- `retarget_while<1675721813&nip_05_identifier=service-bot@my-awesome-store.com` +- `retarget_while>1675721813%&nip_05_identifier=service-bot@my-awesome-store.com` +- `retarget_while>1674777689&created_at<1675721813&&nip_05_identifier=service-bot@my-awesome-store.com` + +*Note: This is closely inspired by the [NIP-26: Delegated Event Signing](https://github.com/nostr-protocol/nips/blob/master/26.md) tag specification. However, the NIP-26 implementation is NOT chosen for this use case. Delegating event signing ability as per NIP-26 would be superfluous because the Merchant Delegate will not possess the ability to decrypt incoming order messages from Customers. ## Customize Marketplace