Kind

Kinds define the composition, interactions, and asset computations for specific types of objects within the protocol.

All kinds are created from the Set of Kinds, governed by the Kind Registry contract.

Each kind adheres to the Kind of Kind, which specifies the structure, interactions, and asset computations of kind objects themselves.

Several original kinds were established during the initial deployment of the protocol, and many more continue to emerge as users register new kinds.

Kinds are crucial in defining the behavior of objects created by sets. When an object is assigned a specific kind through its set contract, it commits to adhering to the behaviors and rules outlined by that kind.

Creation

Kind objects are created unpon registration, they are initialized as follows:

id

For original kinds, the id field is predefined by constants in the protocol:

uint64 constant ID_KIND_OF_SPACE     = 0;
uint64 constant ID_KIND_OF_SET       = 1;
uint64 constant ID_KIND_OF_KIND      = 2;
uint64 constant ID_KIND_OF_RELATION  = 3;
uint64 constant ID_KIND_OF_TRANSFORM = 4;

For emergent kinds, created dynamically later, their IDs are allocated from a specific range:

uint64 constant ID_KIND_EMERGENT_MIN = 17;
uint64 constant ID_KIND_EMERGENT_MAX = type(uint56).max;

The id is constrained to values no greater than 2^56 - 1 to ensure that the upper 8 bits of the uint64 remain unset.

meta

The meta field is initialized in the following manner, applicable to both original and emergent kinds.

meta.flags      = 0;
meta.rev        = 1;
meta.kindRev    = latestKindOfKind();    // The latest revision of the Kind of Kind
meta.setRev     = latestSetOfKind();     // The latest revision of the Set of Kinds
meta.kind       = ID_KIND_OF_KIND;
meta.set        = ID_SET_OF_KIND;

Since the kind and set objects always point to their latest revisions, kinds created later may have higher values in these fields.

elems

According to the Kind of Kind, a kind object is composed of the following elements:

All elements should be provided upon registration, the shape element cannot be changed once it is set.

shape

The shape element defines the types of elements that compose an object of this kind.

It is interpreted as an array of uint8 values, with any trailing zeroes removed. The length of this array must be between 0 and 16, meaning an object can have no elements or up to a maximum of 16 elements.

All element types must be greater than 0. The following types are supported:

uint8 constant ELEMENT_TYPE_OBJECT            = 1;
uint8 constant ELEMENT_TYPE_INFORMATION       = 2;
uint8 constant ELEMENT_TYPE_VALUE             = 3;
uint8 constant ELEMENT_TYPE_ARTIFACT          = 4;
uint8 constant ELEMENT_TYPE_MATERIAL_GENERAL  = 5;
uint8 constant ELEMENT_TYPE_MATERIAL_JSON     = 6;
uint8 constant ELEMENT_TYPE_MATERIAL_PTABLE   = 7;
uint8 constant ELEMENT_TYPE_MATERIAL_MKTREE   = 8;
uint8 constant ELEMENT_TYPE_MATERIAL_IMAGE    = 9;

code

The code element refers to the material hash of the kind contract.

A kind contract is a WebAssembly (Wasm) bytecode that conforms to specifications defined by the OVM (Object Virtual Machine). These contracts are often compiled from source code written in AssemblyScript using kind-as or in Rust using kind-rs.

gene

The gene element is the material hash representing the shared data for all objects under this kind.

This data is typically utilized in the kind contract, and its format—both content type and structure—should conform to what the kind contract expects. The exact design is at the user’s discretion.

For example, in a typical scenario, the material might be required in JSON format and include fields such as:

• name: The name of the kind.
• description: A description of the kind.
• image (optional): A URL or reference to an image representing the kind.
• ... (optional): Additional fields specific to the kind.

relsN

The relsN elements define the relations that objects of this kind should support.

These elements provide space for up to 8 relation IDs (uint64). Each relation ID is encoded in big-endian format, written one by one into the relsN elements, filling 32 bytes from left to right. If fewer than 8 relation IDs are specified, the remaining space is filled with zeroes.

Operations

Interoperations are not applicable to set objects, all unary operations are supported and listed below: