thebullishbitcoiner on Nostr: Bullish on #Nostr ecommerce and the improvements proposed in this post. Shoutout to ...

Bullish on #Nostr ecommerce and the improvements proposed in this post.

Shoutout to the caffeinated officers:
Caffeinated Tech Officer (CTO): aceaspades (npub1xzr…0qap)
Caffeinated Operating Officer (COO): ericfj (npub10xv…g437)

Keep up the great work. Looking forward to seeing what you do at ConduitBTC (npub1nkf…2svu) ConduitCoffee (npub18pl…4wh4) ☕️

quoting note1vr5…fev2

Written by **Acea Spades**, Caffeinated Tech Officer @ Conduit BTC https://primal.net/AceaSpades
aceaspades (npub1xzr…0qap)

Editing and feedback by **Eric FJ**, Caffeinated Operating Officer @ Conduit BTC https://primal.net/EricFJ ericfj (npub10xv…g437)

NIP-15 enables a new architectural paradigm in e-commerce. Every piece of data is distributed across a network of relays, adding resiliency and redundancy. Every piece of sensitive data is encrypted in-transit and at-rest, accessible only to Customer and Merchant. Communications and e-commerce activities use an inbox/outbox model across relays. This gives both the Customer and Merchant freedom to choose the digital environment for their shared activities.

This also introduces a host of fun and exciting new issues, such as stale data, relay mismatches, unreachable Customers/Merchants, disappearing messages, and this pesky direct message checkout system.

Platforms like Wordpress, Shopify, and Etsy have democratized the space of e-commerce, made it easy to onboard as a Merchant, and smooth to transact as a Customer. But these systems require centralized servers, siloed data stores, unclear third-party visibility, and possess no protocol-level mechanism for connection with a larger network.

NIP-15: Nostr Marketplaces enables Merchants and Customers to transact directly using the Nostr protocol. It enables a resilient, decentralized presence of Products, and a way to purchase them. It adds privacy and encryption to all correspondence, automatically. Both parties gain the amazing features of Nostr, out-of-the-box. However, the current implementation of the protocol has much to be desired.

Our team at Conduit BTC is focusing our efforts on resolving the shortcomings of the current system. Our mission is to push Nostr E-Commerce forward and help it evolve into a top-quality online retail experience for all.

But to get there, we've got to do some housekeeping.

Let's start with the checkout problem...

-----------

# Checkout: A Problem

The current state of Nostr E-Commerce is, to put it lightly, lacking in real-world viability.

If I want to purchase a Product, my Nostr client sends a direct message to the Merchant. When they see the message appear, the Merchant generates an invoice, sends it back, waits for payment, then performs the fulfillment steps that their unique businesses requires.

While that might look good on paper, there's some unfortunate implications for both the Merchant and Customer experience. Let's explore some negatives.

NIP-15 uses direct messages to exchange Checkout events between Customer and Merchant. Any Nostr client that doesn't handle NIP-15 events will display the order in good ol' JSON:

```
{
"id": "ord_cust_1234567890abcdef",
"type": 0,
"name": "Jane Smith",
"address": "123 Mountain View Dr, Boulder, CO 80302",
"message": "Looking forward to using these boots on my upcoming hike!",
"contact": {
"nostr": "7f3b5f21c9880ce33043478436487435878934578934589345893458934",
"phone": "+1 303-555-0123",
"email": "jane.smith@email.com"
},
"items": [
{
"product_id": "boot_model_789xyz",
"quantity": 1
}
],
"shipping_id": "zone_us_rocky_mountain"
}
```

Imagine parsing through that every time you get an order.

Most clients won't separate these ugly JSON orders from human-speak messages. These orders will be side-by-side with all other conversations, spamming your inbox.

Since the order message needs the Merchant to receive it, generate an invoice by-hand, then send the invoice back, the Bitcoin-based price might fluctuate. This could mean lowering the transaction value for the Merchant or increasing expected cost for the Customer. There's also a higher chance of invoice expiration for Merchants with a smaller risk window against Bitcoin's volatile price.

