searches the current version of every section · esc to close

tagged 2026-04-01 — add 26.05.01 Reconstruction Logic.Go to current (v0.1.51) →

Manifold Standard

Version: 0.1.22

Abstract

The Manifold Standard maps digital data to a space. It defines several types of JSON objects and how to reliably reconstruct the space from them. The reconstructed space contains a three-dimensional scene, and may specify how users can interact and leave traces in the scene.

Status of This Memo

This document is currently not open to the public.

Relation to the reference implementations

One of the reference implementations of the standard is the project Exterior Space. Exterior Space is an open-source browser for spaces stored on-chain, planned to launch alongside the standard.

Exterior Space implements the standard with its own profile for optional fields and modules. It also includes additional features optimized for browsing and editing spaces. Exterior Space supports the standard, and its major version aligns with the standard’s major version. The maintainers plan to extract the conformant core into a standalone open-source package as the reference implementation of the standard, which Exterior Space will then use. Until that is complete, this document will include footnotes about Exterior Space where relevant.

02 Copyright Notice

Copyright (c) 2026 The Manifold Standard Editing Committee and the persons identified as the document authors. All rights reserved.

03 Conventions

03.01 Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here.

03.02 Conventions Used in This Document

Any JSON object defined in this document MUST conform to RFC8259.

Some examples use the combination of a TypeScript single-line comment (//) followed by an ellipsis (...) as placeholder notation for content deemed irrelevant by the authors. These placeholders must of course be deleted or otherwise replaced, before attempting to validate the corresponding JSON code example.

Whitespace is used in the examples inside this document to help illustrate the data structures, but it is not required. Unquoted whitespace is not significant in JSON.

03.03 Type Definitions

In this document, a JSON object type defines the required and optional name-value pairs of a JSON object. An object belongs to a type — or "is of that type" — if it contains all required name-value pairs and only name-value pairs that are either required or optional for that type. Each name-value pair in a type definition specifies the name of the pair and the constraint on its value. Required name-value pairs are indicated by the keywords MUST or REQUIRED; optional name-value pairs by MAY, OPTIONAL, SHOULD, or RECOMMENDED, as defined in Section 03.01.

A JSON type, or simply a type, is a constraint on a JSON value. A JSON object type, as defined above, is a type that constrains an object by specifying its required and optional name-value pairs. A type may also constrain a non-object value by specifying the set of allowed values, for example, a number within a particular range, or a string equal to one of a specified set.

03.04 Representation of Data

In this document, TypeScript code is used to represent data, such as JSON object and JSON object type. However, the TypeScript code SHOULD NOT be considered the only form in which the data can be realized in an implementation.

03.99 Notes

The section 03.02 significantly references the standard RFC 7946.

04 Version Control

In this section, the meaning and handling of the version of the standard are defined.

04.01 Version Number

The version number of the standard and each section of the standard use the format MAJOR.MINOR.PATCH. Notice this is not the standard semantic versioning.

  1. MAJOR version number is the released stable version of the standard. Each MAJOR bump is a release of a stable version, which is a closure of a set of proposed changes to the standard. Each MAJOR bump resets the MINOR version number to zero and increases the MAJOR version number by one. One can refer to a stable version of the standard by the MAJOR version number. For example, Manifold Standard Version 1 refers to Version 1.0.0 of the standard.
  2. MINOR version numbers are used for proposed changes for the next stable version of the standard. Each MINOR bump is a closure of a set of section changes to the standard, with each change labeled with a PATCH version number. Each MINOR bump resets the PATCH version number to zero and increases the MINOR version number by one.
  3. PATCH version numbers are used for proposed changes for the next stable version of one section of the standard. A PATCH bump of the standard is performed when a section of the standard is changed. This section is also marked with the full version number it was last changed. This mark can be referred to as the version number of this section.

04.02 Breaking Changes

A breaking change is a change that either:

  1. Makes the data format not backward compatible, or
  2. Alters the relationship between the data and the reconstructed space in a non-compatible way. This includes changes of default behaviors.

It is RECOMMENDED that stable releases of the standard do not introduce breaking changes. The version number does not imply whether changes are breaking or non-breaking. If a breaking change is included in a stable release, an attachment describing migration from the previous version to the current version MUST be provided in Section 90 of the release.

04.03 Notes on Implementation

  1. Closure is an event of obtaining and confirming the consensus of the Manifold Standard Editing Committee. The Manifold Standard Editing Committee is the maintenance team for the Manifold Standard before version 1.0.0. Each closure MUST ends with a version number bump and a tag of the version to the Git repository.
  2. If a change in one section requires edits in another section, and if the changes have a clear logical order, each edit SHOULD be followed by a PATCH bump. If term changes, typo changes, or convention changes occur in multiple sections, changes to multiple sections MAY be merged into one PATCH bump. If there is a set of inseparable changes across multiple sections, these changes MAY be merged into one PATCH bump.
  3. A section of the standard is defined as one markdown file.

04.04 Implementation of Referencing

  1. Each release of the stable version contains an archive action, for which the released standard MUST be uploaded to durable storage, obtaining the URI for referencing the standard of the particular stable version.
  2. Each proposed version can be referred to using the git tag.
  3. MINOR/PATCH version of the standard MUST NOT be cited as normative in external integrations.

04.05 Errata for Stable Releases

Each post-release erratum of the stable release version is additional documentation called amendments to the stable release version, specifying fixes to the standard of the stable release version. The amended stable release version of the standard is referred to using the version number MAJOR.0.0.ERRATA. It is RECOMMENDED not to issue an erratum for the stable release version unless critical mistakes are made. The amendments MUST be uploaded to durable storage, obtaining the URI for referencing.

04.06 Expiration of This Section

The version numbering, meaning, and handling described in this section are for versions before version 1.0.0. At version 1.0.0, versioning and change control transfer to the governance model that is defined at that time. The governance model after version 1.0.0 may or may not follow this handling of version numbers.

05 Conformance Profile

TODO

10 Introduction

The Manifold Standard specifies a mapping between a defined set of data and a space. Its goal is to define a virtual space where users can store, arrange, decorate, present, generate, update, and interact with digital assets. It provides a canonical data format for serializing these spaces and reliably reconstructing a space from that data. Although similar implementations exist in products and games, they remain closed and therefore fragment users’ memories, creations, and belongings, while a standard provides the common ground for decentralized, user-owned spaces open to anyone, anytime, anywhere, with any digital assets.

The standard is organized into three parts that together define a framework enabling users to experience virtual spaces. The core specifications form the minimal kernel of the standard. They define the scene space and its artifacts, and hence how artifacts are placed within the scene. The extension specifications define how users are connected to the space, that is, how users present themselves and interact within and across spaces. Finally, modules are optional specifications built upon the core and extension specifications to enhance how users experience the space, providing additional layers of interaction, personalization, and growth. Together, the standard enables the space and its artifacts to encode users' live events, helps users share their spaces anywhere, assists users in discovering and engaging with other spaces, brings a sense of time or living creatures into the space, and much more.

11 Scope and Structure

[TODO]

20 Core Specification

The Core Specification defines objects that can be mapped to a scene and objects that represent assets which can be included in the scene.

21 Scene

21.01 Scene and Coordinate type

A scene is a vector space of R3\mathbb{R}^3. We fix the right-handed orientation and an orthonormal basis, labeled x^\hat x, y^\hat y, and z^\hat z. A point in the space can be expressed as a 3-tuple (x,y,z)=xx^+yy^+zz^(x, y, z) = x\,\hat x + y\,\hat y + z\,\hat z, where xx, yy, and zz are real numbers.

A Coordinate type represents a point in the scene and is an array of three real numbers. It is represented as

type Coordinate = [number, number, number]

where the three numbers correspond to xx, yy, and zz, in this order.

The ground plane is the subspace of the scene spanned by the basis x^\hat x and y^\hat y, i.e., the set {(x,y,0)  xR,  yR}\{(x, y, 0)\ |\ x \in \mathbb{R},\; y \in \mathbb{R}\}. The up direction is defined as the positive direction of the basis vector z^\hat z.

21.02 Coordinate Transformation

A coordinate transformation with uniform scale in the scene defined above transforms a vector v=(vx,vy,vz)\vec v = (v_x, v_y, v_z) to sRv+ts\, R \, \vec v + \vec t, where RR is a rotation operator, ss is a real number for uniform scale, and t\vec t is the translation of the origin. Such a transformation can therefore be encoded in three pieces of information: translation t\vec t, rotation RR, and scale ss.

21.02.01 Rotation and Euler Type

Rotation can be represented by the type Euler, specifying the Euler angles as a 3-tuple (x,y,z)(x, y, z) in radians. The rotations are applied in the order of the xx-axis, then the yy-axis, then the zz-axis. It can be represented as

type Euler = [number, number, number]

where the three numbers correspond to rotation in radians around the xx-axis, yy-axis, and zz-axis, in that order. For each rotation, a positive value means counterclockwise rotation. A zero rotation on all axes implies that the axes of the transformed coordinate align with those of the scene coordinate.

21.02.02 Scale and Scale Type

The type Scale represents the scaling of the transformed coordinate about its local origin and is a real number, where a value of 1 means no scaling. It can be represented as

type Scale = number

21.02.03 Local Coordinate

A coordinate distinct from the scene coordinate, also referred to as the global coordinate, is called a local coordinate. A local coordinate can be defined by the coordinate transformation above with respect to the scene coordinate, or can be specified by the origin of the local coordinate in the scene coordinate along with the transformed basis; see Section TODO: local scene.

21.03 Entity in the scene

Each entity in the scene comes with its own local coordinate, and its placement can therefore be described by the three pieces of information defined in Section 21.02. That is, one starts with the entity's local coordinate coinciding with the scene coordinate, then applies the transformation defined in Section 21.02 to the entity.

22 Form Type Object

A Form type object represents the layout of the scene.

Form type is defined as

interface Form {
    version: string // REQUIRED
    layout: Embedding[] // REQUIRED
    metadata?: FormMetadata // OPTIONAL
    properties?: FormProperties // OPTIONAL
}

where

  • version is REQUIRED, and its value MUST be of type string equal to one of the standard’s version numbers (see Section 04-Version-Control).
  • layout is REQUIRED, and its value MUST be an array of Embedding, representing placed artifacts in the space. An empty layout MUST have the value [].
  • metadata is OPTIONAL, and its value MUST be of type FormMetadata. It is used to hold any additional descriptive data about the space. If not provided, an empty FormMetadata is used by default.
  • properties is OPTIONAL, and its value MUST be of type FormProperties. It represents additional properties of the scene. If not provided, an empty FormProperties is used by default.

23 Embedding Type Object

An Embedding type object represents an artifact being placed in the scene.

Embedding type is define as

interface Embedding {
	artifact: Artifact // REQUIRED
    position: Coordinate // REQUIRED
    rotation: Euler // REQUIRED
    scale?: Scale //OPTIONAL
    properties?: EmbeddingProperties // OPTIONAL
}

where

  • artifact is REQUIRED, and its value MUST be of type Artifact.
  • position is REQUIRED, and its value MUST be of type Coordinate.
  • rotation is REQUIRED, and its value MUST be of type Euler.
  • scale is OPTIONAL, and its value MUST be of type Scale.
  • properties is OPTIONAL, and its value MUST be of type EmbeddingProperties. It stores data that modifies or enhances the placed artifact.

An Embedding type object represent an artifact been placed at position with rotation and scale, as defined in 21-Scene#21.03 Entity in the scene.

24 Artifact Type Object

The Artifact type object represents an asset that can be loaded into the space.

Artifact type is defined as

interface Artifact {
	content: string // REQUIRED
	type: ArtifactType // REQUIRED
	metadata: Metadata // RECOMMENDED
}

where

  • content is REQUIRED, and stores the content to be loaded into the scene.
  • type is REQUIRED, and its value MUST be of type ArtifactType. It specifies the artifact type of content and therefore implies the possible loaders that an implementation can use to load the content.
  • metadata is RECOMMENDED, and its value MUST be of type Metadata. It stores relevant information about the asset. If it is not provided, the default MUST be used.

24.01 ArtifactType data

The ArtifactType indicates the artifact type of the asset and therefore the loader that the implementation needs to use to correctly load it. Modules can define more ArtifactType values than those specified in this section.

type ArtifactType = "model"
  • For model artifact type, the implementation need to use a GLTFLoader to load the content, following the glTF standard.

The artifact type, the type member of Artifact, and the ArtifactType type should not be confused with the JSON object type or JSON type. In this document, the single word "type" is reserved for JSON type.

24.02 Artifact Content

The artifact content, as specified in the content field of the Artifact object, MUST be a path or Uniform Resource Locator (URL) to the data that can be loaded by the loader and presented in the scene.

For artifact content of type "model", it is RECOMMENDED that the data be a model file following the GLTF standard. When loaded, such a model contains a local origin.

25 Metadata Type Object

The Metadata type object stores data relevant to an asset.

All members in Metadata are OPTIONAL and if they are not specified, the default value will be used. Modules and extension specifications can define additional members in type Metadata beyond those specified in this section. It is RECOMMENDED that modules make use of the attachment and propertiesmembers rather than introducing new members in the Metadata type.

Metadata type is define as

interface Metadata {
	id: string,
	name: string,
	description: string,
	preview: string,
	creators: string[],
	attachment: ArtifactAttachment
	properties: ArtifactProperties
	// ...
}

where

  • id MUST be of type string representing the path or asset ID of the artifact. Its default value is the content string of the artifact. It is RECOMMENDED that all artifacts loaded in the scene have distinct id values.
  • name MUST be of type string and is the display name of the artifact. Its default value is "Artifact".
  • description MUST be of type string and is the display description of the artifact. Its default value is "", i.e., an empty string.
  • preview MUST be of type string containing the URL to the preview image file, and it is RECOMMENDED that the preview image file be of type PNG.
  • creators MUST be an array of string representing the creators of the artifact.
  • attachment MUST be of type ArtifactAttachment, representing any associated files relevant to this artifact. The attachment member is mainly used by modules and extension specifications.
  • properties MUST be of type ArtifactProperties. It stores data that modifies or enhances the artifact's behavior in the scene. The properties member is mainly used by modules and extension specifications.

26 Enhancing and Modifying the Scene

From the Form data, one can reconstruct a scene by placing each artifact in layout according to its placement as specified in the Embedding. Modules can also add additional information to enhance or modify the scene by making use of the FormMetadataFormProperties, and EmbeddingProperties types. These types by default include only empty objects, i.e., objects with no members, representing no additional or altered behavior beyond placing artifacts in the layout member.

In this section, we go through some modules that can be used to enhance or modify the scene. These modules are not part of the core specification and implementations MAY implement them.

26.01 Form Metadata Module

The Form Metadata module enhances the scene by adding descriptive data for the space, specified in the FormMetadata object.

It is RECOMMENDED to include the following data to record basic information about the space:

  • name of type string
  • description of type string

All other data in FormMetadata are OPTIONAL.

An example of FormMetadata can be represented as:

interface FormMetadata {  
    name: string // RECOMMENDED
    description: string // RECOMMENDED
    // ...
}

26.02 Sky Module

The Sky module enhances the scene by introducing two new members in FormProperties and a new artifact type, allowing a skybox to be specified for the scene.

The new member in FormProperties is defined as

interface FormProperties {
	sky: Artifact // OPTIONAL
	skyVisible: boolean // OPTIONAL
	// ...
}

where

  • sky is OPTIONAL, and its value MUST be of type Artifact with artifact type hdri.
  • skyVisible is OPTIONAL, and its value MUST be of type boolean. If it is not provided, the default value false MUST be used.

The new artifact type is defined as

type ArtifactType = "hdri" // ...

and the implementation MUST use an EXRLoader to load the content, following the EXR standard.

When sky in FormProperties is specified, a supported implementation MUST use the content of the specified artifact as the skybox of the scene. If the sky member is not provided, the implementation may use a default skybox or no skybox. When a skybox is present and skyVisible is true, the skybox MUST be rendered as the visible background. Otherwise, there MUST be no visible background rendered, and the skybox, if present, is used only for environment lighting and reflections.

An implementation that does not support the Sky module MUST ignore the sky and skyVisible member of FormProperties and discard any artifact with artifact type hdri.

When used with the Category module, the artifact MUST use sky as its artifact category.

26.03 Environment Model Module

The Environment Model module enhances the scene by introducing a new member in FormProperties, allowing an environment model to be specified for the scene.

The new member in FormProperties is defined as

interface FormProperties {
	environmentModel: Artifact // OPTIONAL
	// ...
}

where

  • environmentModel is OPTIONAL, and its value MUST be of type Artifact with artifact type model.

When environmentModel in FormProperties is specified, a supported implementation MUST place the content of the specified artifact at the origin of the scene. If the environmentModel member is not provided, the implementation MUST NOT render any environment model.

An implementation that does not support the Environment Model module MUST ignore the environmentModel member of FormProperties.

When used with the Category module, the artifact MUST use environment as its artifact category.

26.04 Boundary Module and Tile Module

26.04.01 Coordinate2D and Euler2D Types

The 2-dimensional coordinate and rotation are represented by the types Coordinate2D and Euler2D, following the same conventions as the 3-dimensional ones defined in 21-Scene. These types are defined as

type Coordinate2D = [number, number]
type Euler2D = number

where Coordinate2D represents the coordinate (x,y)(x, y), in that order, and a positive Euler2D value means counterclockwise rotation.

26.04.02 Boundary Module

The Boundary module modifies the scene by introducing a new member in FormProperties, defining a horizontal boundary of the scene.

The new member in FormProperties is defined as

interface FormProperties {
	boundary: OBB[]  // OPTIONAL
	// ...
}

where

  • boundary is OPTIONAL, and its value MUST be an array of OBB type objects.

An OBB type object represents an oriented rectangle on the ground plane, defined by its center, its rotation about the center, and its halfWidth and halfLength. The OBB type is defined as

interface OBB {  
    center: Coordinate2D // REQUIRED
    rotation: Euler2D // REQUIRED
    halfWidth: number // REQUIRED
    halfLength: number // REQUIRED
}

where

  • center is REQUIRED, and its value MUST be of type Coordinate2D. It represents the center of the oriented rectangle on the ground plane.
  • rotation is REQUIRED, and its value MUST be of type Euler2D. It represents the rotation of the rectangle about its center.
  • halfWidth is REQUIRED, and its value MUST be a number. It represents half the width of the rectangle, aligned with the xx-axis at rotation 0.
  • halfLength is REQUIRED, and its value MUST be a number. It represents half the length of the rectangle, aligned with the yy-axis at rotation 0.

26.04.03 Tile Module

The Tile module modifies the scene by introducing three new members in FormProperties, defining a tiled horizontal boundary of the scene.

The new members in FormProperties are defined as

interface FormProperties {
	tileList: Coordinate2D[] // OPTIONAL
    tileModel: Artifact // OPTIONAL
    tileVisible: boolean // OPTIONAL
    // ...
}

where

  • tileList is OPTIONAL, and its value MUST be an array of Coordinate2D. It represents a tiled horizontal boundary of the scene as an array of positions of square tiles on the ground plane.
  • tileModel is OPTIONAL, and its value MUST be of type Artifact. It represents the visual representation of each tile in the scene. Its value MUST be ignored if tileList is not specified, or if tileVisible is false, or both.
  • tileVisible is OPTIONAL, and its value MUST be of type boolean. It represents the visibility toggle of the tile model. If it is not provided, the default value true MUST be used. Its value MUST be ignored if tileList is not specified.

When tileVisible is true and tileModel is specified, the implementation MUST place tileModel at each position on the ground plane specified by tileList with zero rotation as the visual representation of each tile. When working with the Layout Mode module, the placed tileModel MUST NOT affect the reconstruction logic of the scene and MUST NOT appear in the layout data.

When tileVisible is true and tileModel is not specified, the implementation MAY use its own Artifact as tileModel for the visual representation of the tile. It is RECOMMENDED to use a mid-tone gray plane with dimensions 1 by 1 as the default visual representation of each tile.

When tileVisible is false, there MUST NOT be any visual representation of the tile and the value of tileModel MUST be ignored.

When used with the Category module, the artifact that can be used as value of tileModel MUST use tile as its artifact category.

26.04.04 Horizontal Boundary of the Scene

A horizontal boundary of the scene is defined by a list of oriented rectangles, commonly referred to as oriented bounding boxes (OBBs), as defined in 26.04-Boundary-Module-and-Tile-Module#26.02.02 Boundary Module, lying on the ground plane. The union of the specified list of OBBs defines the inside of the scene, and any point that does not lie within this union is considered outside of the scene. The line where the outside and the inside of the scene meet is the scene boundary.

For general artifacts, the ground plane (x,y)(x, y) placement, i.e., the projection of its (x,y,z)(x, y, z) placement onto the ground plane, MUST NOT lie outside of the scene. This means its (x,y)(x, y) placement may lie on the scene boundary by the definition of outside of the scene. Any artifact whose (x,y)(x, y) placement lies outside of the scene MUST be removed during reconstruction of the scene.

When working with the Layout Mode module, for artifacts participating in stacking logic, no point of such an artifact's footprint MUST lie outside of the scene. That is, such artifacts in layout MUST be removed before the stacking logic is applied.

When the Boundary module, the Tile module, or both are used, the boundary can be specified by the boundary member, the tileList member, or both, in FormProperties. When the boundary is specified by boundary, its value directly gives the OBBs of the boundary. When the boundary is specified by tileList, it is equivalent to a list of OBBs with zero rotation and width and length of 1, i.e., halfWidth and halfLength of 0.5, centered at each element of tileList. When both boundary and tileList are specified, the boundary is their intersection.

When neither boundary nor tileList is specified, or both modules are not supported by the implementation, there is no boundary for the scene and every point in the scene is considered to lie within the boundary.

One MUST NOT confuse the case where these data are specified as empty lists, which indicates that every point lies outside of the boundary, with the case where these data are not specified, which indicates that there is no boundary and every point in the scene lies within the boundary.

Please note that this boundary is the boundary of the scene, not the boundary for avatar movement. For the boundary of avatar movement, please see TODO.

26.05 Layout Mode Module

The Layout Mode module modifies the scene by introducing different layout modes. The original layout, i.e., each artifact placed in the scene with all possible positions, rotations, and scales as specified in the Embedding type object, is referred to as the freeform layout mode in the Layout Mode module. Other layout modes are restrictions on the freeform mode that are more suitable for particular uses of the space.

Besides the freeform layout mode, four layout modes are specified, each with a two-dimensional and a three-dimensional version. Other modules can extend this module by introducing new layout modes. The layout modes defined by this module are:

  • Continuous layout mode
  • Discrete layout mode
  • Block layout mode
  • Slot layout mode

The Layout Mode module introduces a few new members in FormProperties. The central member is the layoutMode member, defined as

interface FormProperties {
	layoutMode: LayoutMode // OPTIONAL
	// ...
}

where

  • layoutMode is OPTIONAL, and its value MUST be of type LayoutMode. It specifies which layout mode is used. If not provided, the freeform layout mode is used by default.

The LayoutMode type is defined as

type LayoutMode =
  | 'freeform' | 'continuous' | 'discrete' | 'block' | "slot"
  | 'flat-freeform' | 'flat-continuous' | 'flat-discrete' | 'flat-block'

where

  • freeform indicates the freeform layout mode in three dimensions.
  • continuous indicates the continuous layout mode in three dimensions. It does not have restrictions on position, but the placement must follow the stacking logic.
  • discrete indicates the discrete layout mode in three dimensions. It imposes a cell-placement rule and a stacking logic.
  • block indicates the block layout mode in three dimensions. It imposes a block-placement rule and allows only artifacts whose volume in each dimension is exactly 1 or an integer to be placed in the scene.
  • slot indicates the slot layout mode. It allows artifacts to be placed only at specified slots with specified orientations.
  • flat-freeform indicates the freeform layout mode in two dimensions.
  • flat-continuous indicates the continuous layout mode in two dimensions.
  • flat-discrete indicates the discrete layout mode in two dimensions.
  • flat-block indicates the block layout mode in two dimensions.

The terms "cell-placement rule", "stacking logic", "block-placement rule", and "volume" will be defined throughout this section.

Other modules extending this module can define more LayoutMode values than those specified in this section. Implementations supporting the Layout Mode module MAY support only one or more of the layout modes. Implementations SHOULD state which layout modes are supported.

26.05.01 Reconstruction Logic

The reconstruction logic takes a Form with a specified layout mode and outputs a layout following the specified layout mode restrictions, derived from the original layout in Form. The output layout is then used to reconstruct the scene by placing each artifact in the output layout according to its placement as specified in the Embedding. The reconstruction logic therefore refers to how to produce a layout following the restrictions from the original layout.

30 Extension Specification

Extension Specifications define objects that represent users and their actions within the space, creating context for spaces and connections between users.

31 User and User Interface

/[TODO/]

A user is an being that must own or have access to an interface, and may have an inventory. Concretely, users include, but are not limited to, human beings, other intelligent beings, programs.

Interface

An interface is the input from a user to space and output to a user from space. The input from a user is a set of events that can trigger a set of corresponding functions known as interactions that changes the space. The output to a user is what user experienced from the space.

Camera

Each user may be associated with a camera. The camera can be moved in response to interface interactions and serves as the user’s primary visual viewport.

External interface

There are predefined sets of external interfaces commonly available on different platforms:

  • Desktop:
    • Mouse click (left or right) (at a place)
    • Mouse drag (along a path)
    • Keyboard input (with some characters)
  • Mobile:
    • Single tap and multi-tap (at places)
    • long tap (at a place)
    • Tap and drag (along a path)
    • On-screen keyboard input (with some characters)
  • System / Null users:
    • System interface: may monitor user-defined events occurring in the space or inventory as interfaces.
    • A null user is a system user that is implemented in a non-explicit way.

Avatar interface

The avatar interface has two layers: the control layer and the avatar layer.

The control layer is the external interface. When triggered, it calls an interaction function to control the avatar and perform a behavior.

The avatar’s behavior then acts as an interface in the avatar layer. Common behaviors include:

  • Moving (towards a direction or along a path)
  • Standing (at a location)
  • Engaging (with an object, self, or another avatar, may with options)

Inventory

An inventory is a list of items associated with a user. It represents the set of artifacts currently held by the user.

An inventory may include special slots that are monitored by system users. These are sometimes referred to as equipment slots or state slots.

In implementation, inventory elements may correspond to items or tokens stored in a user's wallet, or to contextual contents such as a backpack.

Item

Items are typically Artifact objects, but may be any object. They can also be monitored by system users.

32 Space

/[TODO/]

A space is the totality of what a user can experience. Concretely, a space can include the scene, its state, how it evolves and responds to user input, its recorded history, and any data stored within it along with how that data is presented.

In this section we define a few potential constituents of a space besides the scene. The constituents defined here should not be considered the only possible parts of a space beyond the scene.

State

A state of the scene is

UI Component

Interaction

Time

History

Background music and sounds effect

On this page