Simple Store Protocol (SSP)

July 25, 2022 ยท View on GitHub

Permissionless Software Foundation Specification 006 (PS006)

Specification version: 1.0.0

Date originally published: July 14, 2022

Date last updated: July 22, 2022

Authors

Chris Troutner

Acknowledgments

1. Introduction

The Simple Store Protocol (SSP) describes data structures for representing stores, products, and reviews on Bitcoin blockchains, by leveraging the OP_RETURN field of a transaction.

2. Definitions

  • Stores are the most fundamental data structure in the protocol. They represent an asset (like a business) which contains Products for sale. Their data structure is based on the Store schema.
  • Products are items listed for sale by the Store. Their data structure is based on the Product schema.
  • Claims are statements placed onto the blockchain, which are cryptographically signed by the originator. Claims can be product reviews, store reviews, metadata, or can refer to other Claims. Their data structure is based on the Review schema
  • Customers are users that purchase goods from a Store.

3. Brief Technical Summary

  • Stores are represented as Group Tokens as per the SLP NFT 1 Protocol, which in turn makes use of the Lokad ID specification.
  • Products within the Store are described in mutable data for the Store NFT by following PS002 Mutable Data protocol. Entries follow a JSON Linked-Data format, and whenever possible leverage existing schema.org taxonomy.
  • Claims can represent store reviews, product reviews, metadata, or a Claim about other Claims. This is recorded in transactions, and also leverages the Lokad ID specification.
  • An indexer similar to the psf-slp-indexer will be used to discover and track the above data as it is placed onto the blockchain.

4. Stores

Stores are represented as a SLP Group token. This allows the store to generate NFT tokens which can be used in a variety of ways: receipts, digital products, etc. They follow the Store schema.

Minimum Data

In order for a Group token to be recognized as a Store, it must meet these minimum data requirements:

  • The ticker field of the Group Genesis transaction must start with the letters SSP. There can be additional characters of any kind after those first three.
  • The docuementUrl field of the Group Genesis transaction should reference immutable data as per PS002, which is a JSON document stored on the IPFS network. That data should be less than 1 megabyte in total size, and follow the Store schema. The following minimum fields are required:
{
  "storeData": {
    "@context": "https://schema.org",
    "@type": "Store"
  }
}

5. Products

Products only exist within the context of a Store. Their data structure is based on the Product schema. The data for Products exists within the mutable data of the Store.

6. Claims

Claims are primarily used by Users to leave reviews about a Store or Product. However, Claims can reference other Claims. For example, a Store owner can generate a Claim to respond to a Claim generated by a User.

Claims are not tokens. Instead they are transactions on the blockchain that leverage the Lokad ID specification. Because they are transactions, they are cryptographically signed by the owner of a Bitcoin address (nonrepudiation), and once created, they immutable and uncensorable. Claims provide rich metadata about Stores, Products, and Users.

6.1 Claim Examples

The protocol for generating a Claim within the Simple Store Protocol is inspired by the Simple Ledger Protocol and the memo.cash protocol:

  • The protocol uses P2PKH addresses. Actions are saved using OP_RETURN.
  • Message data is UTF-8 encoded, with the exception of the Lokad ID prefix of 0x00504d00 (hex)
  • OP_RETURN outputs must be the first output in the transaction.

6.1.1 Example for making a Claim about a Store:

The most typical use-case for a Claim is for a customer to leave a review about a Store or product. The first output of the transaction would be formatted like this:

OP_RETURN 0x00504d00 7ce786b1b975c53c474764ca136f60bcf9dd438a1d0c01d94821f804c7b09749 ipfs://bafybeif253afapbm23cq5mujt4pw2mb22lijwppgu57o2obqms5z2x54lu

The claim is split into 'chunks', separated by spaces above. Here is the breakdown:

6.1.2 Example for making a Claim about another Claim:

Store owners can respond to Claims, by generating a new Claim that references the another Claim. The first output of the transaction would be formatted like this:

OP_RETURN 0x0504d00 7ce786b1b975c53c474764ca136f60bcf9dd438a1d0c01d94821f804c7b09749 ipfs://bafybeif253afapbm23cq5mujt4pw2mb22lijwppgu57o2obqms5z2x54lu

The claim takes the same format, but has slightly different context: