The UNAVI Vision

This document outlines the philosophical foundation, aesthetic principles, and strategic direction of UNAVI and The Wired.

What is UNAVI?

UNAVI is an open-source spatial browser — a gateway to three-dimensional hypermedia. It is built primarily in Rust using the Bevy engine, and serves as a reference implementation of The Wired protocol.

A space in UNAVI is a 3D hyperdocument. It can contain objects, portals, and behaviors, all expressed through open formats and standard scripting APIs. Spaces can be created, viewed, and hosted by anyone.

UNAVI is not a walled garden. It provides the foundation for an open, interoperable ecosystem where identities, spaces, and objects operate under shared standards rather than centralized control.

What is The Wired?

The Wired is the spatial hypermedia layer of the Internet — an open protocol for representing and linking shared 3D environments. It defines how spaces, objects, and agents interoperate across peers.

The Wired is also a philosophy: information systems should reflect the natural order of the human experience. Traditional digital interfaces flatten information into screens and feeds, but humans evolved as spatial beings. As feng shui teaches, form and life are inseparable.

The Wired restores spatial structure to digital information.

Spatial Continuity

A defining aspect of The Wired is seamless spatial continuity. Spaces are independent hyperdocuments, but they can be linked together through portals without interruption of presence or state. Moving between spaces does not require reloading, respawning, or resetting context; the transition is treated as a continuation of the same session.

This design allows The Wired to function more like a network of physical environments than a collection of separate applications. Users can navigate across different spaces while maintaining the same identity, objects, and interaction model.

Creation and Autopoiesis

At the heart of The Wired is a computation layer powered by WebAssembly. Its goal is autopoiesis: systems that define and maintain their own behavior through internal logic.

A space is a self-contained hyperdocument. Its layout, rules, and behaviors live inside the space itself. Objects also embed their own logic and state, allowing them to operate predictably in any environment.

Autopoiesis does not imply isolation. Objects can still react to and communicate with their surroundings through explicit interfaces. A lamp keeps its lighting logic but may respond to ambient brightness or signals from nearby devices.

Autopoiesis gives The Wired a consistent, interoperable foundation.

The Vision

UNAVI exists to give form to The Wired — to make spatial hypermedia usable, open, and accessible. For decades, the web has been a network of text and images. It is expressive, but fundamentally two-dimensional. People, however, perceive and understand information through spatial relationships. Presence, distance, orientation, and shared environments all influence how we think and communicate.

UNAVI’s goal is to reintroduce these spatial qualities into digital life. This is not about simulation or escapism; it is about creating interfaces that align with how people actually understand the world.

When information lives in space, it becomes clearer, more navigable, and more concrete. The Wired extends the Internet into the form it was always meant to take.

Principles

The Wired, expressed through UNAVI, should be:

Open — Based on transparent standards.
Interoperable — Objects, identities, and spaces move freely across peers.
User-sovereign — Users own their data and decide where it is stored.
Generative — Systems should support internal growth and adaptation.
Human-centered — Interfaces should reinforce presence, clarity, and meaningful interaction.

The Wired Manifesto

The true form of the Internet already exists.
We need only to let it express itself.

UNAVI is the first step toward making that form visible and inhabitable.

Architecture

The Wired is built in three layers, each serving a distinct role.

Social — who you are. Decentralized identity that you own and carry across every space you visit.

Data — what you own. Personal storage for your spaces, objects, and files, synchronized peer-to-peer without central servers.

Spatial — where you go. The format for 3D environments and the objects within them, scriptable and composable like web pages.

These layers are designed to be independent. You can use your identity without hosting any data. You can host data without running a space. Each piece stands on its own.

Identity

In The Wired, your identity is yours — not issued by a platform and not revocable by one. It is a cryptographic key pair you hold, expressed as a Decentralized Identifier (DID).

Your DID works anywhere in The Wired. You can take it to a different space, a different server, or a different client. No one can take it from you.

Two forms

did:key — generated entirely from a cryptographic key. No server or domain required. Portable and self-contained, but cannot be rotated if the key is lost.

did:web — tied to a domain you control. More recoverable, and can advertise services (like your data store) through standard web infrastructure.

What it enables

Your DID signs the data you create, proving authorship. It controls access to your records, granting read or write permissions to others by their DID. It points to your data store so others can find and sync with you.

One identifier — ownership, verification, and discovery.

Data Store

Your Wired Data Store (WDS) is your personal storage — the place where your spaces, objects, and files live. You can run it on your own machine, on a server you control, or let someone else host it for you.

Data stored in a WDS belongs to you. Your identity controls who can read or write to it. If you move to a different server, your data comes with you.

Sync

WDS instances sync with each other directly, peer-to-peer. When you edit an object, the changes propagate to anyone subscribed to it — no central intermediary required.