While Lightning payment processors (Strike, BTCPay Server, etc) send webhooks when funds are received, typical commerce systems don't have a way to communicate with Nostr relays. Product details on-relay aren't auto-updated with current stock, leading Customers placing orders for out-of-stock items.

And, the Merchant has to manually send shipment details in a direct message to the Customer; another manual step in the checkout flow.

Long story short, it's simply not functional for a Merchant to complete the entire series of checkout steps as-described by NIP-15, at-scale for real-world e-commerce, by hand.

To summarize the challenges we must overcome:

- **Merchant experience friction**: Manual steps require time per order multiplied by their unique business operation's requirements.
- **Spammed inbox**: Non-relevant JSON messages fill the Merchant's inbox.
- **Fulfillment delays**: Checkout flow is delayed until several manual steps are completed by both parties.
- **Price fluctuations**: Time between order placed and invoice paid leads to possible price fluctuation, impacting Merchant or Customer expectations
- **Invoice expirations**: Time between invoice generation and payment increases chance of expiration
- **In-Stock Mismatches**: Relays may have incorrect inventory stock, leading to failed orders and customer inconvenience.

With these points considered, a "real-world" checkout process requires automation. Coordination between inventory, payments, fulfillment, and Customer communication, should take place by an automatic process.

To that effect, we at Conduit BTC propose a solution. We call it the *Nostr Commerce Coordinator*.

# The Case for Coordinators

An NCC (Nostr Commerce Coordinator) is a server-based Nostr bot that:
- Is under control of, and represents, the Merchant on Nostr
- Subscribes to a relay pool
- Posts and queries NIP-15 events
- Coordinates the NIP-15 Checkout process on behalf of a Merchant:
- *Inventory Management:* verify, increment, and decrement product stock, create and update Stalls and Products on relays via signed events
- *Payment Processing:* generate Lightning invoices, send invoice to customer, respond to payment events via webhook
- *Fulfillment Services:* create shipments, notify fulfillment partners
Handles Checkout-related communications with the Customer
Notifies the Merchant when certain things occur
Collect sales-relates metrics for Merchant visibility

To summarize the benefits of an NCC:
- Automated, frictionless checkout flow
- Direct integration with Merchant's existing e-commerce stack: inventory management, payment processing, and shipping service
- Separation of Checkout-related direct messages (containing ugly JSON) from actual human readable direct messages
- General separation-of-concerns between Merchant's social graph and e-commerce activities
- Ability to implement additional commerce features, such as metrics collection, financial statements, subscriptions, and much more yet-to-be explored possibilities

# Where do I put my private key?

There's one violation of Nostr pleb sensibility that, at first glance, might seem required for the NCC equation to work: putting a Merchant account's private key in the hands of a cloud-based server.

Obviously, we don't want our private keys stored on a cloud-based server.

To overcome this, there's the option to use an nsec Bunker (with supported clients). Using an Nsec bunker would more-safely store our private keys, granting both sign-and-decrypt access to the server. It's a great solution.

However, we'll explain a couple of reasons why using the Merchant account with an Nsec bunker for checkout fulfillment may not be right for most use cases:

- All checkout messages would spam the Merchant account with non-social direct messages. For popular Merchants, this will increase friction for both fulfilling orders and engaging with Customers. This can be resolved by clients enabling NIP-15 message sorting, but it's likely that most clients will still display an inbox filled with socially-irrelevant messages.
- Both business and social activities would be strongly coupled. Stalls, Products, and Orders are managed by the same keypair that the Merchant's social graph is tied to. A leaked key has the potential to bring the entire business operation to a halt, social presence included.

There is, however, an alternative to using the Merchant account for checkout resolution. And, it works great with nsecBunkers, too.

