Claims [DRAFT]

December 21, 2022 · View on GitHub

Permissionless Software Foundation Specification 008 (PS008)

Date originally published: December 21, 2022

Date last updated: December 21, 2022

Acknowledgments

This document refines the 'Claims' concept laid out in PS006 Simple Store Protocol
This specification leverages the Lokad ID. A pull request has been submitted to identify this protocol with Lokad ID 0x00504d00.

Claims are statements placed onto the blockchain, which are cryptographically signed by the originator. Claims can be reviews, certification badges, metadata, or can refer to other Claims. Their data structure is based on the Review schema.

Claims always and only refer to a Token, or to another Claim. Claims are a way to leave on-chain metadata about Tokens (or other Claims).

2. Claims

Claims are primarily used to leave reviews or comments about a SLP token. However, Claims can reference other Claims. For example, a Token owner can generate a Claim to respond to a Claim generated by someone else.

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 and social history for tokens.

2.1 Claim Examples

The protocol for generating a Claim 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 (0x00504d00) and 2-byte prefix (0x0000), which are both hex-encoded.
OP_RETURN outputs must be the first output in the transaction.

2.1.1 Example for making a Claim about a Token:

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

OP_RETURN 0x00504d00 0x0000 7ce786b1b975c53c474764ca136f60bcf9dd438a1d0c01d94821f804c7b09749 ipfs://bafybeif253afapbm23cq5mujt4pw2mb22lijwppgu57o2obqms5z2x54lu

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

0x00504d00 is the Lokad ID for SSP
0x0000 is a 2-byte prefix, which can be used to expand this protocol in the future.
7ce786b1b975c53c474764ca136f60bcf9dd438a1d0c01d94821f804c7b09749 is the token ID for the token.
ipfs://bafybeif253afapbm23cq5mujt4pw2mb22lijwppgu57o2obqms5z2x54lu - is JSON data containing the Claim information, stored on the IPFS network.

2.1.2 Example for making a Claim about another Claim:

Token holders and other users can respond to Claims, by generating a new Claim that references another Claim. The first output of the transaction would be formatted like this:

OP_RETURN 0x0504d00 0x0000 04c3ecfc12097d680c2c5f4a82984b3e75609da3105123a95d1c1dff8e6f1a4f p2wdb://zdpuArdVoAiujGRnfPUGg4ZMHweze1uL7MRM4LWfMmHLNzJRy

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

0x00504d00 is the Lokad ID for SSP
0x0000 is a 2-byte prefix, which can be used to expand this protocol in the future.
04c3ecfc12097d680c2c5f4a82984b3e75609da3105123a95d1c1dff8e6f1a4f is the transaction ID of the original Claim.
p2wdb://zdpuArdVoAiujGRnfPUGg4ZMHweze1uL7MRM4LWfMmHLNzJRy - is JSON data containing the claim information, stored on the P2WDB network.

3. Data Storage

This section defines the prefixes and data storage used by Claims. Claim data can be stored on any of the networks defined below.

The ipfs:// prefix indicates that the data is stored on the IPFS network and is referenced by a CID. This data should be able to be retrieved through any public IPFS gateway.
The p2wdb:// prefix indicates that the data can be retrieved from the pay-to-write database (P2WDB). These also use a CID, which starts with the letter 'z'. These are OrbitDB CIDs. The data can be retrieved from any instance of the P2WDB.