kino://user@realm/path

Realms

One system across users and machines. A Realm holds identities and documents and answers for an address. Realms exchange signed commits store-and-forward, so laptops sleep, shares wait, and many machines read as one tree. This is the design the next layers are built to.

One address, all the way down

Everything on this site so far is one file on one machine. Realms extend the same idea across users and machines. A Realm is an authority: it knows its users, holds their documents, and answers for an address. The address is:

kino://user@realm/path

kino://dy@kinogaki.com/projects/light/scene/world/lens.radius reaches from the public network, through a user's tree, into a document, down to a single value. The Path that addresses an Element inside a Document simply keeps going — up through the filesystem, up through the network. Kinogaki's promise is a file that opens all the way down; a Realm is the network opening all the way down to the file.

This page is the forward path: the design the next layers are being built to. The pages before it describe what runs today, and every piece here stands on one of them.

The filesystem is a Document

A Realm's storage is a Prism Document: a tree of typed Elements whose leaves hold documents. A directory is an Element. A listing is a Document. Users, groups, grants, and mounts live under /sys as Elements like any others. That one decision collapses the operating system into a handful of Prism programs:

• Storage is a daemon that owns a tree of documents and serves it.
• Auth is Elements describing principals, plus a signature check on every request.
• The terminal is a server-driven-UI client whose commands are verbs over the tree.

Browsing the filesystem, watching a directory change, editing a shared document — all of it is the loop and the wire this site already describes, pointed at a bigger tree.

Canonical names, personal views

Every node has one canonical address — kino://user@realm/path — and that is what links, shares, and cross-machine references store. What a user works in is a namespace: their own tree, with other people's subtrees mounted wherever they like. Mount your collaborator's exports at /assets and work there; the link you save still records the canonical address, so it survives any remount. Identity is global; the view is personal. Users see their own portion of a monolithic system because the namespace itself is per-user — visibility is structure, with access control behind it.

The journal

Every mutation is a commit: signed by its author, chained to its parent, carrying a Prism diff as payload. The state of a volume is the fold of its journal. A commit is data, so a batch of commits is a file — and that makes the whole synchronization story portable: anything that moves a file moves the system. HTTP between realms, or a USB stick, with equal correctness.

Sync is store-and-forward

Realms exchange commit bundles asynchronously, the way FidoNet moved mail between machines that dialed each other at night. The topology comes with it:

• A point is a Realm on a machine that sleeps — a laptop. It polls its always-on boss Realm when it wakes, sending its outbound commits and collecting what arrived while it was closed.
• A direct share addresses commits to one user at another Realm.
• An echo is a subtree many Realms subscribe to — a team's project, a public gallery, an issue board. Commits to an echo flood to every subscriber through its home Realm.
• The tosser is the sync worker: it scans the journal for outbound commits per subscription, packs bundles, and applies inbound ones.

A Realm accepts a commit only when the signature is valid and the author holds a write grant on that subtree. A bundle from one user reaches exactly what that user may touch, whichever Realm forwarded it.

Live connections still exist — a mounted subtree over a socket is the same subscription the SDUI loop runs today. Async is the backbone; live is the special case for when both ends are awake.

Sharing: grants inside, capabilities across

Inside a Realm, sharing is a grant: an Element under /sys/grants naming a principal, a subtree, and a right (read, write, share). Grants are documents, so "everything I've shared" is a query and the answer renders like anything else.

Across Realms — where two machines share no authority — a share is a capability: a signed token minted by the granting Realm that is the access. Hand someone the link and they can mount it; the interior ACL machinery never needs to federate. Revocation is the minting Realm's ledger.

A user is a name and a keypair. Sessions ride the same per-client channel the wire already carries. Passwords, magic links, and federated identity are bindings a Realm may add on top; the interior model never changes.

Conflicts keep both

Two points edit the same document offline; their bundles cross. Element-Path identity merges almost all of it — concurrent edits to different Elements are independent commits, and that is the overwhelming case. When two commits touch the same slot, the fold keeps both as sibling versions, picks one deterministically as current, and marks the Element diverged, so the terminal and every UI can show the fork and offer the pick. A signed commit is never dropped.

The terminal

The terminal is a Prism shell: whoami, ls, open, share /projects/pixel with alice, mount kino://bob@studio/exports/assets /assets, poll, useradd. Its output is Documents, and the stack renders Documents — so ls yields a live, clickable listing that updates when the directory changes, because it is a subscription like any other. It is an SDUI app, so the same terminal runs in a native window and in the browser.

Kinogaki runs Realm nodes

A network of machines that sleep needs machines that don't. Kinogaki operates always-on Realm nodes, and a hosted Realm gives a user four things a laptop can't:

• Presence. Shares and echo traffic addressed to you land at your boss Realm and wait. You poll when you open the lid.
• A permanent address. kino://you@kinogaki.com/... outlives your hardware. A new machine is a new point: mint a key, poll, and everything comes back.
• Durability. The hosted Realm is the replica that is backed up.
• The web, for free. A Realm speaks the wire, and the wire renders in a browser — so every document in a hosted Realm has a URL. Publishing is a grant to public.

The protocol is signed bundles, so anyone can run a Realm on their own domain and federate — the email model, and FidoNet's. Kinogaki is the best-run node on the network, never the gatekeeper.

The layers

Four new pieces carry the design, each resting on the libraries below it:

• kinogaki-auth — principals, keys, tokens, grants. A library and a small Realm service.
• kinogaki-storage — the volume, the namespace, the journal, the tosser. A library and the daemon.
• kinogaki-os — the thin seam every app talks to: a Session that answers who am I, what is my namespace, and opens, watches, writes, mounts, and resolves kino:// addresses. Auth and storage composed into one ambient environment — the libc of the system.
• The terminal — the first app on Session, and the face of the whole thing.

Storage and auth sit above Core and the network layer, beside Platform rather than inside it: Platform owns the machine, Realms own the world.