Awesome

Diagon Alley: Decentralised Market-Stall Protocol

Diagon Alley is a decentralised market-stall protocol, that shifts emphasis from the frontend market to the merchants stall. If a frontend market (indexer) gets taken down, merchants just point their stalls elsewhere. Game-theoretically the winner of Diagon Alley is the most forthright, although suggestions on limiting bad behaviour are very welcome.

Indexers

An indexer is a simple frontend server and GUI that routes product, payment and shipping information between merchant and buyer. Each merchant has products in a stall. The stall chooses what products to list with the indexer. An indexer has one endpoint.

/register/<stall_ID> POST The <stall_ID> is generated by the stall. the endpoint is for stalls to fetch rating data (0-100%), register products and check the indexer is online.

Body (application/json) {"stall_url": <string>}

Returns 200 OK (application/json) {"shopstatus": <boolean>, "rating": <int>}

The indexer uses the <stall_url> and <indexer_ID> for the stall endpoints.

The indexer may present information from the stalls it has registered in any way it want, either as a web shopping experience or an API or something else. It must show the stall_ID along with each product listing. When the customer clicks "buy" or equivalent it must fetch the invoice from the stall and present it to the customer.

Stalls

A stall has a keypair it uses to register itself to indexes and sign invoices. That keypair isn't related to any Lightning Network keypair, it's independent.

A stall can choose to list some/all products with an indexer. A stall is a small server that has three endpoints.

/products/<indexer_ID> GET for fetching all products associated with an indexer ID

Returns 200 OK (application/json)

[
  {
    "product_id": <string>,
    "product_name": <string>,
    "categories": <list>,
    "description": <string>,
    "image": <string>,
    "price": <int>,
    "quantity": <int>
  },
  ...
]

/order/<indexer_ID> POST for placing an order and sending shipping data. Returns a Lightning invoice, metadata and checking_id.

metadata is a JSON array encoded as string containing at least two items:
```
[
 [
 "text/plain",
 <string> // detailed description of the item that will be shipped and its destination>
 ],
 [
 "application/vnd.diagonalley.signature",
 <string> // DER-encoded ECDSA secp256k1 signature of the <string> tagged as "text/plain" the with the stall private key
 ]
]
```
Invoices must contain the h tag (description_hash) set to sha256(metadata).

This is such that customers can be sure they are paying an invoice originating from the stall and not from a malicious indexer. The information on metadata may be displayed in a nice way by the indexer interface, but its validity should be checked independently by the customer, perhaps at an independent website that allows him to copy-and-paste payment_request, metadata and stall_ID.

Body (application/json) 
```
{
 "product_id": <string>,
 "address": <string>,
 "shippingzone": <integer>,
 "email": <string>,
 "quantity": <integer>
}
```
Returns 201 CREATED (application/json) {"metadata": <string>, "payment_request": <string>, "checking_id": <string>}
/status/<checking_id> GET for checking an order status.

Returns 200 OK (application/json) {"status": "SHIPPED" | "PAID" | "UNKNOWN"}