DEOS: A Distributed Operating System over Content-Addressed Typed Data

1. Introduction

Ask what an operating system is and the usual answer points at hardware: the layer that schedules processes, protects memory, drives the disk and the network card. That answer is not wrong, but it is a frame of reference rather than a definition. Plan 9 took a different frame, organizing the whole system around one coordination abstraction — the file — so that devices, network services, and windows were all named and accessed the same way. By yet another reading, the operating system most people now live inside is the web browser: it is where their documents, their mail, their tools, and their colleagues are, and the machine underneath has become a detail. The question what is an operating system is answered by what you choose to coordinate and how, and the hardware answer is only the lowest of several honest ones.

This paper takes the coordination frame and pushes it one step further than it usually goes. The unit of a conventional operating system is the machine: the thing it manages is one computer’s resources. But a person today is not one computer. They have a laptop, a desktop, a phone, perhaps a home server and a tablet; an organization has fleets of them. The natural unit of coordination is no longer the box but the fleet — all of those peers, run as one coordinated system. That is what we mean by DEOS: The Entity System, viewed as the operating system of all your peers at once. When you have five machines on your home network and they hold one coherent, synchronized, capability-governed body of state that you reach the same way from any of them, the operating system is not any one of the five. It is the abstraction over all of them. That is why it is a distributed operating system, and the distribution is not a feature bolted onto a single-machine OS — it is the point.

The claim is structural, not a metaphor, and the rest of the paper makes it good. An operating system coordinates state, dispatch, processes, events, authorization, and the boundaries between its parts. The entity system’s standard peer — the core protocol plus the substrate-bridge extensions (see Convergent Evolution) — provides each of these, from the same six primitives, in the same typed and content-addressed substrate. The mapping from kernel service to extension is close enough to walk concept by concept, and we do.

The framing matters. The core protocol is a substrate, not a system: as developed in The Entity Core Protocol, the core ships a small set of live hooks — register a handler, dispatch outward, observe the emit pathway, check a capability, connect to a peer — and does not dictate what is layered above them. The extensions DEOS is built from are one coherent set of choices over that substrate, the set the architecture ships; they are not privileged by the core, and a community could compose a different operating system from the same hooks. So DEOS is one operating system the substrate can host — the reference build — not the operating system the substrate is. We keep that line sharp throughout, because it is the difference between describing a design and legislating one. This paper maps a space of possibilities and walks the reference point in it; it does not claim that point is the only one, or the best.

One consequence is worth stating plainly at the start, because it is the strongest version of the idea and the easiest to overstate. Because the substrate can carry computation as well as data, you could, if you chose, do all of your computing inside the entity system and never leave it — your storage, your coordination, your programs, your devices, all entities and dispatch in one operating system. That is an option the substrate makes available, not a mandate and not a description of how anyone runs today. It does not mean abandoning native code: a real deployment still has handlers written in a host language, still has lower-level infrastructure, still drops to the metal where it must. It means the architecture of your computing — the layer you think in — can be the entity operating system and the network of peers you call yours. How far anyone takes that is their choice; the system does not care.

This paper is one of three views of the same substrate, and keeping them apart keeps each one honest. This paper (DEOS) is the operating system you run your own devices on — the coordination, the kernel services, the fleet, the deployment. The developer’s view, building and serving an application on the substrate, is Application Architecture — that paper is the thing you build; this one is the system you build it on. And there is a third view, the subject of The Decentralized Systems Landscape: the entity system at internet scale, as a peer-to-peer and social-convergence substrate — what communities build on it, why sites and shared spaces and version-controlled repositories exist, the sharing and exchange that happen when your fleet connects to other people’s fleets. This paper hands off to that one at the seam where your operating system meets someone else’s. The three overlap — they share peers, compositions, the extension set — but they ask different questions, and DEOS holds the operational one.

1.1. What This Paper Covers

The paper is organized around the operating-system frame and the three moves above:

1. The reference operating system over an extensible substrate. Why the core is a kit and the standard peer is one operating system built from it, and what that buys.
2. The kernel as its own running state. A peer as a live configuration recorded in its own tree; the system that observes and heals itself.
3. The kernel-service mapping. The systematic correspondence between operating-system services and substrate extensions, where it exceeds Unix, where it breaks, and how the services coordinate internally.
4. Cross-peer coordination. What the system actually provides when peers diverge and reconcile — convergence as a primitive, consensus as a configuration — told honestly, including the open problems.
5. The network as transport substrate, the fleet, and the shell. How peers reach each other, how a fleet is run as one operating system across the deployment scales, and the distributed shell that drives it.

1.2. What This Paper Does Not Cover

