# Cyberplanetary
## Mission and Specification Charter

**Founding draft · 1 October 2026 · English**  
**Document revision:** 0.2  
**Status:** Revised charter for publication review. The vision and mission reflect the agreed wording; adoption of the full charter remains pending.  
**Semantic basis:** *Cyberplanetary concept system and ontology*, version 0.1.0.

This is a charter for Cyberplanetary's specification work. It states the vision and mission, and defines the subject, boundaries, and authoring commitments of that work. It is not a wire-protocol specification, an application design, a service agreement, or a constitution for the worlds described through it.

This draft begins a new specification baseline. Earlier website content, experimental protocol drafts, implementation assumptions, and proposed worlds are historical exploration only. None is retained merely because it already exists. No backward-compatibility or migration requirement is inherited from that work.

---

## 1. Vision and mission

### 1.1 Vision

> **A future where everyone has the freedom and the means to choose and shape their experiences with technology on their own terms.**

### 1.2 Mission

> **To expand human freedom and choice by lowering the cost and friction of creating experiences with technology, enabling reuse, and putting discovery in people’s hands.**

We pursue this through **open protocols, reusable profiles, and free, open-source catalog software that anyone can run**. Developers can build on one another’s work without all building the same kind of world. More ideas become practical to create, and useful work becomes a foundation for what comes next.

Discovery belongs in that same circle of freedom. People can choose a catalog, turn to another, or run their own. No single catalog, platform, or feed should be the compulsory gateway through which every experience must be found. The freedom includes choosing how to look—not merely choosing among what someone else has decided to show.

That is the **freedom machine**: a shared foundation for expanding what people can experience, without prescribing what those experiences must be.

**More possibilities within reach. The choice of where to go remains yours.**

### 1.3 The specification’s contribution

Cyberplanetary exists so that developers can build on a shared, intelligible foundation without joining one platform. A developer should be able to describe a world, a catalog operator should be able to maintain a collection, and an implementer should be able to interpret the resulting information using the published specification.

Cyberplanetary provides an open specification for world registration and discovery, with a basis for developing voluntary profiles.

Success is independent use. Adoption need not produce an account, a submission to Cyberplanetary's own catalog, a contribution to its code, or a commercial relationship with its operator.

## 2. What Cyberplanetary is defining

Cyberplanetary is developing a small family of specifications, beginning with a **core protocol specification** provisionally titled:

> **Cyberplanetary — World Registration and Discovery**

The core defines exchanged registration information, catalog records, and the rules needed to interpret those exchanges. It addresses signed registration statements, attribution, world references, optional profile support claims, and the separation between a registrant's material and a catalog's own records and annotations.

**Profiles** define additional, bounded agreements by selecting, constraining, extending, or combining identified base specifications. Where an agreement requires new messages or interactions, those interactions need an actual protocol specification; a profile name cannot supply them.

The protocol family is not a hosted service. A website can publish it; software can implement it; a catalog can use it. Those are separate things. Cyberplanetary's own catalog will be one implementation, not the source of protocol-wide authority.

The ultimate beneficiaries are the people who use what gets built. The direct audience for the specification includes individual developers, technically sophisticated users acting as developers, independent operators, and commercial organizations. The core is not tied to one application audience or business model.

## 3. The subject of registration

The concept system defines a **world** as:

> resource conceived as a digital environment or body of digital content and treated as a unit for independent identification and description

This is the subject of a registration statement, not a minimum feature list for an application.

A world may be static or dynamic, semantic or geometric, actual or planned. A simple website, data table, collection of three-dimensional assets, or simulated environment can fall within that description. A world need not contain artificial people, avatars, language models, cells, a live endpoint, or persistent simulated state.

**World** is the general term. **Planet** is not the general technical designation; particular worlds can still be planetary.

A **cell**, where offered, is a place, allocation, or unit defined within a world for its users. It is a contextual component, not a kind of world. Nothing here requires a lattice, fixed dimensions, permanent cells, exclusive ownership, or a server per cell. Cell addressing and resolution are outside the core.

Developer, user, registrant, and operator are overlapping roles, not mutually exclusive populations. One person or organization can occupy several roles. The protocol does not require a common runtime or make an implementation, a machine, and a world the same thing.

## 4. The semantic contract

The following distinctions govern specification authoring. They do not prescribe a serialization, one object per API endpoint, or a separate running component for every concept.

### 4.1 A world is not the information describing it

| Concept | What is being distinguished |
|---|---|
| **World** | The actual or planned subject being referred to. |
| **World registration statement** | Attributable information identifying and describing that subject for publication or catalog entry. |
| **Signed registration statement** | The information artifact carrying a representation of that statement and supplied signature material. |
| **Submission** | Input received or retained for catalog consideration, including opaque or malformed input. |
| **Catalog record** | The record documenting a submission or listing in one particular catalog. |

Signing and publication can occur before any catalog records a submission. **World registration** is the catalog-local recording activity; it is not synonymous with signing, publication, approval, or global name allocation.

Two catalogs can keep the same signed material in separate local records. They can annotate it differently. Removing one record does not remove the other or revoke the described world.

An artifact carrying a signature is not thereby an artifact whose signature has been successfully verified. A malformed submission need not be represented as an interpretable signed registration statement in order to be retained.

### 4.2 Attribution is not truth

Registrant assertions remain attributable assertions. Catalog annotations remain separately attributable annotations. Neither becomes an objective fact about a world merely because it appears in a catalog or bears a signature.

An **assessment report** describes an assessor's result for a specified target, method, and time. A **signature verification report** concerns a signed artifact and a verification key. A **conformity assessment report** concerns a target and the requirements of an identified profile version.

Those reports can report failure or uncertainty. A report can itself be inaccurate. The act of carrying it is not the act of performing or endorsing its assessment.

Consequently, the core keeps distinct: receipt, retention, structural interpretation, cryptographic verification, claimed profile support, conformity assessment, demonstrated interoperability, and permission to proceed. There is no universal “verified world” status combining them.

### 4.3 Identity, location, and content integrity have different jobs

A world identifier refers to a world. A key identifier identifies or selects a key. A display name is presentation text. A location reference indicates where a request may be attempted. An entry reference supplies a possible means of encounter. A content hash concerns particular bytes under a specified hash function.

Equal display names, locations, key references, or content hashes do not independently establish that two statements concern the same world. Nor does a different value, by itself, establish that the worlds are different. The eventual protocol must state any identity criteria it actually adopts.

Key-based registration is the intended direction, not a completed identifier construction. The design must account for one key making statements about multiple worlds without treating the key itself as every world's identifier.

Successful digital signature verification establishes a result relative to protected input and a key. It does not prove organizational identity, authority over every world named, truthfulness, availability, general trustworthiness, or conformity.

## 5. The core work

The core specification is to make the registration boundary usable by independent implementations. Its responsibilities are bounded but real.

**Registration information.** Define how a world registration statement is represented and interpreted, including its subject, attribution, references, and optional claims. Define the minimum required information deliberately rather than copying every property from the ontology into the wire format.

**Signed artifacts.** Specify the protected input, public-key representation or reference, permitted cryptographic mechanism, and verification processing. Private keys are never submitted. Preserve the difference between supplied signature material, a verification attempt, and its result.

**Catalog exchange.** Specify how catalog records, retained submissions, registrant material, and catalog annotations are represented and exchanged. A record's local context and the source of assertions must remain distinguishable. Catalog exchange does not require catalog synchronization or a shared authoritative database.

**Profile claims.** Specify how an attributed claim identifies its target and an identified profile version, with the scope needed to interpret the claim. The target may be a world or a particular implementation. A reader need not retrieve or implement an unknown external profile merely to retain its reference.

**Versioning and processing boundaries.** Specify supported versions, update interpretation, and unknown-metadata behavior at the actual exchange boundary. Descriptive extensibility must not silently alter base meanings, authorize an operation, or override critical cryptographic processing.

The publication and retrieval baseline uses ordinary web infrastructure. It does not require a Cyberplanetary-specific world-server process, proof-of-work registration, a live world destination, or new routing infrastructure.

Content addressing may identify particular material. It is not a commitment to hashing an entire running world or operating a distributed storage network. Likewise, a fresh cached response says something about the response's reuse conditions, not that its described world is running.

These responsibilities concern interpretation of exchanged material. They do not establish service availability, a guarantee of truthful claims, or a requirement for every catalog to perform every available assessment.

## 6. Independent catalogs and local registration

World catalog names the collection. A registration service is a separately offered function.

Catalog operators choose their inclusion, exclusion, retention, pricing, ranking, presentation, and investigation policies. They may specialize in particular profiles, technologies, developers, signing keys, or application families. They may retain planned, unavailable, stale, disputed, or malformed submissions. They may perform extensive assessments or none.

This discretion does not make the protocol meaningless:

> **Local policy decides what a catalog keeps or does. The shared specification makes interpretable what its records say.**

A catalog may retain a failed signature without representing it as successful verification. It may add a continuity annotation without manufacturing a signature from a previous key. It may illustrate a semantic world as a cloud without making that illustration the world's own geometry.

No catalog is compulsory. A registration statement can be published and consumed directly without being recorded in any catalog. No shared reputation system, global registration approval, protocol-wide display-name reservation, or globally authoritative catalog is established. Registrar-like services, when offered, have their stated local scope.

The reference catalog gains no special protocol authority from being hosted at the project's domain. Adoption can take place entirely outside it.

## 7. Profiles and additional interoperability

A **profile** defines an additional, bounded agreement.

In this project, a profile is requirements-bearing. It identifies its bounded function and base specifications. Its requirements preserve the applicable requirements of the specifications it profiles. A supporting dependency is not automatically a profiled base, and a contradiction of a base cannot be hidden by calling it an extension.

A profile can use specifications other than the Cyberplanetary core. New interactions need specified messages and processing rules, whether supplied by a base or by a separately defined protocol. A topic, label, or URI without those requirements is not a completed profile.

