Our principles

1 Let worlds connect without losing their individuality

A game, museum, research station or landscape can be built with different tools and still have a common way to welcome visitors. Elsewhere defines that connection: how to discover a place, understand its meaning and participate with permission.

The protocol standardises communication between worlds. The people operating each region choose what it contains and how it works.

2 Each region decides what is true

A region is an independently addressable spatial environment. Its defining boundary is its authority, not a fixed plot size or a universal coordinate grid. Regions need not have finite geometric bounds.

Every authoritative region has one clear primary authority for its canonical state and outcomes. That authority may use several servers or delegate storage, media and simulation without making the trust boundary ambiguous.

Our hosted service uses bounded regions in a shared coordinate system. That is one implementation profile, not a requirement for every Elsewhere world.

3 A small manifest opens the door

A region manifest identifies the place, its authority, supported interfaces and entry information. Visitors discover further detail as they need it.

Interactive regions expose a logical MCP interface with readable instructions, resources and structured actions. Instructions explain the local rules and unusual concepts; they do not replace deterministic contracts where clients must agree.

4 Use the richest compatible description

Canonical facts, catalogue concepts and natural-language description work together. Facts establish what cannot be contradicted. Shared vocabulary gives recurring concepts stable names. Description carries the detail that a fixed schema cannot anticipate.

A client should use richer compatible meaning where it can, while respecting authoritative state. Unknown optional concepts should not prevent basic participation.

5 Ask the region; receive its answer

An entity can advertise capabilities such as opening, docking or an action invented for a particular game. A participant requests an action; the region authority applies permissions, state and local rules, then reports the outcome.

Simulation sits beneath that authority. A region may delegate it, but the protocol does not impose a competing universal simulation authority, one physics engine or one set of game mechanics.

Realtime connections may carry frequent updates. MCP provides discovery, resources and actions; it does not have to carry every frame.

6 Access belongs to the destination

The protocol does not require a universal user account. Each region decides which identities it trusts and who may observe, enter, inspect, interact, build, administer or subscribe to events.

Knowing an address or seeing an advertised capability grants no permission. Private information must be withheld by the authority, rather than sent to a client and hidden afterwards.

Our hosted service supports scoped credentials and building grants. These controls express local policy; other authorities can choose their own permission systems.

7 Choose how the place is experienced

A client may be a browser, game engine, VR experience, accessible text interface or autonomous agent. It chooses its controls and presentation while respecting the same accepted regional facts.

The protocol separates entity identity from representation. glTF and OpenUSD serve different asset workflows; clients use the formats they support. Our current browser supports glTF/GLB and procedural geometry, not every engine or format.

Detailed models, materials, textures and lighting determine visual quality. Blender can author those assets. Connecting a renderer alone does not turn simple geometry into a finished environment.

8 AI participates with permission

AI can help author assets, interpret descriptions or operate agents. It is optional, and reasoning does not confer authority.

An authorised authoring process can commit new facts. Runtime interpretation may enrich unspecified presentation, but must not silently rewrite canonical reality.

The hosted Blender connector can render a draft for review and export a model. The app’s standard AI build flow does not yet automate a full Blender, generated-texture and visual-review loop.

9 Follow links into independent worlds

A source region owns its link. The destination owns its state, entry rules and permissions. Linked regions may use different servers, engines, coordinates and physics.

A visitor follows the destination manifest, discovers supported interfaces and establishes the access needed there. Copying a model, referencing an object and transferring ownership or authority are distinct operations.

Our browser currently supports a manifest-based handoff to a destination’s browser entrance. Arbitrary engine negotiation and cross-authority object transfer are not implemented.

10 Let regions experiment

Economies, prices, avatars, inventories, combat systems and local rules belong to regions and profiles. The protocol should formalise a concept when recurring interoperability requires it.

Namespaced vocabulary, explicit versions and compatibility declarations let new ideas emerge without silently changing existing meanings. Hosted prices and service limits are operational choices.

11 The draft and the hosted service

The published specification is the Elsewhere v1.0 draft. Our hosted profile implements region manifests, MCP instructions and resources, visibility-filtered reads, permission-checked actions and region event replay.

Legacy API compatibility remains separate from the draft version. This is an evolving implementation, not a claim of complete v1.0 conformance. Service health checks show availability; they do not certify protocol coverage.