This document clarifies the technical model and provides a concrete prompt you can use to create an interoperable, self-hosted shop.

---

The 2.5 Levels of Online Commerce#

Level 1 — Type of Commerce Space#

This level defines the structural model of commerce.

• Marketplaces
  Examples: Amazon, eBay, Reverb
  Shared discovery, shared infrastructure, shared rules.

• Web Shops
  Either:

  • A hosted CRM / commerce solution, or
  • A lightweight commerce layer embedded into an existing website.

---

Level 2 — Operator Model (the “Matrix” Layer)#

This level defines how the shop operates legally and operationally.

A. Law-Compliant / Circular Economy Commerce

Examples include farm-to-table sales, farmers markets, and local P2P trade.

The underlying assumption is that small-scale, peer-to-peer commerce is legal in most jurisdictions and forms the foundation of innovation and company creation.

As long as:

• Products are legal within the operator’s jurisdiction
• Customers are legally permitted to purchase them
• The platform is framed as P2P commerce

Operations should remain viable. This model does, however, require active listing oversight through whitelisting or moderation.

B. Non-Compliant Commerce

This applies when products fall outside the existing legal framework.

This operator model requires two additional considerations from day one:

1. Hosted environment and infrastructure
   Decisions around hosting, connectivity, and runtime environment (e.g. Nsite-style deployments).

2. Full operational security (OPSEC)
   Secure communications with customers, careful handling of shipping data, and disciplined operational practices from the outset.

---

What Is the Focus Here?#

It is already possible to clone or run existing projects such as Shopstr or Plebeian and operate a marketplace-style platform, depending on legal posture and technical capability.

That problem space is largely solved.

What makes more sense in 2026 is enabling small, independent shops that:

• Are interoperable with existing marketplaces for discovery
• Preserve decentralization and self-custody
• Do not require a traditional backend server

The goal is to provide a prompt that allows a user, for a small fee, to generate a complete project they can deploy and own.

---

Why Document a Prompt?#

Traditional CMS-based shops are centered around account creation and backend servers. Guest checkout exists, but it is rarely the primary design assumption.

Designing a shop without a backend server requires a clear, step-by-step checkout and order flow. Proper documentation of this process is essential to creating a simple, functional commerce experience.

---

Prompt #1 — Basic NIP-99 Shop

Build a Nostr shop using the NIP-99 specification.

• Use the provided npub as the shop identity.
• Create a simple client-side cache for products sourced from this npub.
• Avoid server-side state where possible.

---

Global Requirements#

• Implement a currency selection mechanism that applies to the entire shop.

• The currency selector must be accessible from both the header and footer.

• Supported display currencies:

  • Bitcoin (BTC)
  • Satoshis
  • Fiat (USD)

• Use a minimal, basic visual design.

• Implement at least three pages with the functionality described below.

---

Page 1 — Product Overview#

Data Source#

• Fetch products from kind 30402 published by the shop npub.

Layout#

• Left (1/5 width): Filters

  • Inventory: All items
  • Stock status: In stock
  • Default state: All items selected

• Right (4/5 width): Product Grid

  • Product title
  • Short description
  • Price (based on globally selected currency)

Routing#

• Each product must have a unique URL ending with its note ID.

---

Page 2 — Individual Product Page#

Data Loading#

• Extract the note ID from the URL.
• Fetch and render the corresponding product.

Functionality#

• Image slider for product images
• Product title
• Full description
• “Add to cart” button

Cart Behavior#

• Store the following in local storage:
  • Product note ID
  • Quantity

---

Page 3 — Shopping Cart and Checkout Flow#

Empty Cart State#

• If local storage contains no products:
  • Display a message indicating the cart is empty
  • Provide a link back to the product overview

---

Checkout Flow#

Step 1 — Cart Overview

• Display selected products
• Allow:
  • Quantity updates
  • Product removal
• Button: Continue to shipping details

---

Step 2 — Shipping Details Form

Collect the following fields:

• First name
• Last name
• Company (optional)
• Street address
• City
• Postal code
• State
• Country
• Email address

---

Step 3 — Order Review and Confirmation

Display:

• Shipping details
• Cart contents
• Final price in:
  • Bitcoin
  • USD

Order ID

• Generate a random 10-digit numeric order ID

Confirmation Options

• Button 1: Confirm order using an ephemeral key
• Button 2: Confirm order using a browser extension

Order Submission

• Send the following via NIP-17 private DM to the shop npub:
  • Order ID
  • Product list
  • Shipping information

---

Step 4 — Payment

• Generate a Lightning invoice for the final order amount
• Use the kind 0 LUD-16 address associated with the shop npub
• Include the order ID as the invoice memo or description

---

Step 5 — Payment Confirmation

• If Lightning invoice payment status can be detected:
  • Display a confirmation indicating:
    • The order has been received
    • Payment has been successfully completed