We're now going to explore the use of a *utility keypair*, a Nostr account generated specifically for assisting the primary account holder in any number of tasks. We'll explore utility keypairs in greater detail through a paradigm we call **Merchant Delegation**.

# Merchant Delegation

In the Merchant Delegation paradigm, a different Nostr keypair 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 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.

When coupled with an NCC, the Merchant Delegation paradigm really begins to shine.

For the mindful Merchant who doesn't want to use their main account for checkout activities, Merchant Delegation is the answer. For wary Merchants who want to keep their private keys off-cloud, an NCC can use a utility keypair and act on behalf of the Merchant through Merchant Delegation.

For the rest of this article, we will refer to this utility keypair as the *NCC Account*, while calling the Merchant's primary Nostr account the *Merchant Root Account*.

When an order is placed, the NCC automatically fetches the incoming message, decrypts it, parses the order, generates an invoice, and sends it to the Customer. A Customer can place an order, then receive an invoice in seconds.

Once paid, the payment processor's webhook notifies the NCC. The NCC decrements stock in the inventory management system, posts a Product Update event across the relay pool, then forwards the paid order to the fulfillment service.

NCCs can optionally keep a copy of every event they've handled. This enables local persistence and immediate access to important events without requiring re-retrieval from relays. A locally-kept reconstruction of the entire e-commerce activity graph. This can be useful for keeping order history, assisting Customer support, generating sales reports and financial records, etc.

All the while, 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.

In this way, the NCC becomes the bridge between the Nostr protocol and the Merchant's e-commerce systems. The Merchant freed from manual checkout management, and gain a piece of extendable software that can meet many of their needs as a Nostr-based business.

# NIP-15 Amendment - Merchant Delegate Tag Spec