A world or implementation may advertise no profiles, one profile, or several. A profile version identifies an edition of requirements, not an implementation's software release. Merely listing several profile versions does not establish that they compose correctly, that another implementation can use them, or that any interaction is authorized.

Profile authors are free to publish independent work. The project will begin a small set of profiles informed by its initial use contexts. Candidate development areas remain cells and internal addressing, geometry, avatars, artificial people, resource sharing, and economic arrangements. They are neither six completed profiles nor a final taxonomy.

Selecting a profile does not make every world adopt its subject matter. A geometry profile does not require geometry of all registrations. An artificial-person profile does not own the category of artificial-person applications. An economic profile does not establish a universal economy.

## 8. What remains outside this work

The core does not define world-internal ontologies, geometry, cells, physics, state transitions, resident behavior, cognitive architectures, histories, or persistence of simulated activity. It does not assign who wins a conflict within a world.

Application design and implementation are outside the scope of this specification work. Interfaces, policies, membership rules, guarantees, subscriptions, contributions, and economic systems remain application-level decisions.

It does not create a game engine, viewer, messaging replacement, universal SDK, language-model service, consensus network, storage network, blockchain, or alternative Internet infrastructure. Protocol examples and test utilities do not become mandatory runtime dependencies.

It does not establish real-world identity certification, a global naming tribunal, a reputation system, a universal admission policy, or a guarantee of beneficial use. It does not require all worlds to be open source. The previously chosen AGPL direction for project software is retained without turning software licensing into a world-registration eligibility rule.

Initial core work excludes key-recovery, key-rotation and revocation services, and guaranteed continuity after key loss. This exclusion does not excuse ambiguity about signed material, revisions, or replay in the protocol we do specify.

Some excluded subjects can receive bounded treatment in voluntary profiles. That does not expand the core automatically. Conversely, protecting the integrity and interpretation of core exchanges is within scope even though application-level privacy and world governance are not.

## 9. The role of the concept system

Version 0.1.0 of the concept system is the semantic basis of this draft. Its terminology and distinctions are used intentionally. Owner adoption of the complete concept system remains pending.

The ontology is **of registration and discovery**, not of the worlds being discovered. Its concept identifiers, formal symbols, and proposed namespace are not themselves deployed services.

The editable concept model, generated vocabulary, authored ontology, and proposed data constraints have different purposes. None is automatically a mandatory wire format. The data constraints describe a particular semantic exchange view, not a set of core fields already approved for every publisher. Forty-nine concepts do not mean forty-nine required fields, endpoints, or processes.

Each external dependency used in the technical specification is to be identified by edition and role, with any adaptation stated explicitly.

The proposed authoring chain is:

> **Project purpose → concept and boundary → selected source provision → protocol requirement → executable example or test.**

That chain is an authoring discipline, not a new requirement on every developer's application.

## 10. From this foundation to an implementable specification

This charter settles the purpose and semantic boundaries of the work. The following decisions belong in the first technical specification; they are not already answered by the ontology.

| Specification work | Required precision before claiming that exchange is specified |
|---|---|
| **Representation and signatures** | Serialization, protected bytes, signature mechanism, public-key representation, and preservation of the signed material. |
| **World references** | Identifier construction and comparison, including multiple worlds per key; distinctions from locations, labels, and content hashes. |
| **Statements and revisions** | Update and replay handling, revision interpretation, conflicting statements, and any limits on continuity or precedence. |
| **Publication and catalog exchange** | Concrete web representations and processing rules, including which interactions the protocol specifies and which service operations remain local. |
| **Profiles and extensions** | Profile-version references, target and scope, dependencies, unsupported versions, optional metadata, and critical processing. |
| **Conformity and test evidence** | The target of each requirement, permitted outcomes, failure classifications, and executable examples and cryptographic test vectors. |

These are engineering obligations for protocol authors, not a new application questionnaire. An intentionally unsupported operation should be stated as unsupported, not left ambiguous.

The first specification's examples and tests should preserve the supplied boundary cases: a world without cells or entry references; opaque retained input; a failed signature that remains cataloged; one agent in several roles; one statement in two independent catalogs; multiple and unknown profile claims; matching labels or keys without an automatic identity merge; and local removal without global revocation.

A syntactically acceptable message, a successful signature check, a reported assessment, actual conformity, and an authorized interoperable exchange are distinct outcomes. Test evidence must identify which one it addresses.

The publication will be ready to serve as an implementation target when its in-scope messages and processing rules are sufficiently specified for independently written implementations to be compared. That is a proposed criterion for the specification's usefulness, not a certification service or an availability guarantee.

## 11. The new baseline

The project now proceeds from this mission, the clarified scope, and the supplied semantic basis—not from the old website's field list.

The founding charter determines what work belongs here. The concept system supplies meanings and relationships. The core protocol specification determines messages and processing. Profiles determine additional bounded agreements. Implementations realize those agreements. Catalog operators select and present records.

The website publishes this work; it does not define it by precedent.

**Shared meaning at the registration and discovery boundary. Independent decisions within the worlds.**