Add Order note based on BOLT12 payment protocol

XXX.md

@@ -0,0 +1,92 @@
+NIP-XXX
+=======
+
+`draft` `optional` `author:ariard`
+
+Order
+-----
+
+This NIP defines a new event type to communicate trade orders between Nostr relays and clients.
+
+A new parameterized replaceable event `order` is introduced `32500`. This event content field is a Lightning [BOLT12](https://bolt12.org/bolt12.html) string.
+
+## Motivation
+
+This proposal aims to enable peer-to-peer markets over the Nostr network, where clients can select
+market places or trade counterparties with high-level of flexibility, efficiency and privacy.
+
+Two types of peer-to-peer markets can be build from an order event:
+- over-the-counter markets
+- exchanges
+
+Over-the-counter markets can be defined where a dealer is selling products for the account of its
+clients to a set of market-makers, where they have commitments to the product. This can be a Nostr
+encrypted or public group events, where the members are selected according to the dealer's policy.
+
+Exchanges markets can be defined as a publication space where the makers orders are executed against
+takers one by the intermediary of a brokering service. This service can be run on top of a Nostr
+relay, where the makers and takers are Nostr clients.
+
+The technical difference between OTC and exchanges lays in the lack of financial interest of
+the intermediary in the trade order, and only charges a fee for the publication service. While this
+distinction comes with trade-off in term of security model (e.g chain notarization of all the exchange
+trades with [NIP03](https://github.com/nostr-protocol/nips/blob/master/03.md)), in practice the differences
+are expected to be blurred and function of the goods/products quantity.
+
+## Design 
+
+The separation between the offer field related to the trade and the event fields related to the processing
+of the event enable to introduce orders types based on Nostr tags e.g:
+- buy/sell limit order where the offer is not more valid based on a market price indicated in a tag
+- stop order where the offer becomes valid when a market price is reached or passed
+- time-sensitive order where the offer becomes valid when a chain height is reached
+
+Those orders types can be defined in future NIPs and enforced by the relay at order routing.
+
+Merkle construction of the BOLT12 invoice signatures allow selective reveal of the offer fields and therefore
+enable brokering service where a Nostr relay can announce an order to its clients, without revealing the issuer
+pubkey or withholding some fields related to the order execution (e.g the `blinded_path`).
+
+The dissociation of the event signature from the offer signature enable to transit the offer across "market
+zones" (e.g from a exchange A to an exchange B) without breaking the validity of the offer signature itself.
+The old order can be recycled as a new ones with corresponding tags to adapt to the new market zone policy.
+
+## Specification
+
+Order has the following format on the wire:
+
+```json
+{
+  "id": 32-bytes lowercase hex-encoded sha256 of the serialized event data,
+  "pubkey": 32-bytes lowercase hex-encoded public key of the event creator,
+  "created_at": unix timestamp in seconds,
+  "kind": 32_500,
+  "tags": [
+    ["d", "optional value"],
+  ],
+  "content": bolt12 string,
+  "sig": 64-bytes hex of the signature of the sha256 hash of the serialized event data, which is the same as the "id" field
+}
+```
+
+An `order` note creator note:
+  - MUST set the `kind` field to `32_500`
+  - MUST set the event `content` field to a valid BOLT12 string
+
+An `order` receiving node:
+  - MUST reject event of kind `32_500` if the content is not a valid BOLT12 string
+  - MAY substitute the `pubkey` field by its own pubkey and re-sign the event
+
+## Security
+
+TODO: both relay/client-sides
+
+## Backward compatibility
+ 
+BOLT12-enabled Lightning wallets can read the content of order events and verify the authenticity of the payment or
+trade information, without substantial change in the parsing or validation logic of the payment module. A Nostr client
+is just responsible to transfer a bolt12 string to the payment module.
+
+## Acknowledgements
+
+The Lightning protocol development community for the BOLT12 payment protocol.