Data Model - Claims¶
Claims are the smallest self-contained pieces of information - an arbitrary information package - inside the Userfeeds Platform. They are also the only way of introducing any information to databases which is sent via the so-called transports and then interpreted by algorithms in order to return the requested information to interfaces. All claims are signed cryptographically or have a reference to their cryptographic origin which can be a transaction (call) on the blockchain, for example.
Structure¶
The typical structure of a claim is presented in the Overview below:
Overview¶
The Claim may look as follows:
{
"context": "CONTEXT",
"type": ["TYPEA", "TYPEB", "..."],
"claim": {
"target": "TARGET",
"additional": "fields",
"go": ["here", "..."]
},
"credits": [
{
"type": "interface",
"value": "INTERFACE IDENTIFIER"
}
],
"signature": {
"type": "TYPE",
"creator": "CREATOR",
"signatureValue": "SIGNATURE"
}
}
The format of claims is rather isolated from structure of data in a block-chain - and this is why it is in the json format
We cannot say that there are types of claims as they accompany transactions in general and it is the transaction which is the main part. And it is the contract on a given block-chain which defines in which way the claim will be read and treated. Basing on that we can that:
- There are Claims with a value for a defined account - usually used for getting to a higher position in a ranking – the value is the score – and it is the algorithm which decides if the structure of such claim is proper (it is transation with use of token)
- There are Claims serving solely for connecting sensual / graphic / text data with some transaction data
- There are Claims serving for limiting the number of users who can apply for transactions by defining parameters for such transactions and users
It is important to remember that claims are an optional part of transactions and in that way they are treated by algorithms.
Claims which do not bear or transfer a value (from the main Ethereum net) can be used on any block-chain as no token for the identification is needed. Therefore a normal claim without a value should be rather used outside of the Ethereum main net.
Context
¶
Note
Populating this field is optional.
The Context field is used to denote a destination of a given claim. It can be interpreted as a name of any topic or thing about which people might want to share information. Usually it will have something to do with a blockchain space (but it doesn’t have to).
For example if you would like to share some information to all people interested in Ethereum blockchain you will send a claim with ethereum
as the context.
Other examples of contexts may be:
- ethereum
- ethereumclassic
- bitcoin
- ethereum:0x4564567890abcdef….abc
- ethereumclassic:0x4564567890abcdef….abc
- myspecialcontext
- companyx
- companyx:departmenty
ethereum:0x123....456
context identifiers are interpreted as object 0x123….456 on ethereum and usually will be used to share information about contracts / addresses on a given blockchain.
Special contexts such as starting with userfeeds: are technical and have a special meaning in the Userfeeds Platform, eg. userfeeds:pairing will create a special PAIRED relationship allowing one to connect their crypto-currency holdings with an additional public key which will only be used to sign claims.
Type
¶
Note
Populating this field is optional.
The Type describes an additional data present in a claim object.
An example can be the labels type. The object of claim of that type needs to have a labels key with an array of values.
The description of all supported types can be found at Types
Claim
¶
This key is used to store user provided information and it is mandatory for all claims.
claim
object will always have a target
key and additional fields depending on the type
array.
Target
¶
The Target
value identifies a target object which the user wants to share or tag with additional information.
Examples of proper target
values are:
- http://some.url/path/
- text:base64:base64encodedtext
- ipfs:somehash
- ipdb:somehash
- claim:claimsignaturehash
- mediachain:somehash
- isbn:0451450523
- isan:0000-0000-9E59-0000-O-0000-0000-2
- btih:c12fe1c06bba254a9dc9f519b335aa7c1367a88a
- ethereum:0x4564567890abcdef…abc
- bitcoin:0x4afebcdef…123
Signature
¶
This field is generated in order to denote the ownership of claim and the content can be a cryptographic signature or a pointer to the cryptographically secured origin of claim.
Type
¶
Describes what type of signature we are dealing with. It could be ecdsa.secp256r1
for the elliptic curve signature or ethereum.transaction
for the claim origination from the Ethereum blockchain.
Supported Signature Types¶
ecdsa.prime192v1
- In python: ecdsa.NIST192p
ecdsa.secp256r1
/ecdsa.prime256v1
- In python: ecdsa.NIST256p
ecdsa.secp224r1
- In python: ecdsa.NIST224p
ecdsa.secp384r1
- In python: ecdsa.NIST384p
ecdsa.secp521r1
- In python: ecdsa.NIST521p
ecdsa.secp256k1
- In python: ecdsa.SECP256k1
ethereum.transaction
Claims posted on ethereum blockchain will be verified by comparing the blockchain content with the claim content.
Creator
¶
This identifies a public key or an address which signed the claim.
Format: identifier
- hex:04861127b14bf0036e…ef7127b114988057
- rinkeby:0x1234567890abcdef…1456
- ethereum:0x1235…145
- bitcoin:0x123456…1234
Signature Value
¶
This key holds a raw signature value as produced by the signing algorithm or it can be a transaction hash or any valid identifier of some externally verifiable origin of claim.
Types¶
Basic¶
Basic claim:
{
"claim": {
"target": "http://some.url/path/"
},
"context": "ethereum:0x4564567890abcdef....abc",
"signature": {
"creator": "94d1aa6655d931294d524cf52b0df866976f89774bac38a730cf20e2d51dd24d34efc2bbb4d5bba91a7a6582511491dde1803dcdf7fd55550cf3132aae16077a",
"signatureValue": "304402203dac2176721d7e05cd8c580a27a504b64b0a8ee171b18a07630201cbed979ac7022013faf8735f90b957ca4656efb17349856ac22894aab553db136b7dfc2b03ede4",
"type": "ecdsa.prime256v1"
}
}
With the acknowledgment of the interface from which the claim was created:
{
"claim": {
"target": "http://some.url/path/"
},
"context": "ethereum:0x4564567890abcdef....abc",
"credits": [
{
"type": "interface",
"value": "http://blog.example.com/path/"
}
],
"signature": {
"creator": "0df1d4915347bcae90a0696c9efd6300e33b610d31130c3049d329fa61af138de7a7ee55f99057fd8d39c4664be9f1c34361c237433b34c8f523c5858f9fb9a0",
"signatureValue": "304502206c243684007c9e412612b5d1a371b20eb146652e4b149bb1fc0e6da437e7f728022100b8c77983949feac478de449751587be82d5b37ff30b257da04f2352aab5f8793",
"type": "ecdsa.prime256v1"
}
}
Link
¶
Additional keys:
title
stringsummary
string
{
"claim": {
"summary": "summary",
"target": "http://some.url/path/",
"title": "title"
},
"context": "rinkeby:0xfe5da6ae3f65e7d5ce29121a9f5872ffd83b45e6",
"credits": [
{
"type": "interface",
"value": "http://blog.example.com/path/"
}
],
"signature": {
"creator": "ffc8c2f39e8a302bf9ca37b06fa9014f0cd3c85900c3d8b771f31a91ce33c050948faedad14d73a4f6c41f5937c3a010b5af24055092c136b7a667fee2249f87",
"signatureValue": "304602210093c55c30be1868de005def995aefb391d7ff20f235457b37a01e6921427701f80221008e5fc2afc2c9124660a57f9a2c9f4be1187afe3bc4b3c67a30e9a4c52747f4f7",
"type": "ecdsa.prime256v1"
},
"type": [
"link"
]
}
Labels
¶
Additional keys:
labels
array of string
{
"claim": {
"labels": [
"Good",
"Book",
"Cats"
],
"target": "http://some.url/path/"
},
"context": "rinkeby:0xfe5da6ae3f65e7d5ce29121a9f5872ffd83b45e6",
"signature": {
"creator": "de9965ce03cf6f960a7efe423633409a0052ad8f9f2100e27026ad94551d4d69058c0a263dbd0cacf999ca3e97ddcc0afae5051e91dc42c4ca008e4c7c5c0ddb",
"signatureValue": "3044022069457927f1fc06b26467a7cc93c99085efea4d8811c6979ffab9ba2196be5ad702201587d3f88d2e9058d6ce48708ddf8713b07017a311ce713b566a1829ea516e41",
"type": "ecdsa.prime256v1"
},
"type": [
"labels"
]
}
Value Transfer¶
Along with claims the Userfeeds Database contains normalized data about transfer of assets (tokens and others)
If the transfer of assets was accompanying a claim, they will be connected with the TRANSFER relation.