# Manifold Standard Version: 0.1.1 ### 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](http://extspace.net). 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. ### 01 Table of Content This table of contents is provided as a guide for navigating this document. It does not list all the subsections, but only lists sections to a manageable depth for navigation. - [[00-Manifold-Standard]] - [[01-Table-of-Content]] - [[02-Copyright-Notice]] - [[03-Conventions]] - [[04-Version-Control]] - [[05-Conformance-Profile]] - [[10-Introduction]] - [[11-Scope-and-Structure]] ### 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](https://datatracker.ietf.org/doc/html/bcp14) [RFC2119](https://datatracker.ietf.org/doc/html/rfc2119) [RFC8174](https://datatracker.ietf.org/doc/html/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](https://datatracker.ietf.org/doc/html/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 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](https://datatracker.ietf.org/doc/html/rfc7946). ### 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