Ecosyste.ms: Awesome
An open API service indexing awesome lists of open source software.
https://github.com/lnbits/market
market extension, inspired by nostrmarket
https://github.com/lnbits/market
Last synced: about 1 month ago
JSON representation
market extension, inspired by nostrmarket
- Host: GitHub
- URL: https://github.com/lnbits/market
- Owner: lnbits
- License: mit
- Archived: true
- Created: 2023-02-10T13:15:26.000Z (almost 2 years ago)
- Default Branch: main
- Last Pushed: 2024-05-14T08:15:40.000Z (7 months ago)
- Last Synced: 2024-08-03T06:04:58.058Z (4 months ago)
- Language: HTML
- Homepage:
- Size: 130 KB
- Stars: 4
- Watchers: 3
- Forks: 1
- Open Issues: 8
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
- awesome-lnbits - Market - Build your own shop stall on a virtual marketplace with LNbits (Uncategorized / Uncategorized)
README
### WE ADVISE USING NOSTR MARKET, BUT HAVE LEFT THIS EXTENSION HERE IN CASE ANYONE WANTS TO CONTRIBUTE.
> This was originally built to be a nostr market as well, although now that turned into this extension. The below has been kept for historcial context, but is irrelvant for this extension.
## Nostr Diagon Alley protocol (for resilient marketplaces)
`authur: Ben Arc`
#### Original protocol https://github.com/lnbits/Diagon-Alley
> The concepts around resilience in Diagon Alley helped influence the creation of the NOSTR protocol, now we get to build Diagon Alley on NOSTR!
In Diagon Alley, `merchant` and `customer` communicate via NOSTR relays, so loss of money, product information, and reputation become far less likely if attacked.
A `merchant` and `customer` both have a NOSTR key-pair that are used to sign notes and subscribe to events.
#### For further information about NOSTR, see https://github.com/nostr-protocol/nostr
## Terms
* `merchant` - seller of products with NOSTR key-pair
* `customer` - buyer of products with NOSTR key-pair
* `product` - item for sale by the `merchant`
* `stall` - list of products controlled by `merchant` (a `merchant` can have multiple stalls)
* `marketplace` - clientside software for searching `stalls` and purchasing `products`
## Diagon Alley Clients
### Merchant admin
Where the `merchant` creates, updates and deletes `stalls` and `products`, as well as where they manage sales, payments and communication with `customers`.
The `merchant` admin software can be purely clientside, but for `convenience` and uptime, implementations will likely have a server listening for NOSTR events.
### Marketplace
`Marketplace` software should be entirely clientside, either as a stand-alone app, or as a purely frontend webpage. A `customer` subscribes to different merchant NOSTR public keys, and those `merchants` `stalls` and `products` become listed and searchable. The marketplace client is like any other ecommerce site, with basket and checkout. `Marketplaces` may also wish to include a `customer` support area for direct message communication with `merchants`.
## `Merchant` publishing/updating products (event)
NIP-01 https://github.com/nostr-protocol/nips/blob/master/01.md uses the basic NOSTR event type.
The `merchant` event that publishes and updates product lists
The below json goes in `content` of NIP-01.
Data from newer events should replace data from older events.
`action` types (used to indicate changes):
* `update` element has changed
* `delete` element should be deleted
* `suspend` element is suspended
* `unsuspend` element is unsuspended
```
{
"name": ,
"description": ,
"currency": ,
"action": ,
"shipping": [
{
"id": ,
"zones": ,
"price": ,
},
{
"id": ,
"zones": ,
"price": ,
},
{
"id": ,
"zones": ,
"price": ,
}
],
"stalls": [
{
"id": ,
"name": ,
"description": ,
"categories": ,
"shipping": ,
"action": ,
"products": [
{
"id": ,
"name": ,
"description": ,
"categories": ,
"amount": ,
"price": ,
"images": [
{
"id": ,
"name": ,
"link":
}
],
"action": ,
},
{
"id": ,
"name": ,
"description": ,
"categories": ,
"amount": ,
"price": ,
"images": [
{
"id": ,
"name": ,
"link":
},
{
"id": ,
"name": ,
"link":
}
],
"action": ,
},
]
},
{
"id": ,
"name": ,
"description": ,
"categories": ,
"shipping": ,
"action": ,
"products": [
{
"id": ,
"name": ,
"categories": ,
"amount": ,
"price": ,
"images": [
{
"id": ,
"name": ,
"link":
}
],
"action": ,
}
]
}
]
}
```
As all elements are optional, an `update` `action` to a `product` `image`, may look as simple as:
```
{
"stalls": [
{
"id": ,
"products": [
{
"id": ,
"images": [
{
"id": ,
"name": ,
"link":
}
],
"action": ,
},
]
}
]
}
```
## Checkout events
NIP-04 https://github.com/nostr-protocol/nips/blob/master/04.md, all checkout events are encrypted
The below json goes in `content` of NIP-04.
### Step 1: `customer` order (event)
```
{
"id": ,
"name": ,
"description": ,
"address": ,
"message": ,
"contact": [
"nostr": ,
"phone": ,
"email":
],
"items": [
{
"id": ,
"quantity": ,
"message":
},
{
"id": ,
"quantity": ,
"message":
},
{
"id": ,
"quantity": ,
"message":
}
}
```
Merchant should verify the sum of product ids + timestamp.
### Step 2: `merchant` request payment (event)
Sent back from the merchant for payment. Any payment option is valid that the merchant can check.
The below json goes in `content` of NIP-04.
`payment_options`/`type` include:
* `url` URL to a payment page, stripe, paypal, btcpayserver, etc
* `btc` onchain bitcoin address
* `ln` bitcoin lightning invoice
* `lnurl` bitcoin lnurl-pay
```
{
"id": ,
"message": ,
"payment_options": [
{
"type": ,
"link":
},
{
"type": ,
"link":
},
{
"type": ,
"link":
}
}
```
### Step 3: `merchant` verify payment/shipped (event)
Once payment has been received and processed.
The below json goes in `content` of NIP-04.
```
{
"id": ,
"message": ,
"paid": ,
"shipped": ,
}
```
## Customer support events
Customer support is handle over whatever communication method was specified. If communicationg via nostr, NIP-04 is used https://github.com/nostr-protocol/nips/blob/master/04.md.
## Additional
Standard data models can be found here here