The six primitives and the build-up sequence are in The Entity System; the protocol wire format, dispatch, and capability mechanics in The Entity Core Protocol; the computational model in The Entity Church Architecture; the compilation gradient and machine boundary in The Entity Machine Boundary; the landscape of existing systems in Convergent Evolution; the application developer’s view of the substrate in Application Architecture; the internet-scale and social-convergence view of the wider field in The Decentralized Systems Landscape; the security architecture in Entity System Security Architecture; and the structural methodology behind the analytical vocabulary this paper occasionally uses in A Structural Methodology for Information System Domains. We assume the primitives and the extension set from those papers and do not re-derive them.

1.3. Scope Discipline

The core protocol is stable, and the substrate-bridge extensions are the architecture-supplied set over it, carried to differing depths by the reference implementations. The operational tier a multi-peer deployment needs — identity, attestation, the network stack — is partly mature and partly still specified, and we mark which is which where it matters. The aim is to be useful to someone deciding how to run on the substrate, with the maturity of each piece stated plainly. Maturity is the part of this paper most likely to have moved by the time it is read; the extension specifications and the conformance matrix are where the current state lives.

2. The Reference Operating System over an Extensible Substrate

The reason DEOS is a reference operating system rather than the operating system is in the shape of the core protocol. The core is small and deliberately incurious about what runs on it. It defines the typed, content-addressed substrate — entities identified by the hash of their content, a mutable tree of named paths over an immutable content store — a single dispatch operation, capability-based authorization, and peer connection. Around that it exposes a handful of live hooks: register and unregister a handler, let a handler dispatch outward, observe the pathway by which writes emit their effects, check a capability, connect to another peer. And then it stops. It does not say what services should exist above those hooks; it says only how anything built there must behave.

An operating system is what you get when you commit to a particular set of services over that substrate. The standard peer is one such commitment: the core protocol plus the substrate-bridge extensions — the extended tree, types, content, inbox, subscription, continuation, compute, query, revision, history, and clock. Each is a service the application uses through the same dispatch as everything else, not a component the application contains. Together they cover what operating-system literature calls kernel services, and a peer that installs them is the kernel of a distributed operating system. That composition, plus the shell and deployment surface that make it usable, is what we call DEOS.

The full structure is a layered stack, and naming it once fixes the altitude for the rest of the paper. At the bottom is a thin platform bootstrap — the small body of native code each implementation needs to run at all, on the order of a few thousand lines. Above it sits the core protocol: the six primitives, dispatch, capabilities, the emit pathway, the type system’s fixed point. Above that is a coordination layer that specifies how multiple extensions behave when they observe the same write. Above that are the extensions themselves. Above those, the SDK presents the protocol in a host language; above the SDK, shared patterns; and at the top, applications. The architecture owns the core, the coordination layer, and the extensions; the layers above are the developer’s surface, which is Application Architecture’s subject.

The decisive point is that almost none of this is mandated by the core. These extensions are the architecture-supplied set, and the coordination layer that choreographs them is itself one set of choices about ordering and cascade behavior. The architecture’s own design notes are explicit that the reference implementations are proof the specification is implementable, not the canonical thing — the specification is the deliverable, and the concrete instantiation is “one set of choices; others are possible.” A community that wanted different messaging semantics, a different history model, or a different reactive discipline could build them on the same hooks and still interoperate at the core. This is exactly why application architecture on the substrate is a design space (see Application Architecture) rather than a single stack, and it is the same reason the operating system is a space too. DEOS is the region of that space the architecture has built out and tested. We walk that region in detail; the reader should keep in view that it is a region, not the whole map.

3. The Kernel Is Its Running State

A conventional kernel is a program: an image loaded into memory whose running state — its process table, open files, scheduler queues, socket buffers — lives in opaque data structures you inspect only through special interfaces, if at all. The entity system inverts this. A peer is not an image with hidden state beside it. A peer is its state, and that state is entities in a tree you can read like any other.

The architecture’s own definition is blunt: a peer is not a role but a configuration — its cryptographic identity, the handlers and extensions it has installed, the capabilities it holds and has issued, its tree, its active continuations, its active subscriptions, and its operational state. Two peers that run the same code are different peers if any of this differs. There is no separate notion of “the system” apart from this configuration; the configuration is the system. And because every part of it is written through the ordinary emit pathway, every part of it is an entity: stored by hash, bound to a path, subscribable, recorded in history, available to compute, indexed by query. The peer’s identity is at a known path; the transports it speaks and the addresses it listens on are entities; its view of which other peers are reachable is entities; its open connections, its held capabilities, its subscriptions and the durable continuations representing its in-flight work — all entities, all readable with the same get that reads a document.

This collapses three things a normal operating system keeps separate. The tree is the data store, plainly. It is also the process table: a peer’s running work is its active continuations and subscriptions, which are entities, so listing what the peer is doing is reading a path, and a tool that shows every continuation across every peer is a distributed process viewer over ordinary entity reads. And it is the management interface: there is no separate monitoring API and no admin console, because the state an operator would want to inspect or change is the tree, reached through the same dispatch and governed by the same capabilities as everything else. The operating system describes itself by being read.

The sharpest consequence is in recovery, and it is worth being precise about what is claimed. There is no write-ahead log, no journal, no checkpoint file, no separate recovery protocol, because the tree already is the durable record of intent. A peer with durable storage that stops and restarts is required to produce behavior equivalent to one that never stopped, holding the same state — this restart-equivalence is a normative property, not an aspiration. The peer recovers by reading its own state and acting on it: it sees which connections it had, which subscriptions it owed, which work was in flight, and re-establishes them. The system heals by being itself.

We should mark the line between what is settled and what is the direction. The operational-state types — transports, configuration, observed peer status, local aliases, connections — are specified, and restart-equivalence is normative. The fuller vision, in which a peer’s entire web of relationships is maintained as a self-repairing graph of running processes that needs no imperative reconnection code, is developed as the entity-native target in the architecture’s explorations; a peer that reconnects with ordinary host-language code interoperates identically and is the common case today. The property that makes the strong version coherent — that the operating system’s running state is nothing but readable, content-addressed entities — is real now. How much of the self-maintenance is expressed natively rather than in handler code is a gradient the implementations are still climbing.

4. The Kernel-Service Mapping

With the framing in place — a reference operating system whose running state is its own tree — the kernel-service mapping is the concrete demonstration that the standard peer covers what an operating system covers. The correspondence is not “DEOS resembles Unix.” It is that DEOS and Unix solve the same coordination problems, and for most of them the entity system has a single mechanism where Unix has one too.

4.1. A Systematic Mapping

Read the table as pairs. Where Unix raises a signal, the standard peer delivers a subscription event; where Unix opens a pipe, the standard peer routes an inbox message; where Unix forks a process, the standard peer advances a continuation. Each pair solves the same coordination problem with the same kind of mechanism — with the difference that the standard peer’s mechanism is content-addressed, typed, and capability-scoped from the first.

4.2. Where DEOS Exceeds Unix, and Where It Breaks

The substrate hands the kernel services properties a Unix-derived kernel does not have, because they are properties of the substrate, not features added to a kernel. Content addressing makes integrity verification, deduplication, and cross-machine cache reuse automatic — an entity’s name is the hash of its bytes, so identical things are the same thing. Authorization is per-operation and decentralized, granted by handing out attenuable tokens rather than by maintaining access lists, with revocation expressed in the tree (see Entity System Security Architecture). Versioning is built in: the store is immutable beneath a mutable namespace, so prior states remain addressable and audit and undo are structural. The system is self-describing — the type entities describe themselves and the protocol’s own structures — and dispatch is typed, so a class of error a Unix kernel meets at runtime is caught at the boundary.

The parallel also breaks, in three honest places. DEOS is distributed-first where Unix is local-first: Unix’s coordination mechanisms live within one machine and its distributed extensions reach across machines with weaker semantics, whereas a subscription, a continuation, or an inbox message crosses peers without changing what it means, and the single-machine case is a deployment configuration rather than a separate set of primitives. DEOS does not abstract hardware: process isolation, memory protection, scheduling fairness, and interrupts are the host’s job, and the kernel-service mapping is for the coordination layer that traditionally sits above the hardware-abstraction layer. And networking is a substrate, not an in-kernel service: Unix puts TCP/IP in the kernel, while DEOS treats the network as transport that an extension wraps — structurally cleaner, but it means the networking layer is younger than a Unix-derived stack’s, a point the next sections take up directly.

4.3. How the Services Coordinate

A Unix kernel’s services interact through the kernel’s implicit state machine, which is why a developer has to reason about signal-safe code, fork-safety, and file-descriptor races. The standard peer’s services do not interact implicitly. Every write travels the emit pathway — store the content, bind the path, raise the events — and the extensions that care register as consumers invoked in a fixed, specified order: persistence, then indexing, then time, then history, then computed values, then structural summaries, then automatic versioning, then subscription delivery. Delivery is two-phase, settling the synchronous cascade fully before the asynchronous broadcast. The cascade carries a depth counter with specified thresholds at which it suppresses further reactions, freezes recomputation, and finally refuses the write, so a runaway reaction is bounded by the protocol rather than by luck. And termination is content-addressed: when a recomputed result hashes to what is already stored, the write is suppressed and the cascade stops, because nothing changed.

This coordination layer is normative for a peer that runs several extensions — but, consistent with the substrate principle, it is normative given those extensions, not a claim that the core mandates them or their ordering. The discipline that makes it compose is that each extension does its own distinct job, and where two would touch the same surface the coordination layer specifies the interaction explicitly rather than leaving it to emerge. That explicitness is the property Unix lacks, and it is what lets the kernel services be installed in different combinations without implicit cross-talk.

5. Cross-Peer Coordination

If the kernel-service mapping is where DEOS earns the word operating system, cross-peer coordination is where it earns the word distributed — and it is the part most easily overstated. The honest account is more interesting than the slogan, so we give it in full, including what is not yet solved.

5.1. Synchronization Is a Gradient

Coordination between peers rests on synchronization, and synchronization is not one mechanism but a gradient of four, each independently useful. At the base is the raw tree: the current path-to-hash bindings, state with no history. Above it, the emit pathway records each write’s transition — the new hash, the previous hash, the author, the capability, the time — giving a per-path, per-peer history for free, though one that on its own says nothing about other peers. Above that are snapshots: a content-addressed capture of a subtree’s bindings, so that two peers comparing a snapshot hash know in one comparison whether they hold identical state. And above that is the version: a snapshot plus parent links, author, time, and message — which is, structurally, a commit in a content-addressed history. Zero parents is an initial version, one is linear progress, two or more is a merge, and because the parents are hashed into the version’s own identity, the version history has the same cryptographic integrity as a distributed version-control system’s commit graph.

Two peers reconcile by walking this structure. They negotiate heads — exchanging what each has and wants — find a common ancestor in the version graph, transfer the content that differs, and integrate, either fast-forwarding or merging. Merging has two layers: a structural layer that decides which hash sits at which path, and a semantic layer that reconciles the content when both sides changed the same path, through a pluggable strategy that defaults to a three-way merge and admits last-writer-wins, a conflict-free replicated type, manual resolution, or a custom handler. A guiding principle keeps this clean: a replicated data type is a merge algorithm, not a storage format (Shapiro et al. 2011), so no replication metadata is persisted — the strategy runs when a conflict arises and produces an ordinary entity. And a conflict is data, not a blocking state: an unresolved conflict is stored as an entity at the path and the tree moves on, to be resolved when convenient, rather than halting work until a human intervenes.

5.2. Convergence Is Provided; Consensus Is a Configuration

It is tempting to summarize all of this as “the revision extension gives you distributed consensus.” That would be an overclaim, and a revealing one. What the system provides, out of the box, is convergence: peers that exchange versions and merge reconcile toward a common state, and where they cannot — where two sides changed the same path incompatibly — the divergence is surfaced as data rather than silently lost. Whether they collapse to a single value depends on the merge: a conflict-free strategy converges by construction, while an ad-hoc one is only guaranteed to make the disagreement explicit. What it does not provide as a primitive is consensus in the strict sense — a single agreed linear log with bounded failover, the guarantee a protocol like Raft (Ongaro and Ousterhout 2014) or Paxos (Lamport 1998) is built to deliver.

The interesting part is that consensus is reachable, not as a built-in but as a configuration of the parts already described. The architecture’s exploration of this shows the decomposition cleanly: a leader is a peer holding the write capability; log replication is synchronization push; commitment is a quorum check over peers’ published head pointers; the heartbeat is a subscription with a timeout; and safety rests on content addressing. One can arrange the sync primitives, capabilities, and subscriptions into a spectrum from independent peers, through eventual convergence, through a coordinating hub, to leader-and-followers, to consensus with election. But the same exploration is candid about the cost of this generality. There is no formal safety proof; safety depends on the merge strategy being configured correctly, where a strict consensus protocol hardcodes the rules so it cannot be misconfigured. By default the system gives at-least-once version propagation and eventual convergence, not an exactly-once linear log — a linear log emerges only under a single writer, where the version graph degenerates to a chain. And the consensus pattern is documented guidance, not a shipped extension with conformance tests. So the honest claim is the narrower and, we think, more useful one: the substrate provides convergence and makes consensus configurable; it does not hand you a proven consensus protocol.

Said this way, the genuine strengths come forward rather than getting buried under a borrowed word. The version graph’s integrity is cryptographic, so any peer can verify the history rather than trusting a leader. The model is offline-first: a peer can fork, work disconnected, and reconcile later, which a leader-based protocol forbids by construction. Authority can be partitioned by path, so different subtrees can have different writers without a global leader. Synchronization is capability-scoped at the path level, so different peers legitimately see and reconcile different slices of the same tree — a property the existing distributed systems do not offer. And there is no idle cost: coordination happens when state changes, not on a constant heartbeat.

