Nondominium object

From OVN wiki
(Redirected from NDO)
Jump to navigation Jump to search

Also referred to as NDO.

The Nondominium Object is a new way to represent Resources for a complex world, a new peer-to-peer infrastructure designed to match the real complexity of the economy we are already living in.

Context

The dominant institutions of the industrial era, corporations, markets, property registries, ERP systems, were built for a world of relative stability and manageable complexity. They encoded a particular assumption about resources: that a resource is a static thing, owned by someone, located somewhere, with a fixed description. This assumption worked well enough when the economy moved slowly, when supply chains were legible, when things were created in centralized factories and distributed through centralized markets.

That world is dissolving. The complexity theorist Yaneer Bar-Yam has shown that hierarchical systems have cognitive ceilings, there is only so much complexity a centralized decision-maker can absorb before coordination breaks down. We are living through that breakdown now. The economic structures we inherited were not designed for an economy of distributed knowledge, open-source hardware, networked fabrication, and peer-to-peer collaboration at global scale. They are straining under the weight of their own inadequacy.

Something new is needed. Not just a better platform, but a better primitive, a more truthful way of representing what a resource actually is.


Resources Are Not Static Things

Consider a hardware device that begins as an idea in a maker community. At first, it is nothing but a name, an intention, a property regime (who will govern it, and how). Then it becomes a design, a set of files, specifications, governance rules. Then it becomes a prototype, validated by peers. Then it becomes a mature, production-ready design that anyone with a local fabrication shop can reproduce. Then it is in active use across dozens of communities. Then, years later, it is superseded by a better version and enters a kind of archival memory, not deleted, but no longer active.

This is not a static thing with an owner and a location. It is a living process, an entity that moves through emergence, maturity, use, and eventual retirement. Current software systems have no vocabulary for this, not even the NRP-CAS, which has inherited from traditional ERPs. They can describe a product in its finished state or a fabrication process, or a scripted process. They cannot describe the complex journey from idea to artifact to legacy, in conjunction with the distributed human activity that makes that journey happen.

The NDO project is building exactly this vocabulary.


The Nondominium Object: A Three-Layer Architecture

At the core of the Nondominium system is a new kind of digital object — the Nondominium Object (NDO) — designed to represent resources as they actually are: dynamic, social, and evolving.

The NDO is structured in three layers, each corresponding to a different register of complexity. The metaphor is the human brain, which evolved not as a single organ but in layers, each built on and coupled to the previous.

  • Layer 0 — Identity is the permanent foundation. From the moment a resource is conceived — even before it has been designed, built, or described — it receives a stable, cryptographically-anchored identity. This identity never changes, never disappears. It is the resource's fingerprint through all its transformations. At the end of a resource's life, when all activity has ceased, the identity remains as a tombstone: a permanent record that the thing existed, who created it, and what became of it.
  • Layer 1 — Specification is activated when the resource has a form worth communicating. This is the design, the blueprint, the governance rules — the *description* of what the resource is and how it should be governed. In the context of distributed fabrication, this layer is the product: a 3D file shared openly is not documentation for a physical object; it *is* the shareable artifact that anyone, anywhere, can instantiate locally. This layer can be updated, versioned, and forked, while the identity beneath it remains stable.
  • Layer 2 — Process is activated when there is active economic work happening around the resource. This is where contributions are tracked, custody is transferred, use events are recorded, and participants receive cryptographic receipts of their participation. It is the layer of economic life — the metabolism of the resource's existence in a community.

These layers activate progressively, in response to the resource's actual complexity. A simple tool being lent between neighbors does not need the overhead of a full process layer. A hardware standard being developed across fifty fabrication networks needs all three. The system adapts its structure to the coordination demands of each situation, rather than imposing maximum overhead on every resource regardless of its nature.


Complexity Economics and Why It Matters

This architecture is not an aesthetic preference. It follows directly from what complexity economics has been teaching us for decades.

