Say a peer is working on an app you’ve been helping with. You know which machine holds it. What you want to find is the place they’re working, what they’ve chosen to show you, and whether there’s something you can help with.

That’s the idea behind traversing the network spatially. A place can lead you to the preview a peer is testing or the room where people have gathered. Moving through it gives you a sense of how those things relate and a way to find your way back.

Traverse the networkA spatial map routes a visitor to terminal worlds and canvas spaces owned by peers.Traverse the networkYour workspacePaired peer identitySpatial mapPublished placesCellar DoorAuthored terminal worldCherrytopPeer’s canvas space PEER A · HOST AUTHORITYPEER B · HOST AUTHORITYDiscover → request access
Each host decides what is visible and what visitors may open.

Two ways to enter

Cellar Door starts with authored terminal worlds. A door leads to a scene. The author decides what the visitor encounters along the way. Cherrytop’s canvas starts with a working desktop. A peer might arrange windows and widgets around a task, then share a view of that place.

These are two experiments in navigation. One makes the journey through a world part of the experience. The other gives people a place to see work in context. They can inform each other without requiring a terminal world and a browser canvas to have the same layout or controls.

A visit that would be worth making

Imagine a collaborator has an app running on their machine and wants another pair of eyes on its layout. They share a place with the preview and a short note about the issue. You see that place on your map, enter it and open the preview. The host might also offer a view of the running terminal. Editing the app would require a separate grant.

The same map might lead somewhere with no task attached. A peer can open a Cellar Door world for people to visit. You enter through its doorway and follow the paths its author laid out. A useful map needs to describe enough about a destination for you to choose whether to go, then let the destination set the terms of the visit.

Finding your way back

A spatial interface needs to handle an ordinary network failure: the place is familiar, but the host is offline. A remembered place should keep its name and location and say when it was last seen. The map should make an unavailable preview distinguishable from one that’s running. If the host returns, a visitor can ask to enter again using the host’s current grants.

Discovery also needs to respect what a peer meant to share. A public room title, a presence count and a live terminal view reveal different things. The design needs a way to publish those independently. Someone may want visitors to find the room without advertising who is inside it.

Durability across the network starts with knowing what survived an interruption. A remembered place can still be useful when its host is away. Conduit keeps offers and replies in durable outboxes and inboxes, with receipts that record their progress. When the host returns, Sakura can reconnect a client to an available terminal run. Each gives you a different way to pick up where you left off.

What you can see when you arrive

A peer can share a running preview or an open question. The map helps you find that work and open a view your grant allows. Read its availability before you enter. A remembered place may still appear when its host is offline.

Pairing and scoped sharing give us a starting point. The peer keeps authority over what it offers. A place on a map can give you a route to a resource. The host decides whether you can view or act on it.

P2P connects paired workspaces. SSH gives you another route to a host that offers it. When a destination opens a running terminal, Sakura handles the session: attach, receive a snapshot, follow the stream and send input if permitted. If you reconnect, you attach to the host’s run again. Conduit handles offers and replies separately, with receipts that survive the connection that carried them.