---
title: "Why do I get lost on my computer?"
code: "RP-0106"
language: "en"
canonical: "https://regentspark.ai/RP-0106/"
html: "https://regentspark.ai/RP-0106/"
markdown: "https://regentspark.ai/RP-0106.md"
updated: "4 April 2026"
---
# Spaces as Namespaces
*From security isolation to cognitive scoping*
> **Summary:** You walk into your kitchen — you see the kitchen. Not your bedroom, not your office. Physical rooms scope your experience by hiding what's outside. Computers don't do this. Every file, every app, every project exists everywhere, all the time. But computing HAS built rooms — remarkable ones. Containers, sandboxes, and virtual environments create scoped realities where the outside simply doesn't exist. Thirty years of extraordinary engineering, all motivated by security. This survey traces that history and asks: could the same mechanism serve as a fundamental primitive for all of computing?
---
## A Room You Already Know
> **Summary:** Physical rooms scope your experience naturally — you see what's inside, the outside doesn't exist. Computers have no rooms: everything is visible everywhere. The difference isn't organization; it's *scoping*, and it's the most fundamental property of physical space that digital space lacks.
You walk into your kitchen. The countertops, the knives in the drawer, the half-drunk coffee from this morning. You don't see your bedroom closet from here. You don't see your office desk. You don't even think about them — they're behind walls, behind doors, in other rooms. They don't exist in your current experience.
Now open your laptop. Every file you've ever saved. Every app. Every project, past and present. Your tax documents sitting next to your novel draft, your vacation photos adjacent to confidential work files. There are no walls. There are no doors. Everything exists, all at once, everywhere.
The difference between these two experiences isn't about organization or discipline. It's about a property so fundamental to physical space that you never notice it: **scoping.** A room shows you what's inside it. A room hides what's outside it. Not "access denied" — the outside simply isn't part of your experience while you're in the room.
Your computer has no rooms.
This brief is about a technology that already builds rooms — that's been building rooms since 1992 — but built them for the wrong reason. We're going to look at that technology, understand what it actually does, and propose using it for the right reason.
---
## The Closed-Door Axiom
> **Summary:** The permission model shows you everything and locks some of it. The namespace model makes the outside nonexistent — not hidden, not denied, simply not there. This "closed-door axiom" is a precise technical property that's been implemented in production systems for over thirty years.
Here's a distinction that seems small but changes everything.
**The permission model** says: you can see this folder exists, but you can't open it. "Access denied." The world is one big namespace — everything is visible, some of it is locked. You know the locked things exist. You can see their names, their shapes, their positions. You just can't touch them.
**The namespace model** says: that folder doesn't exist for you. Not "you can't access it." It's not there. There is no folder. There is no locked door. There is no hallway behind the door. From your perspective, the universe contains exactly what's in your current namespace and nothing else.
The permission model is a museum with roped-off exhibits. You can see the Rembrandt; you just can't touch it. The namespace model is a room with solid walls. There might be a Rembrandt in the next building — you wouldn't know, because the next building isn't part of your room.
This is what Nico articulated on the morning this research began:
> "A room is empty and you can bring objects, people and do things (activity/memory) but a folder on your computer knows about everything outside it which is confusing. If you invite someone or an agent in a space with a 'closed door' then it doesn't know what's outside it."
The closed-door axiom: **when you're in a Space, the outside doesn't exist.** Not hidden. Not locked. Not filtered. Nonexistent.
This isn't philosophical hand-waving. It's a precise technical property. And it's been implemented in production systems for over thirty years.
```mermaid
block-beta
columns 2
block:perm:1
columns 1
p_label["Permission Model"]
p_globe["🌐 Global namespace"]
p_yes1["📂 Your project ✅"]
p_no1["📂 Sarah's project 🔒"]
p_no2["📂 HR files 🔒"]
p_yes2["📂 Old backups ✅"]
end
block:ns:1
columns 1
n_label["Namespace Model"]
n_door["🚪 Your Space"]
n_doc["📄 Brief you're writing"]
n_data["📊 Data for the brief"]
n_person["👤 Your collaborator"]
n_void["Nothing else exists"]
end
```
*Figure: Permission vs namespace. Left: everything visible, some locked. Right: only your Space exists — the rest is ontologically absent.*
In the permission model, you always see the full world — some of it is just locked. In the namespace model, you see only your Space. The rest doesn't exist.
---
## Thirty Years of Rooms (Built for the Wrong Reason)
> **Summary:** Namespace isolation has been built and rebuilt across five major systems since 1992: Plan 9 (per-process namespaces), Linux namespaces (kernel-level isolation), Docker (portable packaged rooms), Qubes OS (rooms for human activities), and agent sandboxes (rooms for AI). Each solved isolation for security. None added sharing, memory, or cross-Space identity — the features that turn a security tool into a cognitive tool.
The technology for digital rooms has existed since 1992. It just wasn't built for people. It was built for processes, then for security, then for applications, then for AI agents. At every stage, the builders thought they were solving an isolation problem. They were actually building the Space primitive.
### Plan 9 (1992): The Epiphany
In 1990, the same team that created Unix — Ken Thompson, Rob Pike, Dennis Ritchie — started over. Unix had one global filesystem namespace: every process could see `/`, could see every mounted disk, could see every device. Plan 9 asked: what if each process had its own namespace?
In Plan 9, every process gets its own **mount table** — its own list of what's visible. Process A might see `/net` pointing to the Ethernet. Process B might see `/net` pointing to a VPN tunnel. Same path, different realities. Neither process can see the other's network. Neither process knows the other's network exists.
The mechanism was simple: `bind` and `mount` operations that attach resources to paths within the process's private namespace. Everything — network interfaces, graphics devices, other processes' file trees — could be mounted as files. And crucially, these mounts were **per-process**, not global.
Plan 9 also introduced **union mounts**: you could overlay multiple directories onto the same path. Mount your project's files and the shared library onto `/work` and see both, merged into one view. This is bringing objects into a Space from multiple sources — precisely what our Space primitive does.
What Plan 9 proved: a namespace doesn't need to be global. Each participant can have its own view of what exists. And that view can be constructed by explicitly mounting (bringing in) resources.
Plan 9 was too early. It never achieved mainstream adoption. But its ideas — per-process namespaces, bind mounts, union directories — migrated directly into Linux.
### Linux Namespaces (2002–2016): The Mechanism Matures
Starting in 2002, Linux began implementing Plan 9's ideas as kernel features called namespaces. Over fourteen years, seven types emerged:
| Namespace | What it isolates | Year | Space analogy |
|-----------|-----------------|------|---------------|
| Mount (mnt) | Filesystem mount points | 2002 | What objects are in the room |
| UTS | Hostname and domain name | 2006 | The room's name/address |
| IPC | Inter-process communication | 2006 | Who can hear you talking |
| PID | Process IDs | 2008 | Who else is in the room |
| Network (net) | Network interfaces, routes, ports | 2009 | Which doors lead outside |
| User | User and group IDs | 2012 | Who you are in this room |
| Cgroup | Resource limits | 2016 | How much electricity the room uses |
Each namespace type isolates one dimension of a process's reality. Combine all seven and you get a process that has its own filesystem, its own network, its own sense of who's logged in, its own process list — a complete, self-contained reality. The process has no way to discover that it's living inside a larger system. From its perspective, its namespace IS the universe.
This is the closed-door axiom, implemented at the kernel level.
### Docker and OCI Containers (2013): Rooms You Can Ship
Docker did something clever with Linux namespaces: it packaged them. A Docker image is a snapshot of a namespace — a frozen room with all its objects arranged and ready. Ship the image to another machine, start it up, and you get the same room. Same files, same tools, same configuration. The room is portable.
Docker also formalized the idea of **volume mounts** — bringing external objects into a container's namespace. Your database container has its own isolated filesystem, but you mount a directory from the host to give it persistent storage. The container can see the mounted volume. It cannot see anything else on the host.
Multiple containers can mount the same volume. This is the same object existing in multiple Spaces simultaneously — exactly what Research 005b described. The document in the shared drive that appears in both your project Space and your collaborator's project Space.
```mermaid
graph TD
subgraph HOST["Host system (invisible)"]
V1["📁 /data/shared-docs"]
V2["📁 /data/models"]
end
subgraph CA["Container A — Project Alpha"]
CA_F["📄 Project files"]
CA_A["⚙️ Application"]
CA_V["📁 /docs"]
end
subgraph CB["Container B — Project Beta"]
CB_F["📄 Project files"]
CB_A["⚙️ Application"]
CB_V["📁 /docs"]
CB_M["📁 /models"]
end
V1 -.->|"mount"| CA_V
V1 -.->|"mount"| CB_V
V2 -.->|"mount"| CB_M
```
*Figure: Docker containers as Spaces. The host is invisible. Shared volumes let the same object appear in multiple rooms — without either container knowing the other exists.*
Container A sees its project files, its application, and the shared documents — nothing else. Container B sees its own files, its own application, the same shared documents, plus a models directory that Container A doesn't know exists. Each container's reality is determined entirely by what's been mounted into it.
This is the Space primitive, running on every cloud server in the world. Docker didn't call it that. Docker called it "containerization" and sold it for DevOps. But structurally, a container is a room: empty by default, you bring things in, the process inside doesn't know what's outside.
### Qubes OS (2012): Rooms for Humans (Almost)
> **Summary:** Qubes gives humans isolated VMs per activity — empty by default, explicitly bridged, color-coded. It proves the closed-door axiom works for daily use. What it misses: sharing, memory, cross-Space identity, and meaning-motivated (vs. security-motivated) design.
Joanna Rutkowska's Qubes OS is the closest existing system to what we're proposing — and the most instructive near-miss.
Qubes gives you separate virtual machines ("qubes") for separate activities. A banking qube for financial tasks. A work qube for office documents. A personal qube for private browsing. An untrusted qube for sketchy downloads. Each qube is a complete, isolated operating system. Malware in the untrusted qube cannot reach your banking qube because they don't share a kernel, a filesystem, a network stack, or a memory space.
What makes Qubes remarkable for our purposes:
**Empty by default.** A new qube starts with a template OS and nothing else. You bring your files in. You install your apps. You choose what belongs. This is the room metaphor — "If I rent a new office it's going to be an empty room."
**Explicit bridging.** To move a file from one qube to another, you explicitly copy it. To paste text between qubes, you use a special two-step clipboard (Ctrl-Shift-C to copy to the inter-qube clipboard, Ctrl-Shift-V to paste from it). Every cross-Space transfer requires conscious intent. Nothing leaks by accident.
**Color-coded trust domains.** Every window has a colored border indicating which qube it belongs to: red for untrusted, green for trusted, purple for personal. You always know which Space you're in. This is presentation invariant #4 (containment has boundaries) implemented at the OS level — the colored border IS the perceptible edge.
**Unified presentation.** Windows from different qubes appear on the same desktop. You see a browser window (red border, untrusted), a text editor (green border, work), and a messaging app (purple border, personal), all side by side. The isolation is invisible at the desktop level but always visible through the color coding.
What Qubes proves: the closed-door axiom works for human daily use. People can operate in isolated Spaces, bridging them explicitly, without going insane. The UX is workable.
What Qubes misses — and this is the gap we're filling:
- **Security-motivated, not meaning-motivated.** Qubes isolates because the world is adversarial. We isolate because focus requires scoping. The motivation difference leads to different design choices: Qubes makes bridging hard (security), we should make bridging natural (collaboration).
- **No sharing.** A qube is single-user. You can't invite someone into your banking qube. There's no concept of a shared Space with collaborators.
- **No memory.** A qube doesn't know *why* things are inside it. There's no context layer recording "you put this file here because it's part of the Q2 report."
- **No identity across spaces.** There's no "person who moves between rooms." Each qube has its own user, its own accounts, its own identity. The person is fragmented across Spaces rather than unified while moving between them.
### Agent Sandboxes (2024–2026): Rooms for the Other Kind of People
> **Summary:** E2B, Daytona, Modal, Fly.io, Cloudflare Workers, and OpenClaw all build isolated environments for AI agents — empty by default, explicit resource binding, invisible outside. They're containers. They're namespaces. They're rooms. If agents are people (Research 009), then agent sandboxes aren't agent infrastructure — they're people infrastructure.
Here's where it gets interesting.
Over the past two years, a wave of platforms has emerged that provide isolated environments for AI agents:
**E2B** (2023): Spins up isolated cloud sandboxes where AI agents can execute code. Each sandbox is a lightweight VM with its own filesystem, network, and process space. The agent can't see the host. Can't see other sandboxes. Can only access what's been passed into its environment.
**Daytona** (2024): Development environment manager that creates isolated workspaces for AI coding agents. Each workspace has its own filesystem, git repo, installed tools. The agent operates within the workspace boundary.
**Modal** (2023): Serverless compute platform where each function runs in an isolated container with its own filesystem and dependencies. Agents can be given scoped access to specific volumes.
**Fly.io Machines** (2022): Lightweight VMs that spin up on demand. Each Machine has its own root filesystem, network identity, and persistent volumes. Used increasingly for agent sandboxes.
**Cloudflare Workers** (2017, evolved for agents 2024+): Isolate execution at the V8 level. Each Worker has its own global scope, can't access other Workers' state, interacts with durable storage through explicit bindings.
**OpenClaw sandbox** (2025): Runs agent tools in an isolated container. The agent sees its workspace and nothing else.
Every one of these platforms implements the same pattern: empty by default, explicit resource binding, invisible outside. They're containers. They're namespaces. They're rooms.
And here's the insight that connects Research 009 (personhood) to this brief: **if agents are people — functional persons with identity, relationships, and agency — then agent sandboxes aren't agent infrastructure. They're people infrastructure.**
These platforms didn't set out to build Spaces. They set out to build safe execution environments for AI. But what they built is precisely the primitive we've been theorizing: persistent (or ephemeral), isolated, scoped environments where an entity operates with only the context that's been explicitly provided.
The difference between an E2B sandbox and our Space primitive is not technical. It's conceptual:
- E2B thinks it's building agent infrastructure for code execution.
- We think it's building the Space primitive for everyone.
The convergence is striking. Thirty years, five independent lineages, the same pattern:
```mermaid
graph LR
P9(("Plan 9\n1992")) --> LN["Linux\nNamespaces\n2002"]
LN --> DK["Docker\n2013"]
LN --> QB["Qubes OS\n2012"]
DK --> AS["Agent\nSandboxes\n2024"]
QB --> AS
AS --> SP{"Space\nPrimitive"}
DK --> SP
```
*Figure: Namespace convergence. Five independent lineages — OS research, kernel features, DevOps, desktop security, AI infrastructure — all arrived at the same mechanism. The Space primitive synthesizes them.*
---
## The Broader Landscape: Rooms Everywhere
> **Summary:** Beyond the main lineage, browsers and WASM independently implement the same closed-door pattern. Browser origins scope cookies, storage, and execution per-domain (but per-app, not per-meaning). WASM components have zero ambient authority — the purest form of "the outside doesn't exist." Both confirm the pattern; neither solves for human cognitive scoping.
Two more domains have been building rooms without calling them that.
### Browser Sandboxes: Per-Origin Namespaces
Your browser already runs a namespace model. Each origin (protocol + domain + port) gets its own isolated context:
- Its own cookies
- Its own localStorage
- Its own IndexedDB
- Its own service workers
- Its own execution context
JavaScript running on `gmail.com` cannot read cookies from `bank.com`. Not "access denied" — the cookies don't exist in Gmail's namespace. The Same-Origin Policy (1995) is the browser's closed-door axiom.
Cross-origin communication requires explicit bridging: CORS headers, `postMessage`, shared service workers. Sound familiar? It's the Qubes clipboard model. Nothing leaks by default; everything crosses by intent.
Where browsers fall short: origins are scoped per-app (per-domain), not per-meaning (per-project). You can't create a browser namespace that says "these four tabs from four different domains are all part of my Q2 research project." The scoping dimension is wrong — it's technical (domain boundaries) rather than semantic (your intent).
### WASM Components and Capability-Based Systems: No Ambient Authority
WebAssembly components take the closed-door axiom to its logical extreme. A WASM component has **zero ambient authority** — it cannot access the filesystem, the network, the clock, or even random numbers unless a capability is explicitly passed to it.
This is the purest implementation of "the outside doesn't exist." A WASM component doesn't know what a filesystem is until someone hands it a file handle. It doesn't know about the network until someone passes it a socket capability. Its universe is exactly the set of capabilities it's been given.
Capability-based security systems — seL4, Capsicum, WASI — formalize this principle: **you can only access what you hold a capability (token) for.** No ambient authority. No implicit permissions. No "well, it's on the same machine, so it can probably see it." If you don't have the cap, the resource doesn't exist for you.
The mapping to Spaces is direct:
| Capability concept | Space concept |
|-------------------|---------------|
| Capability token | Object mounted in the Space |
| No ambient authority | Closed-door axiom |
| Explicit capability delegation | Inviting/bringing objects in |
| Capability revocation | Removing objects/people from the Space |
| Capability attenuation | Bringing in a read-only view of an object |
---
## The Reframe: Same Mechanism, New Purpose
> **Summary:** Every surveyed system built namespace isolation for security. We propose the same mechanism for cognition — helping people focus by making irrelevant context nonexistent. The mechanism is identical; the purpose shift changes everything: cognitive isolation optimizes bridging (vs. minimizing it), assumes collaboration (vs. adversarial actors), and needs memory (why things are here, not just what).
Here's the move this brief is making.
Every system we've surveyed — Plan 9, Linux namespaces, Docker, Qubes, agent sandboxes, browser origins, WASM capabilities — built isolation for **security**. The question was always: "How do we prevent untrusted code from accessing resources it shouldn't?"
We're proposing the same mechanism for **cognition**: "How do we help a person — human or agent — focus on what matters by making everything else nonexistent?"
The mechanism is identical. The mount table doesn't care whether you're using it to prevent malware propagation or to scope a writing project. The namespace boundary doesn't care whether it's protecting a bank from a hacker or protecting a novelist from their tax spreadsheet. It just separates inside from outside.
But the purpose shift has consequences:
**Security isolation minimizes bridging.** The fewer connections between isolated domains, the smaller the attack surface. Qubes makes cross-qube communication deliberately cumbersome.
**Cognitive isolation optimizes bridging.** You need to bring objects in, invite people, share context. The Space should make bridging natural and intentional — easy to do when you mean to, impossible to do by accident.
**Security isolation is adversarial.** Assume the worst. The code is malware. The user is an attacker. The network is hostile.
**Cognitive isolation is collaborative.** Assume good intent. The person in the Space is here to work. The objects are here because they're relevant. The other people are here because they were invited.
**Security isolation doesn't need memory.** A container doesn't care why a volume is mounted.
**Cognitive isolation needs memory badly.** A Space should know: "This document was brought in on March 12 because Nico said it was relevant to the Q2 analysis. Sarah added these three files on March 15. The agent created this summary on March 20." The mount table isn't just a list of what's here — it's a narrative of how the Space was assembled.
```mermaid
graph TD
subgraph SEC["Security Framing (existing)"]
S_Q["Qubes OS"]
S_D["Docker"]
S_B["Browser sandboxes"]
S_W["WASM/capabilities"]
S_A["Agent sandboxes"]
end
subgraph COG["Cognitive Framing (proposed)"]
C_S["The Space primitive"]
end
M["Namespace isolation\n(empty by default,\nexplicit mounting,\nclosed door)"]
S_Q --> M
S_D --> M
S_B --> M
S_W --> M
S_A --> M
M --> C_S
C_S --> F1["+ Sharing\n(invite people)"]
C_S --> F2["+ Memory\n(why things are here)"]
C_S --> F3["+ Identity\n(person moves between Spaces)"]
C_S --> F4["+ Bridging UX\n(natural cross-Space flow)"]
```
*Figure: The reframe. All existing systems converge on the same namespace mechanism. The Space primitive adds four capabilities that security-motivated systems never needed.*
All existing systems converge on the same mechanism (namespace isolation). The Space primitive uses that mechanism and adds the four things security-motivated systems never needed: sharing, memory, cross-Space identity, and natural bridging.
---
## The Mount Table Is Context
> **Summary:** A process's mount table — its list of what's visible — is structurally identical to an AI agent's context window. Mounting a document into a Space is adding a line to the context. Smaller mount table = less noise = better performance. This isn't metaphor; it's the same computational property that makes both humans and agents more effective in bounded environments.
Here's the technical analogy that ties everything together.
In Plan 9 and Linux namespaces, a **mount table** describes a process's reality: which filesystems are mounted at which paths, which devices are visible, which network interfaces exist. The mount table is a complete specification of the namespace — everything the process can see.
Now think about what "context" means for an AI agent. Context is: what documents are available, what tools are accessible, who else is in the conversation, what happened before. It's a list of everything the agent can see and interact with.
The mount table IS context.
When you "bring a document into a Space," you're adding a line to the mount table. When you "invite a person," you're mounting their presence. When you "add a tool," you're mounting a capability. The Space's mount table is its context — a complete, inspectable, modifiable description of what exists.
This has an immediate practical consequence for agents: **smaller mount table = smaller context = better performance.** An agent operating in a scoped Space with five relevant documents, two tools, and one collaborator will outperform the same agent operating in an unbounded environment with access to everything. Not because it's smarter, but because it's not drowning in irrelevant information.
This is why the room metaphor isn't just a nice analogy. A room's physical properties — bounded, scoped, explicitly furnished — map directly to the computational properties that make both humans and agents more effective.
| Room property | Mount table equivalent | Cognitive effect |
|--------------|----------------------|-----------------|
| Walls (boundary) | Namespace isolation | Focus — irrelevant context is nonexistent |
| Furniture (objects) | Mounted volumes/files | Relevance — only what's needed is present |
| People in the room | Mounted identities/presences | Collaboration — you know who's here |
| Door (controlled entry) | Capability delegation | Trust — you choose what enters |
| Room's purpose | Mount table metadata/memory | Meaning — why these things are together |
---
## Universal Primitives for Universal People
> **Summary:** If agents are people (Research 009), there's no separate "agent infrastructure" — just infrastructure for people. E2B builds Spaces for one kind of person. Docker builds Spaces for software processes. Qubes builds Spaces for activities. None have the full primitive. The Space requires all six properties: empty by default, closed door, explicit mount, shareable, memory-equipped, and cross-Space identity.
Here's where Research 009 (personhood) changes the lens entirely.
Nico said it directly: "Primitives built for agents should be universal — also to work with people. And if we have a chapter with an enlarged definition of people it changes the lens since agents are or will soon be technically people."
Research 009 established that personhood is a functional category: persistent identity, capacity for relationships, agency, accountability. Not biology. If agents are people — functional persons who participate in systems with identity and agency — then there is no separate category of "agent infrastructure." There's just infrastructure. For people.
E2B isn't building "agent sandboxes." It's building Spaces for a particular kind of person.
Docker isn't building "application containers." It's building Spaces for a particular kind of software process.
Qubes isn't building "security domains." It's building Spaces for a particular set of activities.
They're all building the same thing. None of them have built the full thing. The full Space primitive — the one that works for humans, agents, and any entity that fits the People pattern — requires all of what these systems have built plus the four extensions we identified: sharing, memory, cross-Space identity, and natural bridging.
The progression looks like this:
| System | Empty by default | Closed door | Explicit mount | Shareable | Memory | Cross-Space identity |
|--------|:---:|:---:|:---:|:---:|:---:|:---:|
| Plan 9 | ✅ | ✅ | ✅ | ❌ | ❌ | ❌ |
| Linux namespaces | ✅ | ✅ | ✅ | ❌ | ❌ | ❌ |
| Docker | ✅ | ✅ | ✅ | Partial¹ | ❌ | ❌ |
| Qubes OS | ✅ | ✅ | ✅ | ❌ | ❌ | ❌ |
| Browser origins | ✅ | ✅ | ❌² | ❌ | ❌ | ❌ |
| WASM components | ✅ | ✅ | ✅ | ❌ | ❌ | ❌ |
| Agent sandboxes | ✅ | ✅ | ✅ | Partial³ | ❌ | ❌ |
| **Space primitive** | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
¹ Docker: containers share volumes but not human collaborative presence.
² Browsers: resources are per-origin, not explicitly mounted by the user.
³ Agent sandboxes: some support shared volumes/APIs, not collaborative presence.
Every existing system nails the first three columns — the namespace mechanism. None have the last three — the features that turn a namespace from a security tool into a cognitive tool for people.
---
## What the Presentation Invariants Say
> **Summary:** Namespace-based Spaces naturally satisfy four presentation invariants that current computing violates: no public-behind-private (#1), hard containment boundaries (#4), singular presence (#3), and traces at the location where actions happen (#11). The namespace model doesn't just support these invariants — it makes violating them structurally impossible.
The Foundations Synthesis B identified twelve cognitive rules that information environments must obey. Namespace-based Spaces naturally satisfy several that current computing violates:
**Invariant #1 (Public never behind private):** In a namespace model, there's no "behind." Each Space is its own universe. You can't accidentally create a public resource buried inside a private Space because Spaces don't nest by default — they're peer environments you move between. Nesting, if it exists, follows the namespace model: the inner Space can't see the outer Space, which means you can't accidentally require passage through private to reach public.
**Invariant #4 (Containment has boundaries):** A namespace has the hardest possible boundary — the edge of existence. Not a blurry transition, not a soft border, but a hard ontological cut: inside is real, outside isn't. Qubes demonstrated this with color-coded window borders. The Space primitive should make the boundary equally perceptible.
**Invariant #3 (Singular presence):** If a person is "in" a Space (their presence is mounted in this namespace), they have a location. They're here. If they leave (presence unmounted), they're not here. The namespace model gives presence a definite, singular location — exactly what Slack's "online everywhere" model fails to provide.
**Invariant #11 (Actions leave traces where they happen):** If the mount table includes memory — if the Space records why things were brought in and what happened inside — then actions leave traces at the Space level. "Nico added this file on March 12" is a trace in the Space where it happened, not in a global activity log.
---
## The Compatibility Bridge: Mount Apps In
> **Summary:** Existing apps don't need to understand Spaces — the Space controls what the app can see. Plan 9 proved this; Docker proved it at scale. A three-tier adoption model (unmodified → mount-aware → Space-native) lets the ecosystem evolve gradually, like web standards adoption.
One hard question: how do existing apps work in Spaces? You can't wait for every app to become "Space-aware."
Plan 9 answered this thirty years ago: **mount them in.**
An app doesn't need to understand Spaces. The Space controls what the app can see. Run a text editor inside a namespace and it can only open files that have been mounted into that namespace. Run a browser inside a namespace and it can only reach networks that have been mounted. The app works exactly as before — it just lives in a scoped reality.
Docker proved this at scale: millions of applications run unmodified inside containers. The applications didn't change. The environment changed. The application is none the wiser.
This is the compatibility bridge for the Space primitive:
- **Tier 0 (Unmodified):** Run the app inside the Space's namespace. It sees only what's mounted. Works immediately, no app changes needed. Limitation: the app doesn't know it's in a Space, can't participate in Space-level collaboration.
- **Tier 1 (Mount-aware):** The app can read the Space's mount table to discover what objects are available. It knows it's scoped. It can present only what's in the Space. Requires the app to understand a mount-table API.
- **Tier 2 (Space-native):** The app understands Spaces as a concept. It can participate in sharing, presence, and memory. It knows who else is in the Space and can coordinate with them. This is the full integration — and it's what you'd build for new apps.
The beauty of the tiered model: adoption doesn't require everyone to move at once. Existing apps work at Tier 0 with zero changes. Over time, apps that integrate with the Space API move up tiers. The ecosystem evolves gradually, like web standards adoption.
---
## The Start-Empty Intuition
> **Summary:** The most counterintuitive property of Spaces is that they start empty. Your computer starts full (every file, every app, everything). A physical room starts empty (you furnish it). This inversion — from "filter down" to "build up" — is the core UX shift of namespace-based computing.
Nico's original framing captures it: *"If I rent a new office it's going to be an empty room."* This is the opposite of how every operating system works today.
```mermaid
block-beta
columns 2
block:current:1
columns 1
c_label["Current: Start Full"]
c_all["📂 Everything visible"]
c_filter["🔍 Filter & search"]
c_find["📄 Find what you need"]
c_noise["😵 Noise never goes away"]
end
block:spaces:1
columns 1
s_label["Spaces: Start Empty"]
s_empty["🚪\nEmpty room"]
s_bring["📄 Bring in what matters"]
s_focus["🎯 Work with just that"]
s_calm["😌 Noise never existed"]
end
```
*Figure: The inversion. Current computing starts with everything and asks you to filter. Spaces start with nothing and ask you to furnish. The cognitive difference is profound: in one model, noise is always present; in the other, noise never existed.*
---
**Key Findings:**
- Namespace isolation — empty by default, explicit mounting, closed door — has been independently built and proven by five major system lineages since 1992 (Plan 9 → Linux → Docker → Qubes → agent sandboxes)
- Every existing implementation was motivated by security; none were designed for cognitive scoping, yet the mechanism is identical
- The shift from security to cognitive framing requires four additions: sharing, memory, cross-Space identity, and natural bridging
- A process's mount table is structurally equivalent to an AI agent's context — smaller mount table means better performance, measurably
- If agents are people (Research 009), agent sandboxes are already people infrastructure — they just don't know it
- The three-tier compatibility model (unmodified → mount-aware → Space-native) enables gradual ecosystem adoption without requiring universal buy-in
- The "start empty" inversion — from filtering a full world to furnishing an empty room — is the core UX shift that makes Spaces cognitively different from everything that exists today
---
## Open Questions
### The hallway problem
> **Summary:** If Spaces are self-contained, navigation between them becomes a design problem with no obvious precedent.
If each Space is its own universe, how do you find things? In a building, you leave the room, walk down the hallway, and enter another room. What's the digital hallway? Some options:
- A "home" Space that contains portals (links) to your other Spaces. Like a lobby.
- A search that operates across Spaces you have access to — but this partially breaks the closed-door axiom, because it reveals the existence of things outside the current Space.
- Spatial memory — you remember which Space something is in, the way you remember which room you left your keys in.
### The empty-room problem
> **Summary:** An empty digital Space needs default affordances — the minimum furniture that makes it usable without being pre-cluttered.
Physical rooms have affordances even when empty: walls, floors, light switches, power outlets. An empty digital Space might be paralyzing. What are the default affordances? Maybe: a place to drop objects (drag-in), a way to invite people, a way to name the Space, a visible boundary. The minimum furniture.
### Shared objects, divergent contexts
> **Summary:** When the same object lives in multiple Spaces, edits in one may or may not appear in another — the copy-vs-reference question from 005b, now with concrete technical grounding.
If the same document is mounted in two Spaces, and someone edits it in Space A, do the edits appear in Space B? In Docker, a shared volume reflects writes immediately across all mounts. But should a Space allow "branched" views — the same object with local modifications that haven't been pushed back? This is the copy-vs-reference question from Research 005b, now with concrete technical grounding.
### Namespace depth
> **Summary:** How deep should Space nesting go? Physical buildings have natural limits; namespaces don't.
Spaces containing Spaces. A project Space that contains sub-project Spaces. How deep should nesting go? Physical buildings have natural limits (rooms in a building, not rooms in rooms in rooms). The namespace model has no such limit. Presentation invariant #12 (depth indicates specificity) suggests that deeper should mean more specific — but how many levels before it becomes unnavigable?
### The performance dividend
> **Summary:** For agents, namespace isolation directly reduces token cost and inference time — a measurable economic benefit that could drive adoption on efficiency grounds alone.
For AI agents, namespace isolation isn't just cognitive — it's economic. Less context means fewer tokens means faster inference means lower cost. A 200-document project with a 5-document Space means the agent processes 5 documents, not 200. This is a concrete, measurable performance benefit that could drive adoption on pure efficiency grounds, even before the cognitive benefits are proven.
---
## What We've Found
> **Summary:** The Space primitive isn't speculative — it's a synthesis of thirty years of proven namespace isolation, completed with sharing, memory, cross-Space identity, and natural bridging for universal use by all people (carbon and silicon).
The Space primitive — a persistent, shareable, scoped container that can hold anything — isn't speculative. The mechanism exists. Thirty years of systems engineering have built, tested, and scaled namespace isolation:
- Plan 9 proved that per-process namespaces work
- Linux namespaces proved they work at OS scale
- Docker proved they work for distributing and running applications worldwide
- Qubes proved they work for human daily workflows
- Agent sandboxes proved they work for AI agents in production
- WASM/capabilities proved that zero ambient authority is viable
What none of these systems did is build the full primitive. They each solved one use case — security isolation for processes, for apps, for activities, for agents. They missed sharing, memory, cross-Space identity, and natural bridging — the features that turn isolation from a security tool into a cognitive tool for people.
The Space primitive takes the proven mechanism and adds the missing layers. It's not a new invention. It's a synthesis — bringing together what's been built in isolation (literally) and completing the picture for universal use.
When Nico says "a room is empty and you can bring objects, people, and do things," he's describing a Linux namespace with four features that containers never needed but people — all people, carbon and silicon — always have.
---
*Regent's Park · Brief 010 · v1.1*
*Context: 005b — Spaces · 008 — Entity Ontology · 009 — Personhood Beyond Biology · Foundations B — Presentation Invariants*
🌳