Yochai Benkler showed that peer-to-peer production has a fundamental economic advantage: lower information opportunity costs. When agents at the edges of a network can sense and act on local information directly — without routing it through central aggregators — coordination is faster, cheaper, and more accurate. The Nondominium Object is built on this insight: it pays the coordination cost that each resource actually needs, and no more.

Bar-Yam showed that systems which pre-classify their contents at creation time are FSM-like — finite state machines that quickly become inadequate as social complexity grows. The Nondominium Object refuses this trap. It begins as nearly nothing and grows in structure as its context demands. The full complexity of a resource's life cannot be known at the moment of its creation. The system is designed to discover, not to pre-empt.

This is what we are calling **Complexity Oriented Programming** — a nascent paradigm that inverts the assumption of every dominant programming tradition. Where Object-Oriented Programming hides complexity behind interfaces, where Functional Programming eliminates side effects, COP models complexity faithfully and works with it as the primary material. The programmer is not a god designing a closed system; the programmer is an ecologist designing conditions for emergence. Holochain — the peer-to-peer infrastructure on which Nondominium is built — is one of the most mature expressions of this paradigm in practice: there is no global state machine, no central server, no single point of control. Each agent runs local rules, and coherent economic coordination emerges from the aggregate.


Built on Foundations That Already Embrace Complexity

The Nondominium Object does not emerge from a vacuum. It is built on a stack of technologies that were each, independently, designed to handle the kind of complexity that centralized systems cannot. Their convergence is not accidental — it reflects a shared recognition that the economy of peer production requires infrastructure that reasons about the world differently.

  • Holochain is the distributed computing foundation. Unlike blockchain systems, which achieve consensus by forcing every participant to agree on a single global state, Holochain takes the opposite approach: there is no global state. Every agent maintains their own cryptographically-signed chain of actions, and data is stored on a distributed hash table where each piece of information is held by the agents most relevant to it. This is the infrastructure equivalent of complexity-oriented thinking: coherent economic coordination emerges from local rules and agent interactions, without any central orchestrator. The system is resilient by architecture, not by redundancy — it does not survive failures because it has backup servers; it survives because it has no single point of failure to begin with. For the Nondominium Object, Holochain provides the substrate: the stable, permanent, cryptographically-anchored identity of every resource, the append-only record of every action taken on it, and the distributed storage of every asset associated with it.
  • ValueFlows is the economic vocabulary. It is an open standard for describing economic activity — who does what, with what resources, for whom, and how value flows as a result. Where conventional accounting systems describe *states* (balances, inventories, ownership records), ValueFlows describes *events*: economic actions that transform resources, link agents, and leave an auditable trail. This is complexity economics translated into a data standard. A resource is not a static entry in a ledger; it is the accumulation of all the events that have ever touched it — produced, transferred, used, repaired, combined. This vocabulary maps directly onto the Nondominium Object's lifecycle: every transition between stages, every contribution, every custody transfer, is a ValueFlows event. The full history of a resource is readable from first principles, without trusting any single authority to have kept it accurately.
  • hREA (Holochain Resource-Event-Agent) is the bridge between these two — an implementation of the ValueFlows standard built natively on Holochain. It provides the working economic model: agents interacting with resources through accountable events, commitments being made and fulfilled, processes consuming inputs and producing outputs. In COP terms, hREA is the layer where relational events flow through the agent graph, typed and traceable, rather than being hidden behind the walls of an organization's internal systems. For Nondominium, hREA provides the Layer 2 machinery: the economic process through which contributions are tracked, receipts are issued, and the distributed community around a resource becomes legible to itself.

Together, these three technologies constitute a stack that was already, before Nondominium existed, oriented toward the same epistemological challenge: how do you build software for a world where complexity is the primary material, not the problem to be eliminated? Nondominium's contribution is the architectural layer above them — the Nondominium Object — that gives this stack a meaningful economic primitive, a unit of analysis that can represent a resource through its entire social life.


A Cornerstone for the Economy That Is Coming

