CYBERPLANETARY — EXPERIMENTAL PROTOCOL DRAFT v0.1

A proposed boundary between worlds

Protocol draft v0.1

A small vocabulary for describing a planet and offering a way in. Everything here is proposed and subject to revision.

Experimental draft · September 30, 2026.

This document does not establish implemented interoperability, certification, a central authority, or a production-ready standard.

Purpose & terms

Minimal descriptor

Entry & discovery

Optional extensions

Boundaries & questions

Draft downloads

Purpose and terms

The proposal starts with independently hosted planets. Their internal implementation, institutions, and residents can differ. A shared description should help a visitor understand what a world claims to be and where its public entry point is.

Planet:

an independently operated digital world with a public description and an entry point. A logical world does not imply a dedicated physical machine.

Cell:

a place, community, organization, or activity within a planet. Cells may have their own operators and implementations. Their boundaries and relationships are defined locally.

Index:

an independently maintained selection of planet descriptions. Any number of indexes may coexist; none is required for direct entry.

These terms are a working vocabulary. Planets and cells can have overlapping relationships rather than forming one fixed hierarchy.

A minimal public descriptor

Draft v0.1 proposes four fields: a draft version, a stable operator-chosen identifier, a human-readable name, and at least one entry link. A short description and namespaced extensions are optional.

Field

Proposed meaning

protocol

The proposal version, currently

cyberplanetary-draft/0.1

.

id

An operator-controlled HTTPS URL intended as a stable reference. It is not a global registration or identity guarantee.

name

The name displayed to visitors.

entries

One or more labeled HTTPS entry links, with an optional interface type.

description

Optional context for visitors.

extensions

Optional capability information under operator-controlled URL keys.

Illustrative example — not a live planet

The deliberately invalid domain below is example data. It is not an operational demonstration or directory entry.

{
  "protocol": "cyberplanetary-draft/0.1",
  "id": "https://planet.example.invalid/",
  "name": "Illustrative planet",
  "description": "Example data only; no live service.",
  "entries": [
    {
      "label": "Enter the world",
      "url": "https://planet.example.invalid/enter",
      "interface": "web"
    }
  ]
}

An operator could publish this JSON at a documented URL on its own host. This draft does not yet reserve a discovery path or define a federation transport. The

proposed JSON schema

expresses a starting shape, not proof of a planet’s availability or trustworthiness.

Entry and discovery

An operator publishes a public descriptor and documents its location.

A visitor obtains that description directly or through an index of their choice.

The visitor follows an entry link and encounters the destination’s own interface, participation requirements, and local rules.

At this stage, travel is a metaphor for following a link. There is no implied transfer of identity, possessions, memory, money, software, or authorization between worlds.

Indexes may curate, rank, annotate, or omit planets according to their own published policies. Listings can overlap. An index is a perspective, not a mandatory gateway or a global registry.

The

initial directory

publishes an empty portable catalog using a separate proposed catalog shape. It has no live planet entries and is not a reference implementation of federation.

Optional compatibility profiles

Future profiles could describe capabilities such as interactive interfaces, resident identity handoffs, cell discovery, or exchange of selected state. A planet may choose to support one, several, or none.

Before any profile becomes meaningful, its participants need explicit semantics, versioning, consent rules, security review, failure behavior, and working implementations. A capability claim in a descriptor alone cannot establish compatibility.

Extensions should use operator-controlled URL keys to reduce naming collisions. Unknown extensions should not prevent a reader from displaying the basic description and entry links. No extension profile is defined as implemented by this release.

Boundaries and open questions

Planets retain control over governance, economies, compute resources, admission, and internal architecture. A public descriptor is a claim by its publisher; it is not a security assessment or an endorsement.

How should descriptions express ownership, authenticity, changes of operator, and withdrawn entries?

How should indexes distinguish verified availability from self-reported capabilities?

How can cells be described without forcing one hierarchy or exposing private residents?

What consent and security guarantees would richer travel require, especially for artificial residents?

How should profiles handle disagreement, version changes, and incompatible local rules?

Public descriptions should contain public information only. Credentials, private resident data, and internal service endpoints do not belong in a public descriptor.

Draft materials

These files are portable proposal materials, not promises that another system implements them.

Proposed descriptor schema · JSON

Protocol draft v0.1 · Plain text

Initial empty catalog · JSON