5.3. Concurrency Correctness Is a Separate Guarantee

One distinction prevents a common confusion. The coordination above is about peers diverging and reconciling over time. It is not the same as a peer being a correct concurrent server in the moment, and conflating the two is exactly the error the slogan invites. The latter is its own property, and it has recently been hardened into a tested, cross-implementation requirement: a peer must demultiplex concurrent requests on one connection correctly, tolerate out-of-order completion, never let one slow request block the others, and never deadlock under reentrant load. A conformance gate built for this caught real failures — independent implementations that were correct single-threaded and fell over under concurrent load, the precise “correct but it collapses” class the gate was built to catch — and folding it into the core conformance profile is what makes “the peer stays a correct server under load” a checked guarantee rather than a hope. The point for this paper is that this is about the peer as a correct server under concurrent load, which is necessary infrastructure for a distributed operating system but is a different claim from distributed consensus. We keep them apart.

5.4. The Open Problems

A distributed operating system is judged partly by the honesty of its account of what it has not solved, and the architecture flags several. Concurrent merges of the same divergence can produce a new divergence — two peers merging the same fork yield merge versions with identical parents but different identities — so what holds is eventual convergence over a bounded number of extra rounds, not single-round convergence, and pinning that down is open. Synchronization that walks the tree can stop at hash references buried inside entity data, so a naive transfer can move a file’s metadata without its content; closing that gap needs content-aware transfer rather than a pure structural walk. And there is a recurring class of cross-peer capability bug that local test fixtures mask, because a capability chain that roots correctly on one peer can come apart when a second peer is in the path — which has motivated a discipline of validating every cross-peer capability flow with a third peer that issued none of its links. These are real, and they are the frontier of the work; a paper that claimed cross-peer coordination was a solved one-liner would be contradicting the architecture’s own candor.

6. The Network, the Fleet, and the Shell

The previous section was about what coordination means; this one is about how it is actually carried, how a fleet of peers is run as a single operating system, and the shell that operates it.

6.1. The Network Is a Transport Substrate

The cleanest way to see the network layer is that the wire is abstract. A peer pushing signed entities to a store and another peer reading them is a transport, whether the store is a live socket, a polled endpoint, or a static file host on a content-delivery network. These differ only in latency, liveness, and direction — not in what flows, because what flows is content-addressed, signed, capability-bearing entities that are identical across every medium. The real axis is not live-versus-static but subscribe-versus-poll: how a peer learns that something changed. A peer that can be pushed to learns by subscription; a peer that cannot — a browser tab, a peer behind a restrictive network — learns by polling and diffing, which is the general pattern for any weak participant.

Two structural results fall out of this and are worth stating because they dissolve problems that look hard. First, a static store is already a relay: a peer that writes to a passive store and another that polls it have communicated, and the protocol cannot tell this apart from active forwarding, so a static host serving signed entities is a relay node by another name. Second, a relay is transport, not authority: when a message passes through a relay, the sender’s capability chain passes through unchanged, and the relay can drop or delay but cannot escalate, because it constructs no link in the chain and enforces only its own ordinary “you may relay through me” grant. Relaying therefore needs no special protocol amendment; it composes from the capability primitives already present.

The network extension is a specified, actively developed normative spec rather than a sketch. The transport family (direct connection, web-socket, request-response over HTTP, and a poll-only variant) is signed off across the implementations. Peer discovery and a name registry have landed as version-one specifications: discovery surfaces candidate peers and mediates an explicit human decision to admit them, defaulting to a zero-configuration local-network backend and failing closed so it never silently connects you to a stranger; the registry resolves a name to a peer through pluggable backends, shipping a local petname scheme first, with no backend privileged over another. A relay extension is specified and implementation-ready. The one piece still genuinely pending is a browser-to-browser transport, which is why peers discovered on a local network connect today over the ordinary transports rather than directly. The honest summary is that the network stack is young relative to a Unix-derived kernel’s networking but is specified and converging, not a set of gaps.

6.2. DEOS Is the Operating System of Your Fleet

