Cypher's avatar
Cypher cypher@cypher.space 1 week ago
Article header

Decommerce Prompt ( NIP99)

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

Published: 1 week ago

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
↑