The Model

A store is anything that responds to read and write.

A tree of data in memory is a store. So is an HTTP endpoint, a system clock, a database, or a random number generator. The differences between these systems (protocol, client library, error handling, testing story) are real, but they're accidental. At the level that matters to the application, they're all the same thing: data behind an address.

StructFS makes that sameness the foundation. A store is a store is a store.

Every store responds to the same two operations. That's the entire interface.

No DELETE, no PATCH, no LIST, no SUBSCRIBE. This seems like a limitation until you see why it isn't: paths carry meaning.

HTTP needs many verbs because URLs are nouns: you need different verbs to do different things to the same noun. In StructFS, a path can name an action just as easily as it names a resource. Writing to users/alice/deactivate is as expressive as DELETE /users/alice, but the deactivation is itself a path, one that can be composed, proxied, or intercepted with the same mechanisms as everything else.

Two operations isn't a constraint that limits what you can express. It's a constraint that forces expressiveness into the one place where it composes: the path.

Stores compose into a tree.

Mount a store at a path prefix, and all reads and writes under that prefix route to that store. Mount several stores at different prefixes, and you have a unified namespace:

A store doesn't know where it lives in the tree. When you read /api/items, the HTTP store sees items, not /api/items. This is what makes stores swappable: attach a mock at /api instead of the real client, and nothing else changes.

The tree is the wiring diagram of your system. You can rewire it without touching application code.

This is the mechanism that makes two operations sufficient for complex systems.

When you write to a store, the return value isn't an acknowledgement; it's a path. That path might be the same one you wrote to, confirming the write. Or it might be a new path, a handle you can read from later.

The write queued work. The read collected the result. The interface stays synchronous (no callbacks, no futures, no event loops) but the interaction is multi-step.

The same pattern models file handles, subscriptions, sessions, transactions: any interaction that spans multiple operations. You don't need OPEN, CLOSE, SUBSCRIBE, EXECUTE. Each is just a path you read from or write to.

Classic filesystems deal in bytes. Infinite flexibility, zero interoperability.

StructFS deals in structured values: the same types your programming language already gives you, and the same model that every serialization format converges on. JSON, CBOR, MessagePack, Protocol Buffers: they all encode the same core shapes. StructFS makes that shared model native. When a store returns a value, it's already structured. When you write a value, there's no encoding step. The structure is the data.

This is the departure from Plan 9. 9P gives you a universal namespace over byte streams; you still need to agree on a wire format between every producer and consumer. StructFS gives you a universal namespace over structured data. The serialization format is an implementation detail of the transport, not a concern of the interface.

Structured values solve the data boundary. Paths need the same treatment.

A path component in StructFS must be a valid identifier in every language that might handle it: Rust, Go, JavaScript, Python, and anything else that touches the tree. This is the same problem HTTP faces with URLs: arbitrary strings need to be constrained to a form that survives every context they pass through.

HTTP's answer is percent-encoding. StructFS's answer is Namecode, an encoding that turns any Unicode string into a valid UAX 31 identifier. Think Punycode for variable names.

The encoding is reversible, deterministic, and idempotent. Strings that are already valid identifiers pass through unchanged; most path components in practice never get encoded at all. But when a path component comes from user input, an external system, or any source that might contain spaces, punctuation, or emoji, namecode guarantees it survives the round trip through every language boundary in the system.

This is the same role URL encoding plays for REST. Without it, HTTP URLs would break the moment they crossed a context boundary. Namecode gives StructFS paths the same guarantee: any path, any language, any store.

Two operations and structured values. How does this scale to real systems?

Through conventions at increasing levels of abstraction:

Each level builds on the one below without new operations or new primitives, just conventions about what paths mean and how they relate. A store that implements a complex protocol is still a store that responds to read and write.

This is why two operations are sufficient. The complexity lives in the paths and the values, not in the verb set.

StructFS sits at an intersection of three traditions.