This is the move the paper exists to make. A conventional operating system runs one machine; DEOS runs your fleet, and the same mechanisms hold across a spectrum of scales. On one machine it is a single peer, no network involved, used for development or for the programming model alone. On a personal cluster — a home network of a laptop, a desktop, a phone, a server — the peers find each other by local discovery, keep their state synchronized, and share names, and the economy here is that the group is its own registry: the membership of the home network already maps names to peers, so a personal cluster needs no dedicated infrastructure at all. Across the internet the same fleet adds a registry to resolve names and a relay to traverse networks. In an enterprise it adds dedicated registry peers or clusters and, at high population, gossip and distributed lookup. The mechanism does not change across these tiers; what changes is configuration — which is the same observation that made application architecture a design space, now at the scale of the whole fleet. A single rich peer and a multi-peer composition are points on the spectrum of one primitive, not different systems.

That this works is not only a design claim; it has been exercised. The reference workbench’s multi-peer testing brought up symmetric meshes of three and five peers, a five-peer hub-and-spoke, a cascade, and a ring, and all converged; a burst of writes across a five-peer hub delivered every update; saturation testing found and then lifted a delivery ceiling by an order of magnitude with parallel delivery, and the substrate degraded cleanly under stress rather than collapsing. We cite the failure modes too, because they are the honest part. Concurrent edits to the same file diverge and keep each side’s content — by design, since conflict-free merge is the revision extension’s job, not the substrate’s. A peer joining late catches up asymmetrically, receiving some prior state but not all, which is the worst shape a gap can take — partial state without the operator being told — and it argues for explicit reconciliation on join rather than a faith that everything simply arrives. And a chain rejected for want of a capability has, in places, failed silently, the kind of bug that costs an operator days. These are named in the architecture’s own reviews; a fleet operating system is more trustworthy for saying them out loud.

The texture of running a fleet differs from running a box in ways worth drawing out. Access across your own devices is capability-mediated rather than ambient: you reach another of your machines by holding a grant for exactly what you are allowed to touch there, so cross-device access is a set of explicit, attenuable permissions, not a shared login. Adding a person or a device is issuing identity and granting capabilities, not provisioning an account. And the operator’s view of the fleet is, again, just entities: a peer that synchronizes every other peer’s observed-status entities sees the whole network’s topology, including the asymmetries where two peers disagree about whether they are connected, as plain state rather than as hidden disagreements between connection managers. The image the architecture reaches for is session-based computing — edit on the laptop, walk to the desktop, and the work is there, scroll position and all, because the devices are interchangeable windows onto one operating system.

The host operating system, in all of this, is the substrate the peer runs on, and treating it that way is a strength rather than a concession. The peer is a userspace process on Linux, macOS, Windows, or Android; the native footprint it needs is small, on the order of a few thousand lines validated across the implementations; the host’s resources — files, processes, and in time devices and the network — surface through a reserved namespace as ordinary entities. Because the peer is not bound to the hardware, it is close to a pure build artifact: the only thing that must survive a machine is the on-disk identity material, backed up like a private key, and everything else — the local store, the connection state, the history — can be rebuilt, because content addressing makes republication idempotent. A validated deployment dry-run bears this out, reconstructing a peer’s content to byte-identical hashes after a full wipe, with identity preserved. There is also a more radical model, in which an entity peer runs on bare metal as the lowest layer — the operating system not on top of a host but in its place. We flag it as exploration: it is a coherent direction the substrate’s small native footprint makes imaginable, not a documented or implemented target, and we name it to mark the edge of the space rather than to claim it.

This is also the seam where DEOS ends and the field-map view begins (see The Decentralized Systems Landscape). Your fleet is one operating system; it connects to other people’s fleets — their own distributed operating systems — and what happens across that seam, the sharing and exchange and convergence at internet scale, is the subject of The Decentralized Systems Landscape rather than this one. DEOS holds the operating system you run; the network of operating systems is the next view out.

6.3. The Shell

Every operating system has a shell, and DEOS’s is not a convenience layered on top but an architectural layer in its own right, standing to the SDK as the SDK stands to the protocol. Its working directory is the entity tree — the current path is a tree path, not a host-filesystem path — and its verbs are a one-to-one projection of the SDK and handler operations into named commands. This is what lets a terminal, a graphical panel, and an embeddable library be presentations of one shell rather than separate programs.

A real shell binary runs today, with an interactive loop and a one-shot mode, line editing, completion against live tree contents, and persistent history; its core verbs and most of its extension-derived verbs work against both local and remote peers, with a connect that performs a genuine handshake and a copy that moves an entity across peers. Three independent implementations grew shells and converged on substantially the same surface, which is the same convergence-as-evidence the corpus leans on elsewhere. What is missing is composition: pipelines that flow typed entities from one command to the next are designed but not built, and the packaged single-shot utilities are a distribution decision still pending. The distributed shell is real and cross-implementation, with its compositional layer the open frontier.

