chore: code format

This commit is contained in:
Vlad Stan 2023-02-28 09:44:46 +02:00
parent 9b6b1e87b9
commit 5484560435
3 changed files with 19 additions and 27 deletions

View file

@ -6,24 +6,23 @@
In Diagon Alley, `merchant` and `customer` communicate via NOSTR relays, so loss of money, product information, and reputation become far less likely if attacked. 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. 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 #### For further information about NOSTR, see https://github.com/nostr-protocol/nostr
## Terms ## Terms
* `merchant` - seller of products with NOSTR key-pair - `merchant` - seller of products with NOSTR key-pair
* `customer` - buyer of products with NOSTR key-pair - `customer` - buyer of products with NOSTR key-pair
* `product` - item for sale by the `merchant` - `product` - item for sale by the `merchant`
* `stall` - list of products controlled by `merchant` (a `merchant` can have multiple stalls) - `stall` - list of products controlled by `merchant` (a `merchant` can have multiple stalls)
* `marketplace` - clientside software for searching `stalls` and purchasing `products` - `marketplace` - clientside software for searching `stalls` and purchasing `products`
## Diagon Alley Clients ## Diagon Alley Clients
### Merchant admin ### Merchant admin
Where the `merchant` creates, updates and deletes `stalls` and `products`, as well as where they manage sales, payments and communication with `customers`. 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. The `merchant` admin software can be purely clientside, but for `convenience` and uptime, implementations will likely have a server listening for NOSTR events.
@ -39,14 +38,14 @@ The `merchant` event that publishes and updates product lists
The below json goes in `content` of NIP-01. The below json goes in `content` of NIP-01.
Data from newer events should replace data from older events. Data from newer events should replace data from older events.
`action` types (used to indicate changes): `action` types (used to indicate changes):
* `update` element has changed
* `delete` element should be deleted
* `suspend` element is suspended
* `unsuspend` element is unsuspended
- `update` element has changed
- `delete` element should be deleted
- `suspend` element is suspended
- `unsuspend` element is unsuspended
``` ```
{ {
@ -175,7 +174,6 @@ As all elements are optional, an `update` `action` to a `product` `image`, may l
``` ```
## Checkout events ## Checkout events
NIP-04 https://github.com/nostr-protocol/nips/blob/master/04.md, all checkout events are encrypted NIP-04 https://github.com/nostr-protocol/nips/blob/master/04.md, all checkout events are encrypted
@ -184,7 +182,6 @@ The below json goes in `content` of NIP-04.
### Step 1: `customer` order (event) ### Step 1: `customer` order (event)
``` ```
{ {
"id": <String, UUID derived from sum of product ids + timestamp>, "id": <String, UUID derived from sum of product ids + timestamp>,
@ -213,7 +210,7 @@ The below json goes in `content` of NIP-04.
"quantity": <String, stall name>, "quantity": <String, stall name>,
"message": <String, special request> "message": <String, special request>
} }
} }
``` ```
@ -227,10 +224,11 @@ Sent back from the merchant for payment. Any payment option is valid that the me
The below json goes in `content` of NIP-04. The below json goes in `content` of NIP-04.
`payment_options`/`type` include: `payment_options`/`type` include:
* `url` URL to a payment page, stripe, paypal, btcpayserver, etc
* `btc` onchain bitcoin address - `url` URL to a payment page, stripe, paypal, btcpayserver, etc
* `ln` bitcoin lightning invoice - `btc` onchain bitcoin address
* `lnurl` bitcoin lnurl-pay - `ln` bitcoin lightning invoice
- `lnurl` bitcoin lnurl-pay
``` ```
{ {
@ -276,6 +274,3 @@ Customer support is handle over whatever communication method was specified. If
## Additional ## Additional
Standard data models can be found here <a href="models.json">here</a> Standard data models can be found here <a href="models.json">here</a>

View file

@ -11,7 +11,6 @@ from lnbits.helpers import url_for
from lnbits.tasks import register_invoice_listener from lnbits.tasks import register_invoice_listener
async def wait_for_paid_invoices(): async def wait_for_paid_invoices():
invoice_queue = asyncio.Queue() invoice_queue = asyncio.Queue()
register_invoice_listener(invoice_queue) register_invoice_listener(invoice_queue)
@ -30,4 +29,3 @@ async def on_invoice_paid(payment: Payment) -> None:
async def subscribe_nostrclient_ws(): async def subscribe_nostrclient_ws():
print("### subscribe_nostrclient_ws") print("### subscribe_nostrclient_ws")

View file

@ -2,16 +2,15 @@ import json
from http import HTTPStatus from http import HTTPStatus
from fastapi import Depends, Request from fastapi import Depends, Request
from starlette.responses import HTMLResponse
from fastapi.templating import Jinja2Templates from fastapi.templating import Jinja2Templates
from loguru import logger from loguru import logger
from starlette.responses import HTMLResponse
from lnbits.core.models import User from lnbits.core.models import User
from lnbits.decorators import check_user_exists from lnbits.decorators import check_user_exists
from . import nostrmarket_ext, nostrmarket_renderer from . import nostrmarket_ext, nostrmarket_renderer
templates = Jinja2Templates(directory="templates") templates = Jinja2Templates(directory="templates")