NIP-XXX: new order event based on BOLT12 payment protocol

[ariard]

This NIP proposal introduces a new event order of kind 32_500 based on the BOLT12 protocol aiming to enhance peer-to-peer marketplaces.

The BOLT12 payment protocol indicates a serie of steps for one or more trading counterparties to enter into a trade agreement (offer, invoice_request, invoice). The new invoice format is TLV-based which enables easy extensibility (e.g adding new payment method like e-cash or issuer-related conditional-payment policy).

The new order event is a superset of a bolt12 and the corresponding NIP01 event field. Introducing a new kind rather than adding the offer as a tag introduces the ability to have order policy enforced by a serie of tags. A default order policy is re-using the "tag" d to enable an offer issuer or order broker to replace a subset of its pending orders.

The "Design" section gives more examples of order routing policy based on yet-to-be-defined in future NIP tags.

While there is some redundancy with NIP-15, the current proposal not only enable the two major types of real-world marketplace OTC and exchange by allowing the Nostr relays/services to act as broker, or marketplace boards. A "stall" can be re-introduced as a set of offers all announced under the same issuer pubkey, and with a tag to announce the brokering relays to listen for future order events. The t tag is not re-used as a scalable and trust-minimized overlay namespace over product/good announcement is far from simple in my understanding.

BOLT12 comes with additional advantages over BOLT11, e.g the Merkle tree construction of the signature invoice format that enables privacy-preserving broker/dealer policy.

There is a WIP implementation against the CivKit node, a Rust based NIP-01 relay software:
civkit/civkit-node#20

Opening this NIP proposal to collect feedback and looking forward on how to standardize and harmonize peer-to-peer marketplace softwares (NIP-15 based and others) across the Bitcoin/Nostr ecosystems.

This being my first NIP proposal, if I’m missing some formatting things about NIPs, or previous discussions about p2p marketplace design in the Nostr space, thanks to let me know.

[mikedilger]

formatting: I wouldn't highlight the data here, just put "kind": 32500

[ariard]

thanks updated by removing the highlighting, now “kind”: 32_500 if this what you were thinking about.

[ariard]

I’m thinking to have the option of allowing bolt11 string there too. There is already about BOLT11 integration (NIP-57) however it does introduces it as a tag, which prevents to have “order policy” based on tag, like this proposal is thinking of.

Addition is motivated by the fact than it will take a while for BOLT12 to become a standard across Lightning wallets.

[fiatjaf]

I am having a hard time understanding how this is supposed to work in practice. My infantile mind would like a concrete example.

[ariard]

I am having a hard time understanding how this is supposed to work in practice. My infantile mind would like a concrete example.

Example 1: over-the-counter market

                              Ralph
                            ---------                 "paperbook" offer
                   order    |       |    order
        Alice ------------->| Relay |-------------------> Bob
          |                 |_______|                      |
          |                                                |
          |                                                |
          |                -----------                     |
          |  invoice       |         |  invoice_request    |
          -----------------| LN Node |----------------------
                           |_________|

• Ralph is a happy NIP01 relay
• Alice wishes to do OTC with people of her social circle about paper books
• Bob is friend-of-friend of Alice and Alice knows his Nostr pubkey
• Alice sends an encrypted NIP04 (or NIP44) trade order event to Bob, that way offer content is not seen by Ralph
• Bob can pursue the payment of Alice's paperbook over Lightning using the offer's blinded_path
• Bob does not learn Alice's Lightning node and payment privacy good

The OTC capability can be boosted once you have encrypted group events (e.g NIP112 proposal) and Alice
can broadcast her sales trade order to all her circle of friends (Bob, Dave, Caroll).

Example 2: public market

• Ralph is a happy NIP01 relay signaling a board market service
• Alice wishes to announce her trade order event of delicious homecooked macaroons to all Ralph's clients
• Alice sends such cleartext trade order event to all Ralph's clients subscribing to tag homecooked macaarons flavor raspberry
• Eva, a Ralph's client is interested by the order
• Eva parses the BOLT12 offer content payload from the Nostr order event
• Eva feed it to her LN wallet to conclude the trade with Alice over Lightning in a privacy-preserving fashion from Ralph
• Ralph will keep re-announceing Alice trade order event until a potential NIP40 "expiration" timestamp if more clients wanna homecooked macaarons

Example 3: public market (order brokering)

• Ralph is a happy NIP01 relay signaling a board market service
• Alice wishes to announce her trade order event of space cakes bakery, however she does not wish to link her Nostr identity to the offer identity
• Alice announce a trade order event to Ralph with some tag allowing pubkey substitution (to be specified) though without tampering the bolt12 content
• Ralph re-announce the event to all its clients, including Caroline
• Caroline discovers the bolt12 offers and she can authenticate the offer with the offer_issuer field (authentication might with Alice's pseudonymous)
• Caroline can feed the bolt12 offer to her LN wallet to conclude the trade with Alice in a privacy-preserving fashion

For the last example of order brokering, Ralph can withhold the blinded_path field from Alice order content and only
reveals it to Caroline in exchange of brokering fee (a more sophisticated market order flow).

The examples can be more precised if needed.

Generally, the BOLT12 format present (at least) 3 clear advantages to build marketplace:

• signature covering a merkelized TLV payload, good for payer / payee privacy to enable selective invoice fields reveal
• a disentangling of Lightning pubkey from the format, offer_issuer is a flexible field it can be a per-trade pubkey
• an interactive protocol flow (offer - invoice_request - invoice) between payer and payee if they need to negotiate a conditional payment parameters (e.g DLC oracle points)

This NIP proposal only introduces the kind 32_500 to say "bolt12 string" inside a Nostr event and it’s a simple primitive on top of which everyone can build and experiment with different market flows, I think.

[ariard]

See comment on #662, I’m fine to withdraw this proposal in favor of the other proposal, if we can converge on the semantic “tag-vs-content" and have the content field being indifferently a BOLT11 / BOLT12 / Markdown or LNURL. I think it would benefit to have a single trade order event standard, however it maybe too early for that and have more market place experimentations.

[ariard]

Okay I’ll maintain this proposal open as NIP99 doesn’t address the technical concerns I raised on #662, though from my understanding of the design it doesn’t aim to be a generalized NIP for marketplace, and more something for ad hoc sales for ease and simplicity.

[fiatjaf]

Sorry for taking too long. I read your answer now, and I'm not sure I get it. I think it would work fine without an extra kind. You could just send a nip04 or whatnot with the bolt12 inside it, no?

It's also ok to use a new kind, I just don't see the need, but I'm probably missing something.

[ariard]

You could just send a nip04 or whatnot with the bolt12 inside it, no?

Thanks for the read, to be honest I'm still experimenting with "order" implementation in my nostr relay. I think I'll propose an updated version latter. Note bolt12 offer isn't still worked on on LDK so pending on this so it was a bit too early to propose this NIP. Happy to let it open to collect more feedback.