The three-layer Nondominium Object is not a clever data structure. It is a claim about what the economy is, and what infrastructure it needs.

We are moving, unevenly, incompletely, but irreversibly, toward an economy organized around open knowledge, distributed fabrication, peer-to-peer collaboration, and commons-based governance. The technologies that make this possible already exist: open-source hardware, networked fabrication, decentralized identity, cryptographic accountability. What has been missing is the economic primitive that makes them legible to each other, the object that can represent a resource as it actually moves through a P2P economic ecosystem.

The Nondominium Object is that primitive.


Consider what becomes possible when the ERP systems that currently run industrial-era organizations are rebuilt, or extended, around this kind of object. Today, an ERP is a closed ledger: it tracks resources within an organization's boundary, invisible to the network of communities and agents those resources might otherwise serve. A Nondominium-aware ERP would not track ownership. It would track stewardship: who is responsible for a resource at this moment, what governance rules govern its use, who has contributed to its development, and what the community of practice around it looks like. The organizational boundary dissolves, and the resource becomes legible to the wider network. Open value networks, peer communities creating value together, distributing it fairly, and governing their commons collectively, gain the infrastructure they need to account for themselves.

This is not a distant vision. The patterns are already present in the communities that have built Linux, Wikipedia, and the open hardware movement. What those communities lack is not ingenuity or motivation. They lack the infrastructure that makes their economic activity as legible and accountable as the activity that happens inside a corporation. The Nondominium Object is a step toward that infrastructure.

The wicked problems of our time — inequality, ecological breakdown, the collapse of institutional trust — will not be solved by better management of the industrial era's institutions. They will be addressed by the emergence of new forms of economic organization that can handle the complexity of the world we actually inhabit. Complexity demands distributed intelligence. Distributed intelligence demands a new kind of resource object.

That is what Nondominium is building.


Nondominium is an open-source project building peer-to-peer infrastructure for the commons economy. The architecture described here is under active development.


Implementation

The NDO is designed as a three-layer structure, where each layer corresponds to a different register of complexity and is activated independently in response to the resource's current context.

Layer 0: Identity — The Permanent Anchor

Layer 0 is the prima materia in its most essential form. It is the minimum viable NDO — the smallest structure that gives a resource a stable, cryptographically-anchored identity in the DHT.

Structure:

 struct NondominiumIdentity {
     name: String,
     initiator: AgentPubKey,
     property_regime: PropertyRegime,
     resource_nature: ResourceNature,
     lifecycle_stage: LifecycleStage,
     created_at: Timestamp,
     // Optional: a brief human-readable description
     description: Option<String>,
 }

Key properties:

  • The action hash of this genesis entry becomes the permanent, stable identity of the NDO — a DID-like namespace that all other layers and capabilities link to
  • It is never voided — Holochain's append-only DHT makes deletion impossible, and this is correct: the identity of a resource that ever existed should be permanently accessible
  • The only field that evolves is lifecycle_stage, updated through governance-validated transitions
  • At end of life, Layer 0 alone remains as the tombstone: a permanent record that the resource existed, who created it, its nature, and when it concluded


When Layer 0 exists alone:

  • A stub registration: "this thing exists, I intend to develop it"
  • A tombstone: all other layers have been archived, the identity remains
  • The minimal representation of an idea that has not yet been designed


Layer 1: Specification — The Form

Layer 1 is activated when a resource has a form that needs to be communicated to others — when the resource is ready to be described, shared, peer-reviewed, or replicated.

Activation mechanism: Creation of an NDOToSpecification link from the Layer 0 identity hash to a ResourceSpecification entry.

Layer 1 carries:

  • Design intent and description (what the resource is)
  • Governance rules (who can access it and how)
  • Assets: files, 3D models, code references, digital integrity manifests, documentation links
  • Tags and categories for discovery

When to activate Layer 1:

  • The resource has a design worth sharing with others
  • Distributed fabrication is intended (the spec is the product)
  • Peer review or validation of the design is needed
  • The resource needs to be discoverable by category or tag

