1. The librarian and the swordsman

Neal Stephenson’s Snow Crash has a virtual librarian who organizes and retrieves information for anyone who knows how to ask. The desktop needs a similar layer: a simple, consistent way for compute boards to put data somewhere and get it back later, without caring which physical drive holds it.

Entry 225 sized the storage cells. This entry picks the interface between compute and storage.

2. Three ways to talk to storage

Compute can see storage in three basic ways.

Block device. The storage cell looks like a raw disk. The compute board runs a filesystem on top of it. This is low-level and fast, but it ties the compute board to the storage cell. If the storage cell is unreachable, the filesystem blocks or crashes.

Network filesystem. The storage cell exports a directory tree over the network. Multiple compute boards can mount it. This is familiar, but network filesystems are sensitive to latency, partitions, and single points of failure.

Object store. The storage cell exposes buckets of objects, each with a key. Compute boards read and write objects over a simple protocol like S3. There is no mounted filesystem; applications ask for objects by name.

3. Why object storage fits

The desktop is not a data center, but it has some of the same problems: multiple clients, unreliable hardware, and a need to survive failures without human intervention.

Object storage is built for this. It is stateless from the client’s point of view. A compute board can retry a failed request. Objects can be replicated across storage cells. New storage cells can be added without reformatting anything.

It also matches how Earth observation applications are written on the ground. Many pipelines already use object stores for imagery archives. Running the same pattern in orbit reduces the porting effort.

4. What the first implementation looks like

The first desktop storage layer could be an S3-compatible object store running on the storage cells, with compute boards accessing it over the desktop network. Each compute board keeps a small local cache for objects it is actively processing, but durable data lives in the object store.

Replication is set to at least two copies across different storage cells. If a cell fails, the data is still available, and the robot can replace the failed drives without the customers noticing.

5. What is still to decide

The exact object store software, the network protocol details, and the consistency model are still open. These are important but separable from the architecture choice. The key decision is that the interface is object storage, not block devices or a shared filesystem.

What this changes

  • Compute and storage communicate through an S3-compatible object store.
  • This choice matches cloud-native Earth observation pipelines and tolerates hardware failures.
  • Local compute boards cache active data, but durable storage lives in replicated objects.
  • The next entry can pick the object store software or the consistency model.