Sync is conflict-free: edits from multiple people merge automatically. There is no “latest version wins” — all contributions are preserved and combined.

Offline

A WDS can run locally on your device. Edits you make offline are queued and sync when you reconnect. The local instance also caches data from spaces you visit, so they load faster next time.

Records

A record is the basic unit of data in The Wired — a structured document with a stable identity, access control, and automatic conflict resolution.

Spaces, objects, and schemas are all records. They live in your data store, addressed by a unique ID derived from when they were created.

Ownership and access

Every record has an access list. The creator starts as manager and can grant others the ability to read, write, or manage the record. Permissions are part of the record itself, not stored on a server.

Collaborative editing

Records use CRDTs (conflict-free replicated data types) for their contents. Multiple people can edit the same record simultaneously. Changes merge automatically without conflicts, making real-time and offline collaboration both reliable by default.

History

Changes to a record are tracked as signed, incremental updates. Each update is authored by a DID and timestamped. This creates an auditable trail of who changed what, and enables sync between data stores.

Blobs

Blobs are the binary assets of The Wired — 3D models, textures, audio, scripts, avatars. Unlike records, blobs are immutable: their identity is the hash of their contents, so they never change.

This has useful properties. The same asset referenced from two different spaces is stored once. You can verify the integrity of any asset by checking its hash. And because the hash is the identity, anyone with the hash can fetch the asset from any data store that has it.

Blobs are referenced from records — an object record points to the blob hashes of its mesh geometry, textures, and scripts. The record changes (permissions, metadata, placement); the blobs stay fixed.

Schemas

A schema defines what a record is allowed to contain — its fields, their types, and who can change them. Schemas make records predictable: any client that knows a schema can read and write records conforming to it, regardless of who created them.

Schemas are stored as blobs and referenced by hash. Because blobs are immutable, a schema never changes after it is published. Records reference the exact schema they were built against.

Field types

Schemas support the usual primitives (strings, numbers, booleans, bytes) as well as structured containers: lists, maps, and trees. Fields can be marked optional, and individual fields can have their own access restrictions — for example, a field that anyone can read but only the owner can write.

Interoperability

Shared schemas are how different clients and spaces understand each other’s data. A space schema defines what an environment looks like. An avatar schema defines how a character is described. Applications that agree on a schema can work with each other’s records without coordination.

Objects

A HyperSpace Document (HSD) is the spatial equivalent of a web page — a self-contained 3D object with its own geometry, appearance, physics, and behavior. It is stored as a record and can be placed into any space.

Like a web page, an HSD can be authored by anyone and hosted anywhere. Unlike a web page, it carries its own behavior with it. An object does not depend on the space it is in to function.

Structure

An HSD describes a hierarchy of nodes — the parts that make up the object. Each node can have a position, a mesh (its geometry), a material (its appearance), physics properties, and scripts that define its behavior.

Meshes and textures are stored as blobs, separate from the record itself. This keeps the document light while allowing heavy assets to be cached and reused.

Behavior

Scripts are WebAssembly components embedded in the HSD. They run when the object is loaded into a space, letting objects animate, respond to interaction, and communicate with their environment through defined interfaces.

Because scripts are part of the object — not the space — their behavior is consistent wherever the object appears.

Collaboration

HSDs use the same CRDT system as all records. Multiple people can edit an object simultaneously. The object’s owner controls who has write access.

Spaces

A space is a shared 3D environment — a place where multiple objects coexist, interact, and are experienced together. Spaces are addressed by a URL derived from your identity, making them linkable and navigable like web pages.

Each object in a space has its own owner. A space is not a monolith — it is a collection of independently owned objects that happen to share a coordinate system. The space owner controls what is placed there; each object’s owner controls the object itself.

Portals connect spaces together. Walking through a portal takes you into another space, seamlessly. Your identity, objects, and session carry across. Portals are spatial hyperlinks.

Slots let spaces embed other spaces within them. The embedded space appears as a region inside the parent, with its own objects and behavior, scoped by where the slot is placed.

Entering a space

When you open a space, the client fetches its record, discovers the objects listed in it, and loads each one from its data store. From that point, physics, scripting, and rendering run locally. Changes you make sync back to the relevant stores.

Spaces are not streamed from a server — they are assembled from distributed sources and simulated on your device.

Scripts

Objects in The Wired can carry behavior with them in the form of WebAssembly scripts. These scripts run when an object is loaded into a space, animating it, responding to interaction, and communicating with its environment.

Scripts are sandboxed. They can only interact with the scene through defined interfaces — creating and moving nodes, reading physics state, responding to events. They cannot access the network or the filesystem arbitrarily.

UNAVI Docs