In order to separate the social graph from checkout activities, an amendment to the NIP-15 spec has been proposed: https://github.com/nostr-protocol/nips/pull/1648.

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::\`

To keep this article concise, we have omitted most of the proposal details. **The above may be deprecated.** See the [link to the PR](https://github.com/nostr-protocol/nips/pull/1648) to read the complete and up-to-date spec.

# Merchant Delegate NCC Tags In-Action

On a NIP-15 enabled clients that adhere to this spec, the experience would be as follows:

---

**UX:** A Product for sale, in a Stall, by Merchant (Root Account)

**Nostr:** Kind 30017 (Set Stall) and 30018 (Set Product) events signed by the NCC Account, with a "merchant-delegation" tag pointing to the Merchant Root Account.

---

**UX:** Select this Product for purchase, fill in the appropriate details on a Checkout Form, then click "Buy Now".

**Nostr:** Client creates a direct message addressed to the NCC Account. NCC server generates a Lightning invoice for this order, and sends it back immediately as a direct message addressed to the Customer

---

**UX:** Customer receives a Lightning Invoice from NCC Account, then pays the invoice.

**Lightning + Nostr:** NCC receives a webhook message from its Payment Processor, indicating payment was received. NCC sends a direct message to the Customer indicating Order Confirmation. Any time there are shipping updates from the Shipping Service, NCC will send additional direct messages to the Customer; in the case of digital goods, the order will be fulfilled as-appropriate for the business use case.

---

**UX:** From the same Product's details page, the Customer will see the Product is sold by the Merchant Root Account, with a visual indicator stating the Checkout process is managed by NCC. Customer clicks Follow. Customer zaps the Merchant 100 sats. Customer sends a direct message to the Merchant to thank them for the excellent service.

**Nostr:** Product and Stall are both created by the NCC Account, Follow, Zap, and Direct Message events all target the Merchant Root Account.

---

# Additional Features

## Private Key Watchman

As an additional feature of an NCC, we get "for free" a server can match on-relay events with locally-stored events to detect unauthorized events signed with its private key. The underlying issue corresponding to the leak could then be investigated. A rare instance, but a powerful tool for account safety.

If an unauthorized event were discovered, the NCC can respond in a number of ways, chosen by the Merchant, which may include:

- **"Purge and replace"**: Send NIP-09 Event Deletion Requests to every relay in the pool for every existing Stall and Product. Generate a new keypair, recreate the Stalls and Products, then propagate them to all relays. Notify the Merchant that a purge took place.

- **"Purge, then notify"**: Perform a full purge, then notify Merchant. Useful in scenarios where the running server may have become compromised.

- **"Notify, then purge"**: Notify the Merchant. Unless cancelled within a set amount of time, perform a purge.

- **"Just notify"**: Notify the Merchant that one or more events were signed with the NCC secret key outside of the NCC server. Useful if the Merchant chooses to use the NCC's utility keypair in other clients.

Following a purge, the Merchant (or NCC automatically) would then generate a new keypair / NCC Account, then republish all Stalls and Products. Commerce would continue uninterrupted with an uncompromised Merchant social graph. Through Merchant Delegate tags, clients would still properly route Customer interactions through to the proper systems.

*There's a lot of conversation happening at Conduit BTC about this particular feature, and how we can "watch the watchman" by providing additional layers of security to the server itself. This is an ongoing discussion, and we'd love for you to be a part of it. Visit the Discussions tab on on [C3: The Conduit Commerce Coordinator Repo](https://github.com/Conduit-BTC/conduit-commerce-coordinator
), and let's chat about it.*

## Stall and Product Management

Stall and Product Management could be handled from a web UI served by the NCC, instead of solely within the external Inventory Management service.

*Note: if the "leaked key protection" guard was in place, it would actually be necessary to either use the web UI to manage products, or temporarily disable the guard, to prevent NCC from becoming angry and initiating (or threatening) a purge. Yikes.*

## Subscriptions

In the future, the NIP-15 spec can be updated to include a Subscription event type, indicating that the Customer would like to repeat the same order one or more times.

The NCC can automatically send the subscribing Customer their next order's payment notice. Accepting the notice (via direct message response, following a URL, etc.) generates an invoice on-the-spot.

## Direct Messaging

A direct message client could be placed into the web UI, for passing Checkout-related messages to the Customer, instead of using the Merchant Root account and splitting order-specific conversation into two threads.

# Drawbacks

If the NCC were taken offline, then Customer's order messages would accumulate without automatic resolution.

However, like an escalator conveniently becoming stairs when not functioning properly, Customer orders continue to accumulate on-relay, awaiting the deployment of another NCC, or manual resolution. As long as the NCC Account's private key is safely stored away, it can be loaded into another NCC or Nostr client at any time.

A *serious* drawback to the current NIP-15 spec is using NIP-04 Encrypted Direct Messages for checkout events. Luckily, we've already opened a PR to improve that: https://github.com/amunrarara/nips/blob/patch-1/15.md

# Conclusion

Without a system capable of automating the process between a Customer's intent to purchase and a Merchant's acceptance, e-commerce on Nostr will not grow beyond small sales plagued with high-friction manual checkout steps.

This proposal contains the groundwork for a new type of Nostr bot. A Nostr bot whose core function is handling NIP-15 checkout events automatically on behalf of a Merchant.

We've included many implementation possibilities, which the community may explore, innovate, and perfect.

To recap, concepts introduced in this article were:
- Nostr Commerce Coordinators
- Utility keypair accounts
- Merchant Delegation

This is an ongoing conversation, and we'd love to have your feedback and participation in making Nostr E-Commerce an incredible experience for all.

We hope that this new software and NIP proposal will improve the experience for all of us on Nostr. Join us on this adventure into a new frontier in decentralized online e-commerce.

---

Conduit BTC has begun development on the first Nostr Commerce Coordinator, which we call **C3: The Conduit Commerce Coordinator.** This is, of course, an open-source project - as everything we do will be.

Follow, star, share, and join the discussion on Github: https://github.com/Conduit-BTC/conduit-commerce-coordinator