7. The Collapsed Infrastructure Stack

A standard production deployment today is an assembly: a version-control system for state, a request protocol for dispatch, a message queue for events, a database for typed data, an orchestrator for namespacing and authorization, and — between all of them — an integration layer of pipelines, service meshes, APIs, and authentication flows. The parts are mature and the assembly works; the integration is where the operational complexity lives.

Seen through the primitive analysis of Convergent Evolution, each platform covers part of the primitive set and none covers all of it, and the integration layer is precisely what compensates for the gaps: it translates event semantics between the queue and the request services, reconciles build state with deployed state, and carries authorization across the boundaries between systems. This is the integration tax (see Convergent Evolution) — the cost of building on platforms that each sit off the coherent set of primitives, so that external machinery must bridge between mismatched coverage. The standard peer reaches the coverage of all six primitives in one substrate, so there is no integration layer because there is nothing to integrate: state, dispatch, events, queries, and authorization are properties of the same content-addressed substrate, and a cross-extension interaction is mediated by the protocol’s own dispatch rather than by glue between systems.

Two things keep this from being a slogan. First, it is not a recommendation to discard a working stack: the existing platforms are battle-tested and deeply embedded, the substrate’s claim is structural, and its operational maturity is younger. The honest framing is that the modern stack is an approximation, distributed across platforms and reconnected with integration, of what the substrate provides in one piece — a way of seeing where the substrate sits, not a demolition order. Second, adoption is incremental and through bridges: a peer can wrap an existing database or service and bring its data into the entity model, so a deployment absorbs the substrate piece by piece rather than all at once. That incremental path, and the bridge mechanism that carries it, are the developer’s concern and are developed in Application Architecture; here it matters only as the answer to “must I replace everything to begin,” which is no. Consistent with the substrate principle, none of this should be read as the core mandating these particular extensions — it is the reference operating system’s coverage, against the reference modern stack.

8. Related Work

DEOS sits in a lineage of distributed operating systems and a neighborhood of contemporary infrastructure. We place it against the closest of each.

Plan 9 and Inferno. Plan 9 (Pike et al. 1990) and Inferno (Dorward et al. 1997) are the closest architectural predecessors, and the resemblance is deep: both commit to a single coordination abstraction, where Plan 9 and Inferno make everything a file and DEOS makes everything an entity. The reduction discipline — replace mechanism with one substrate — is the same shape; the substrate differs, untyped bytes in a hierarchical namespace versus typed, content-addressed entities in a tree. What DEOS gains over the file abstraction is exactly what content addressing, types-as-data, and capability-based authorization add: integrity and deduplication from content-derived identity, structural validation at dispatch, and per-operation decentralized authority where Plan 9 carries conventional permissions.

Urbit. Urbit (Yarvin et al. 2016) is the closest in vision: both build a complete personal-computing environment from primitive coordination, both independently arrived at typed entities as the unit, and both treat the personal server as central. The divergence is in what each commits to. Urbit fixes a particular computational substrate — a small deterministic instruction set and a language above it — and derives determinism and replay from it; DEOS commits instead to typed content-addressed data and derives verifiable cross-peer convergence from content addressing. The trade-off is real and the two papers’ systems sit on different sides of it; DEOS’s substrate principle, which lets a different computational layer be composed over the same core, is a direct response to the cost of a fixed one.

Kubernetes. Kubernetes (The Kubernetes Authors 2014) and the container-orchestration lineage operate at a different level: namespace organization, container dispatch, and role-based access, without content addressing or typed application interfaces, with the container rather than the entity as the unit. It is mature production infrastructure, and the relationship is compositional rather than competitive — a standard peer can run as a workload on Kubernetes, providing entity-level coordination above the container-level coordination, the two operating at different abstraction levels.

NixOS and microkernels. NixOS (Dolstra et al. 2004) shares content-addressed reproducibility, reached at the package and build level; the standard peer extends that property past build artifacts to all entities, so what NixOS does for packages the substrate does for application data, types, and capability tokens. Microkernel architectures such as seL4 (Klein et al. 2009) and the modular design of Fuchsia (Google 2016) share the shape of a minimal core plus composable services with capability-based authorization; DEOS carries that shape to the distributed case, with content addressing and typed dispatch as additional substrate properties. The older distributed operating systems — Amoeba (Tanenbaum et al. 1990), Sprite (Ousterhout et al. 1988), and the Andrew File System (Morris et al. 1986) — pursued the single-system-image goal across machines that DEOS pursues across a fleet, and a fuller survey would engage them at length; the selection here is the structurally closest, and broadening it would deepen the comparison without changing the argument.