When Layer 1 becomes dormant:

  • The resource enters hibernation or end of life
  • The specification is archived (is_active: false)
  • The NDOToSpecification link remains readable (DHT is append-only), but no new updates are made to the spec

The design file as the product: In the distributed fabrication context (cosmolocal production), the Layer 1 specification is the product in the most meaningful sense. When a hardware design reaches Stable lifecycle stage, anyone with a 3D printer and the fabrication spec can produce a local instance. The spec is not documentation for a product — it is the shareable, replicable artifact. This is the nondominium model's most radical departure from capitalist product logic.

Layer 2: Process — The Activity

Layer 2 is activated when there is active multi-agent economic work around the resource — when contributions are being tracked, custody is being transferred, use events are being recorded, or commitments are being made.

Activation mechanism: Creation of an NDOToProcess link from the Layer 0 identity hash to a ValueFlows Process entry.

Layer 2 carries:

  • EconomicEvent records of all actions taken on or with the resource
  • Commitment records of agents' intentions to perform future actions
  • Claim records linking commitments to fulfilling events
  • PrivateParticipationClaim (PPR) records issued to participants
  • Labor contribution tracking for OVN-compliant attribution

When to activate Layer 2:

  • A second agent becomes involved (multi-agent coordination begins)
  • Development work begins in earnest and contributions need to be tracked
  • Custody transfers are required
  • Use events or resource access need to be recorded
  • PPRs need to be issued (any economically accountable interaction)

When Layer 2 becomes dormant:

  • The process concludes: all commitments are fulfilled or cancelled, all events are finalized
  • The resource enters hibernation (process paused, not terminated)
  • End of life: process is formally concluded with terminal events


Layer Composition Across the Lifecycle

The NDO requires their explicit separation between LifecycleStage and OperationalState:

  • LifecycleStage — the maturity or evolutionary phase of the resource as an artefact. Advances rarely and (mostly) irreversibly, driven by significant events (design completion, peer validation, fabrication, end-of-life declaration). Lives on the NondominiumIdentity (Layer 0).
  • OperationalState — what process is currently acting on a specific resource instance. Cycles frequently as processes begin and end. Managed by the governance zome. Lives on the EconomicResource instance (Layer 2).

The key distinction: transport, storage, and maintenance are processes that can apply to a resource at any lifecycle stage. A Prototype can be InTransit (moved between R&D labs). An Active resource can be InStorage, InTransit, or InMaintenance simultaneously with its lifecycle stage. These are not lifecycle milestones — they are transient operational conditions.


LifecycleStage Enum

Lives on NondominiumIdentity. Describes what the resource has become, not what is happening to it right now.

 pub enum LifecycleStage {
   // --- Emergence Phase ---
   Ideation,       // Placeholder: name and intent only. Layer 0 alone.
   Specification,  // Design/requirements being written. Layer 1 activating.
   Development,    // Active construction, prototyping. Layers 0+1+2 active.
   Prototype,      // PoC exists, not production-ready. Layers 0+1+2 active.
   // --- Maturity Phase ---
   Stable,         // Production-ready, design is replicable. All layers active.
   Distributed,    // Being actively fabricated/used across the network.
   // --- Operation Phase ---
   Active,         // In normal use. All layers active.
   // --- Suspension ---
   Hibernating,    // Not end-of-life — dormant. Layers 1+2 dormant, L0 active.
   // --- Terminal ---
   Deprecated,     // Superseded by a newer version. Links to successor.
   EndOfLife,      // Concluded. L0 tombstone, L1 archived, L2 concluded.
 }


Note: Maintenance and Reserved are not lifecycle stages — they describe transient operational conditions and belong in OperationalState (Section 5.4).


Lifecycle Transitions and Governing Events

Each transition between lifecycle stages is driven by a VfAction economic event, validated by the governance zome acting as state transition operator. This is consistent with the existing governance-as-operator architecture.



To be completed...