Merchant Delegation Tags

15.md

@@ -229,8 +229,62 @@ The below JSON goes in `content` of [NIP-04](04.md).
 }
 ```
 
-## Merchant Delegation Tags
+## Merchant Delegation
-(WIP)
+
+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",
+  <pubkey of the delegator>,
+  <conditions query string>,
+  <delegation token: 64-byte Schnorr signature of the sha256 hash of the delegation string>
+]
+```
+
+The **merchant-delegation token** should be a 64-byte Schnorr signature of the sha256 hash of the following string:
+
+**nostr:delegation:<pubkey of publisher (delegatee)>:\<conditions query string>
+
+##### 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