What recurs as DEOS’s distinguishing addition, across all of these, is the one developed earlier: the operating system’s running state is itself self-describing, content-addressed entities in the same tree it serves, so the system observes and recovers itself by being read. That property, more than the kernel-service mapping, is what the lineage does not already have.

9. Discussion

9.1. What the Paper Is and Is Not

This paper is a structural account of the entity system viewed as a distributed operating system, written for systems researchers and for teams who would run on the substrate. It is not an operations manual, and it is not a claim that DEOS is the operating system the substrate must become. It is one operating system the substrate can host — the architecture’s reference build — described as a region of a larger space, with the maturity of each part marked rather than smoothed.

9.2. What Is Settled and What Is in Motion

Settled: the core protocol and the six primitives beneath it; the kernel-service mapping, which follows from the extensions covering the operating system’s coordination concerns; the property that a peer’s running state is self-describing entities in its own tree, with restart-equivalence normative; and convergence as what cross-peer synchronization provides. These rest on running code and, for the protocol, on a conformance oracle that has been exercised across many languages.

In motion: consensus is reachable as a configuration of the synchronization primitives but is explored rather than proven or shipped, and the system provides convergence by default, not a linear log. The network stack is specified and converging but young — discovery and a registry have landed, relay is ready, a browser-to-browser transport is pending. The shell runs and is cross-implementation, but its compositional layer is unbuilt. Several cross-peer coordination problems are open and named. And behavior at production scale is demonstrated in multi-peer testing but not in long-lived deployments under real load. None of this undercuts the operating-system frame; it dates it.

9.3. A Note on Posture

The stance throughout is exploratory and pluralist, by choice. The substrate does not care which operating system you compose on it, and this paper maps the reference one rather than legislating it. The question it really pursues — what is an operating system, and how far does this substrate carry the idea — is a question about frames of reference, and the honest answer is a map of what becomes possible, not a verdict on the one right way. Other compositions are possible; a community could build a different operating system on the same hooks and still interoperate at the core. We think the reference build is a good one, and we say where it is strong and where it is unfinished, but the offer is a substrate to build operating systems on, not a finished operating system to adopt.

9.4. Limitations

• DEOS is one operating system the substrate can host, presented as the reference build; the operating-system framing is a frame of reference, not a claim of identity, and other compositions are possible.
• The strongest version of the “never leave the system” idea is an option the substrate offers, not how anyone runs today; real deployments retain native code and lower-level infrastructure.
• Consensus is configurable, not provided as a proven primitive; convergence is what the substrate guarantees.
• The network stack and the shell’s composition layer are young, and several cross-peer coordination problems are open; production-scale behavior is not yet established.
• Generated under prompt-and-review: this paper, like the rest of the corpus, the supporting implementations, and the architectural specifications, is LLM-generated under direction from the author — the author prompts, evaluates, redirects, and approves rather than authoring text directly. The methodology this enables is described in The Entity Core Protocol.

10. Conclusion

The entity system, viewed as a distributed operating system, is the operating system of your fleet rather than your machine. The standard peer — the core protocol plus the substrate-bridge extensions — provides what an operating system coordinates, from the same six primitives, in one typed and content-addressed substrate, and the mapping from kernel service to extension is concept-for-concept. The work this paper does is to frame that correctly. DEOS is one operating system the substrate can host, the reference build over an extensible core, not the operating system the substrate is. Its kernel is not an image but a live configuration recorded as entities in its own tree, so the system describes, observes, and recovers itself by being read. And its distribution is the default rather than an addition: the same coordination runs from one machine to a home network to a federation, and the operating system is the abstraction over all of them.

We have been honest where honesty is load-bearing. Cross-peer synchronization provides convergence, with consensus reachable as a configuration rather than handed over as a proven primitive. The network stack is specified and converging — discovery and a registry landed, relay ready, the shell running across three implementations — but it is young, and several coordination problems are open and named. The protocol’s convergence across languages is the proven half of the system’s story; whether people build operating systems on it, and converge on shared ones, is the open half, and no specification forces it.

Three invitations sit alongside the model, by design. An operating-system coordination concern that no extension can host would test the kernel-service mapping, and we would want to know which one. A coordination need the synchronization gradient cannot reach — something the convergence-to-consensus spectrum genuinely cannot express — would mark the substrate’s edge. And the largest question is not structural: whether the substrate’s small native footprint and self-describing state make it worth running a fleet on at all is a question running fleets will answer, not a specification. The substrate is offered as a thing to build operating systems on, with its early state stated plainly, in the belief that the honest version is the one worth offering — and that where this operating system ends, at the seam between your fleet and others’, the next view of the system begins.