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

Additional fields

That depends on the type array additional keys which might be present in claim object. See the Types for supported types.

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"
  }
}

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.