Hellar Platform is based on document-oriented database concepts and uses related terminology. In short, JSON documents are stored into document collections which can then be fetched back using a query language similar to common document-oriented databases like MongoDB, CouchDB, or Firebase.
Documents are defined in an application’s Data Contract and represent the structure of application-specific data. Each document consists of one or more fields and the indices necessary to support querying.
Hellar Platform Protocol (HPP) defines a set of base fields that must be present in all documents. For the reference implementation, the base fields shown below are defined in the document base schema.
| Field Name | Description |
|---|---|
| $id | The document ID (32 bytes) |
| $type | Document type defined in the referenced contract |
| $revision | Document revision (=>1) |
| $dataContract | Data contract the document is associated with |
| $ownerId | Identity of the user submitting the document (32 bytes) |
| $createdAt | Time (in milliseconds) the document was created |
| $updatedAt | Time (in milliseconds) the document was last updated |
🚧 Timestamp fields
Note: The
$createdAtand$updatedAtfields will only be present in documents that add them to the list of required properties.
Each application defines its own fields via document definitions in its data contract. Details of the HPNS data contract documents are described below as an example. This contract defines two document types (preorder and domain) and provides the functionality described in the Name Service explanation.
| Document Type | Field Name | Data Type |
|---|---|---|
| preorder | saltedDomainHash | string |
| — | — | — |
| domain | label | string |
| domain | normalizedLabel | string |
| domain | parentDomainName | string |
| domain | normalizedParentDomainName | string |
| domain | preorderSalt | array (bytes) |
| domain | records | object |
| domain | records.hellarUniqueIdentityId | array (bytes) |
| domain | records.hellarAliasIdentityId | array (bytes) |
| domain | subdomainRules | object |
| domain | subdomainRules.allowSubdomains | boolean |
The following example shows the structure of a HPNS domain document as output from JSON.stringify(). Note the $ prefix indicating the base fields.
{ "$id": "3AhZ5h63ZrFJXfE3YP3iEFVxyndYWPMxR9fSEaMo67QJ", "$ownerId": "6TGHW8WBcNzFrWwAueGtqtAah7w98EELFZ7xdTHegnvH", "label": "DQ-Jasen-82083", "normalizedLabel": "dq-jasen-82083", "normalizedParentDomainName": "hellar", "parentDomainName": "hellar", "preorderSalt": "bcCSdtGqqZdXBQB4DDBIU2RPAwFDFt9tMr0LX6m5qCQ=", "records": { "dashUniqueIdentityId": "UQTRY+wqPyL27V7YjJadJdyXVBETj6CfzvqUg5aY5E4=" }, "subdomainRules": { "allowSubdomains": false }, "$revision": 1, "$createdAt": null, "$updatedAt": null, "$dataContract": { // Truncated ... }, "$type": "domain" }
Once a document has been created, it must be encapsulated in a State Transition to be sent to the platform. The structure of a document state transition is shown below. For additional details, see the State Transition explanation.
| Field Name | Description |
|---|---|
| protocolVersion | Dash Platform Protocol version (currently 1) |
| type | State transition type (1 for documents) |
| ownerId | Identity submitting the document(s) |
| transitions | Document create, replace, or delete transitions (up to 10 objects) |
| signaturePublicKeyId | The id of the identity public key that signed the state transition |
| signature | Signature of state transition data |
The document create transition is used to create a new document on Hellar Platform. The document create transition extends the base schema to include the following additional fields:
| Field | Type | Description |
|---|---|---|
| $entropy | array (32 bytes) | Entropy used in creating the document ID |
| $createdAt | integer | (Optional) Time (in milliseconds) the document was created |
| $updatedAt | integer | (Optional) Time (in milliseconds) the document was last updated |