Introduction

There is a lot of confusion between the sharing, the collaborative and the participatory economy. In fact, you can see it on this Wikipedia page. Here we propose some distinctions based on experience within the Sensorica OVN and other peer production systems in operation today.

The semantic separation between the terms sharing economy and the other two seems to be greater than the semantic separation between collaborative economy and participatory economy. In other words, people tend to use the terms collaborative economy and participatory economy interchangeably, but sometimes in opposition to the current use of the term sharing economy. This Harvard review, states that sharing economy is a misnomer, and with their conclusion to replace it with the term access economy. The term micro-service economy is also used in the literature.

When we speak about the sharing economy we put the emphasis on assets (material or immaterial) that are "shared" (redistributed or circulated) among individuals and/or organizations, which in turn share information among themselves about needs and offers, about the location (physical or virtual) of these assets and about rules of engagement or terms of use. The term sharing is used somewhat abusively, not necessarily as a reciprocal relation. In this context, sharing can be a transfer (gift or barter, monetary exchange), or rent (payment for use). The use someone makes of these assets is, for the most part, irrelevant, as long as the integrity of the asset is preserved (when it is rented), and the access respects the basic rules of engagement. The use can be personal or part of a commercial activity and the provider can be an individual or an organization. Some platforms that facilitate access and transactions can be agnostic to that, some of them use strict rules to enforce p2p, b2b or a combination. Critics of the sharing economy propose alternative terms such as access economy, rental economy or micro-service economy. These critics focus on the lack of reciprocity as well as on the lack of social externalities that are normally created through reciprocal sharing.

Basic characteristics of Resources of type Nondominium

Take into consideration Resources / OVN wiki and Resource Type / OVN wiki

• Permissionless Access: Anyone can Access Resources under defined rules

• Organization Agnostic: Exist independently of any single organization. They are associated Agents (individuals), according to their Roles.

• Capture Resistant or Unenclosable: No Agent or group of Agents can control or delete Resources, they cannot be captured or monopolized

• Self-governed: Rules driven associated directly with the Resources, which govern interactions or Actions that Agents can take, as defined by the system.

  • Roles: Set of Activities or types of interactions that an Agent can perform with respect to the Resource. Also related to Custody (responsibility), maintenance or improvements (obligations).

  • Access control: Rules associated with Roles of Agents, membranes, to grant permissions to interact with Resources. Is pseudonymous.

• Fully specified: Machine readable in terms of function, design architecture, standards (dimensions, tolerances, quality), etc.

• Hard to Clone: Governance, set of rules and incentives to make unnecessary copying of a resource unlikely.

• Shareable by Default: Resources are designed for sharing

Document Metadata

• Title: Nondominium — Product Requirements Document

• Version history, authorship, date of last update

Executive Summary

Nondominium is a foundational infrastructure project aimed at enabling a new class of Resources that are organization-agnostic, uncapturable, and natively collaborative. These Resources are governed not by platforms or centralized authorities, but through embedded rules, transparent peer validation.

The project’s central goal is to support a sharing economy, while overcoming structural flaws seen in traditional sharing platforms: centralization of power, imposed rules, prone to censorship, unsuitable regulations, and a monetization scheme, including monetization based on users’ data.

Built on the Holochain framework and using the Valueflows language, Nondominium allows any Agent (individual in this case) to interact with these resources (perform a set of possible Actions as described below) in a permissionless but accountable environment.

Key system features include:

• A decentralized identity system with pseudonymity.

• A programmable access and governance layer embedded in each Resource

• UI/UX principles that support finding, planning the use of and interacting with Resources.

By embedding governance into the digital substrate of Nondominium Resources, we lay out the groundwork for a truly decentralized sharing economy.

Objective & Goals

Main Objective

Develop a new class of Resources that are:

• Organization-agnostic (not owned or controlled by any Agent or organization),

• Capture-resistant (uncapturable and resilient to monopolization),

• Permissionless and shareable by default, and

• Integrated with a governance system to diminish the frictions due to mistrust between Agents, on decentralized infrastructure (e.g. Holochain).

Nondominium aims to provide an infrastructure for a truly decentralized sharing economy that overcomes the structural and incentive problems observed in current centralized platforms.

Use Valueflows and Holochain for implementation. 

Supporting Goals

1. Digital Representation of Nondominium Resources

   • Define machine-readable, digital and material Resources as Nondominium, implemented as a DHT entry on Holochain.

   • Ensure support for location, Primary Accountable Agent metadata, and Actions as defined by Valueflows (described below).

2. Proof-of-Concept Implementation

   • Build and test a prototype of a distributed platform that supports Nondominium, which means that it supports the sharing of Resources in the Nondominium property regime (seen as distinct from private, public or shared property regimes), using Valueflows and Holochain as core backend technologies.

3. Governance and Incentive Layer

   • Implement all Actions related to material and digital Nondominium Resources, as defined in Valueflows, as described below.

   • Restricting Actions of Agents on Nondominium Resources shared within the network if they haven’t already created a new Nondominium Resource themselves. Creating a new Nondominium Resource is in essence 

     • transferring one’s material Resource under private property regime into the Nondominium property regime and listing it for access, circulation, use on the Nondominium network, or 

     • making available to the network a digital asset under the digital Nondominium regime, an ultimate form of digital commons. 

4. Identity and Role System

   • Develop an Agent identity infrastructure that supports:

     • Pseudonymmity

     • Credencials

     • Identification information (encrypted) such as address, phone number and perhaps a picture of a Government issued ID.

   • Develop a basic Role system

     • Simple Agent, who can only search and find listed Nondominium Resources and can also create new Nondominium Resources

     • Accountable Agent, who can signal the intent of accessing or interacting with a Resource under Nondominium and make a transaction, and becoming the Primary Accountable Agent or the Custodian of a material Nondominium Resource.

     • Primary Accountable Agent, who is the Custodian of a material Nondominium Resource

   • Develop a role-based access to Nondominium Resources

5. User Interface Patterns

   • Identify and validate UI patterns that facilitate finding and accessing digital and material Nondominium Resources.

   • Produce UI/UX prototypes to test core interaction metaphors, implementing all Actions specified by Valueflows. 

Scope

Proof-of-Concept Development

We’ll focus on producing a minimal, functional prototype of Nondominium. Specifically, it includes:

1. Digital Representation Layer

• Define a standard model for “Nondominium” as Resources:

  • Traceable

  • Signal intent to access

  • Accessible using Actions, including transactions, as defined by Valueflows, described below

  • Includes governance metadata, which describes a promise, requiring enforcing mechanisms, implemented as a Ricardian contract. 

• Integrate with Valueflows on Holochain

2. Agent Identity

• Implement identity as decentralized digital profiles

• Support pseudonymity and sybil resistance

• Link Agent profiles to Roles, and governance interactions

• Credentials (capability tokens)

• Identification information (encrypted), such as address,  phone number and Government issued ID

3. Governance and Validation Mechanisms

• Implement basic access or interaction control using role-based logic and capability tokens (Holochain)

  • One general capability token allowing anyone permissionless access to search and find Nondominium Resources. 

    • Implement using the concept of Lobby: A Holochain application design pattern, in which one DHT is established as a common space which agents can join and either request access to a privileged DHT or ask privileged agents to mediate access to that DHT using remote calls.

  • Four different restricted capability token that allows access to another set of Actions related to Nondominium Resources (as described below), which applies to Agents that have created at least one new Nondominium Resource, validated by another Agent. 

    • One capability token for the Role of Accountable Agent, one for the Role of Primary Accountable Agent, one for the Role of Repair Agent and one for the Role of Storage Agent, as described below.

    • Implement using Membrane (Holochain): One of two types of permeable boundaries that allow or disallow access: The layer of protection around an Agent’s cell, secured by capability-based security, that prevents unauthorized access to the cell’s zome functions, source chain data, or view of the DHT. A special validation function in a DNA that checks an Agent’s membrane proof and determines their right to become part of the DNA’s network. If a membrane proof is invalid, existing peers in the network will refuse to talk to the agent attempting to join.

4. Role System

Define a basic role system: 

• Simple Agent, who can only search and find listed Nondominium Resources and can also create new Nondominium Resources. Applies to digital and material Nondominium Resources. Linked to the general capability token. Has a general capability token.

• Accountable Agent, who is trusted to interact with Nondominium Resources according to possible Actions as defined below. 

  • Applies to digital and material Nondominium Resources. 

  • Has the restricted capability token associated with this role.

• Primary Accountable Agent is an Accountable Agent that is the Custodian of a material Nondominium Resource, meaning that is in possession of one or more material Nondominium Resources for use, repair, storage or transportation. 

  • This does not apply to digital Nondominium Resources. 

  • The material Nondominium Resources has metadata that specifies the status as “in use”, “in repair”, “in storage” or “in transport” for how long (duration, time), and points to the Primary Accountable Agent that is currently in possession of itt. The status metadata which specifies at a given moment if they are “in use” , “in repair”, “in storage” or “in transport” also specifies the status of “unavailable” for access. 

  • Has the restricted capability token associated with this role.

  • Repair Agent is a Primary Accountable Agent that takes action to repair a material Nondominium Resource. 

    • The Repair Agent must enter in possession of the material Nondominium Resource that needs to be repaired, which is specified in the material Nondominium Resource’s metadata as entered by any Accountable Agent, therefore must also become the Primary Accountable Agent on top of being a Repair Agent during the time of the repair. 

    • This does not apply to digital Nondominium Resources. 

    • All material Nondominium Resources have a status metadata which specifies at a given moment if they are “in repair” as it specifies “in use” status. The status metadata which specifies at a given moment “in repair” also specifies the status of “unavailable” for access. Once the material Nondominium Resource is repaired by the Repair Agent, the same Agent can change the status of the Resource to “available” for access or “in use”, meaning “unavailable”, or “in storage”, meaning “available”. 

    • The Repair Agent can transfer the material Nondominium Asset to a Storage Agent (see herebelow). 

    • Has the restricted capability token associated with this role.

  • Storage Agent is a Primary Agent that is trusted to safely store at least one material Nondominium Resource in a physical location and makes them available to an Accountable Agent or an Repair Agent for access. 

    • This does not apply to digital Nondominium Resources. 

    • All material Nondominium Resources have metadata containing information about their physical location in general, including where they are stored, 

    • All material Nondominium Resources have a status metadata which specifies at a given moment if they are “in storage” as it specifies “in repair” or “in use”. The status metadata which specifies at a given moment if they are “in storage” also specifies the status of “available” for access. 

    • Has the restricted capability token associated with this role.

Link to Access

To be implemented later

• Transporter Agent is a Primary Accountable Agent that is trusted to transport a material Nondominium Resource from one Primary Accountable Agent to another, be it for use, repair or storage. 

  • This does not apply to digital Nondominium Resources. 

  • All material Nondominium Resources have a status metadata which specifies at a given moment if they are “in transport” as it specifies “in repair”, “in storage” or “in use”. The status metadata which specifies at a given moment if they are “in transport” also specifies the status of “available” for access. 

  • Has the restricted capability token associated with this role.

5. UI/UX Prototypes for sharing Resources

• Explore user interface elements that make Agents’ interactions with Nondominium Resource visible and traceable.

• Prototype core interaction models: Resource intent of access signals, transactions, etc.

6. Interoperability Foundations

• Align all representations with Valueflows ontology

User Personas and Stakeholders

Are linked to Roles. 

Simple Agent

• Who they are: Any individual who accesses the hApp that allows searching Nondominium Resources.

• Goals:

  • See what is available as Nondominium Resources shared within the network of Agents. Understand how the Nondominium platform for sharing self-governed Resources works.

• Frictions:

  • Difficulty accessing a platform for sharing digital and material Nondominium Resources.

  • Trusting Agents for sharing digital and material Nondominium Resources.

• Needs:

  • Low-friction onboarding.

  • Search functionality to find Nondominium Resources.

  • Easy tracking of Nondominium Resources (their Custodian in case of material Nondominium Resources, their digital location in case of Digital Nondominium Resources and physical location in case of material Nondominium Resources).

  • Trust through embedded governance.

Resource Creator

• Who they are: An individual who creates a new Nondominium Resource.

• Goals:

  • Offer a Nondominium Resource to be accessed by Agents part of the network.

• Frictions:

  • Trusting Agents for sharing digital and material Nondominium Resources.

  • Poor coordination or redundant efforts.

• Needs:

  • Easy process to create a Nondominium Resource

  • Easy tracking of Nondominium Resources (their Custodian in case of material Nondominium Resources, their digital location in case of Digital Nondominium Resources and physical location in case of material Nondominium Resources).

  • Trust through embedded governance

Resource Custodian

• Who they are: An agent (human) that holds one or more resources in trust for others (the rest of the network), according to governance rules. Can be in the Roles: Repair, Storage, Transport, or simply use the Resource

• Goals:

  • Steward assets in a transparent, accountable way.

  • Implement governance decisions or access control.

• Frictions:

  • Trust issues or opaque decision-making processes.

  • Ambiguous rules about who gets what, when.

• Needs:

  • Embedded governance and access rules.

  • History of actions and audit trails.

  • Cryptographic tools for trustless enforcement.

Functional Requirements

1. Nondominium Resource Model

Function: Define and manage digital and material Nondominium Resources that are accessible in a permissionless way (based on capability tokens), traceable, and governed by embedded logic.

Core Requirements:

• A Nondominium Resource structure includes metadata: origin (who created it), Primary Accountable Agent (who has it in custody), governance links, status (availability, needs repair, in repair, needs storage, in storage, needs transport, in transport, validated or not, etc.), etc. 

• Support tracking (location, use, status, etc.) and history

• Governed by code directly associated with it, not by organizational control

2. Agent Identity

Function: Represent Agents as linked to Roles.

Core Requirements:

• Pseudonymous. 

• Cryptographically secure identity information that is revealed to Agents that are not involved in a transaction only in case of litigation. Must be validated by at least another Agent during a first transaction, and subsequently by other agents in other transactions, in a random fashion or if the Agent hasn’t reached a giver threshold of transactions or hasn’t created a given number of Nondominium Resources (doesn’t have enough skin in the game).

• Sybil resistance mechanisms.

3. Role System

Function: Enable simple role assignment based on behavior.

Core Requirements:

Predefined Roles: 

• Simple Agent, who can only search and find listed Nondominium Resources and can also create new Nondominium Resources. Applies to digital and material Nondominium Resources. Linked to the general capability token. Has a general capability token.

• Accountable Agent, who is trusted to interact with Nondominium Resources according to possible Actions as defined below. 

  • Applies to digital and material Nondominium Resources. 

  • Has the restricted capability token associated with this role.

• Primary Accountable Agent is an Accountable Agent that is the Custodian of a material Nondominium Resource, meaning that is in possession of one or more material Nondominium Resources for use, repair, storage or transportation. 

  • This does not apply to digital Nondominium Resources. 

  • The material Nondominium Resources has metadata that specifies the status as “in use”, “in repair”, “in storage” or “in transport” for how long (duration, time), and points to the Primary Accountable Agent that is currently in possession of itt. The status metadata which specifies at a given moment if they are “in use” , “in repair”, “in storage” or “in transport” also specifies the status of “unavailable” for access. 

  • Has the restricted capability token associated with this role.

  • Repair Agent is a Primary Accountable Agent that takes action to repair a material Nondominium Resource. 

    • The Repair Agent must enter in possession of the material Nondominium Resource that needs to be repaired, which is specified in the material Nondominium Resource’s metadata as entered by any Accountable Agent, therefore must also become the Primary Accountable Agent on top of being a Repair Agent during the time of the repair. 

    • This does not apply to digital Nondominium Resources. 

    • All material Nondominium Resources have a status metadata which specifies at a given moment if they are “in repair” as it specifies “in use” status. The status metadata which specifies at a given moment “in repair” also specifies the status of “unavailable” for access. Once the material Nondominium Resource is repaired by the Repair Agent, the same Agent can change the status of the Resource to “available” for access or “in use”, meaning “unavailable”, or “in storage”, meaning “available”. 

    • The Repair Agent can transfer the material Nondominium Asset to a Storage Agent (see herebelow). 

    • Has the restricted capability token associated with this role.

  • Storage Agent is a Primary Agent that is trusted to safely store at least one material Nondominium Resource in a physical location and makes them available to an Accountable Agent or an Repair Agent for access. 

    • This does not apply to digital Nondominium Resources. 

    • All material Nondominium Resources have metadata containing information about their physical location in general, including where they are stored, 

    • All material Nondominium Resources have a status metadata which specifies at a given moment if they are “in storage” as it specifies “in repair” or “in use”. The status metadata which specifies at a given moment if they are “in storage” also specifies the status of “available” for access. 

    • Has the restricted capability token associated with this role.

Link to Access

Role-to-permission mappings

Roles modulate access

Agents can have multiple Roles.

To be implemented later

• Transporter Agent is a Primary Accountable Agent that is trusted to transport a material Nondominium Resource from one Primary Accountable Agent to another, be it for use, repair or storage. 

  • This does not apply to digital Nondominium Resources. 

  • All material Nondominium Resources have a status metadata which specifies at a given moment if they are “in transport” as it specifies “in repair”, “in storage” or “in use”. The status metadata which specifies at a given moment if they are “in transport” also specifies the status of “available” for access. 

  • Has the restricted capability token associated with this role.

8. Sharing economy UX / UI Framework

Function: Create visual and interactive patterns that promote decentralized sharing of Resources among Agents in the network. 

Core Requirements:

• Visibility of Nondominium Resources and of Requests (or published intents) to access Nondominium Resources, as well as Creation of new Resources.

• Interfaces for signaling interest in access a Nondominium Resource

• Interfaces for signaling needs like Storage and Repair.

• Time-sensitive cues (recent Nondominium Resource creation, recent signal to access a Nondominium Resource)

• Feedback loops

  • Interface for validation of a New Nondominium Resource and of associated Process (ex. Repair, Storage, Transport and of a material Nondominium Resource, and Use of both material and digital Resources). Both receiver and giver Agents in a transaction must sign the transaction. Related to Roles, using capability tokens.

  • Interface for Agent and identification information of Simple Agents by an Accountable Agent, to allow a Simple Agent to become an Accountable Agent or to acquire the role of Storage, Transport and/or Repair Agent, i.e. to  acquire the associated restricted capability token.

• Search/discovery of Resources

• Search/discovery of Agents

• Agent profiles, with Roles and history of Actions, and Processes.

• Interface for Processes such as Transport, Repair, Storage and Use. 

Implemented with Svelte kit. 

9. Governance Layer

Function: Implement logic for Nondominium Resource Actions, clearly specify benefits and responsibility for the Accountable Agent and the Primary Accountable Agent. This is implemented like a Ricardian contract.

Core Requirements:

• Governance associated with Nondominium Resources as Ricardian Contracts on Holochain.

  • A generic Governance layer that applies to all Nondominium Resources shared in the network.

  • Take into consideration the distinction between material and digital Nondominium Resources and Roles.

• Rule-based Actions validation workflows.

• Rule-based access to Actions as defined in Valueflows, by Role. 

Implemented on its own zome. 

10. Interoperability and Integration

Function: Enable external systems to interact with the Nondominium infrastructure.

Core Requirements:

• Valueflows-compliant API

• Hooks for Holochain hApps, Solid Pods, or Web3 bridges

Non-Functional Requirements

1. Decentralization and Serverlessness

• The system must operate without reliance on centralized servers or databases.

• All user data, logic, and state should be managed on peer-to-peer infrastructure (Holochain).

• Network participation should not require platform-level authorization (permissionless to become a Simple Agent, rules-based to become an Accountable Agent).

2. Privacy and Data Sovereignty

• Each Agent must have full control over their data, with local data storage by default.

• The system must support selective disclosure: 

  • Agents choose which parts of their history are visible and to whom.

  • Agents keep their identity information, such as address, encrypted, and it is only disclosed to other users when they want to transact.

  • Agents’ Roles are public. 

3. Identity & Reputation Portability

• Identities portable (usable across networks), and persistent (retain historical continuity).

• The system should enable Agents to operate across multiple Resource sharing networks.

4. Interoperability

• The architecture must align with Valueflows vocabulary.

• Resource and agent structures must be to DAOs or other commons infrastructure (e.g., Solid, IPFS, Ethereum).

• Provide APIs or interfaces for integration with third-party platforms and network-of-network systems.

5. Auditability and Transparency

• Every interaction with Nondominium Resources must be traceable, and must have immutable logs.

• Nondominium Resource creation and usage metadata should allow full reconstruction of a resource's life.

• Validations related to Agents must have immutable logs.

6. Performance and Scalability

• The system must maintain acceptable responsiveness under load typical for distributed sharing networks (hundreds of Agents, thousands of assets).

• Performance should degrade gracefully under high contention (e.g., multiple forks, many simultaneous edits).

7. Modularity and Composability

• All core features (units, Agents, Resources, Role system, etc.) must be implemented as loosely coupled modules.

• Modules should be reusable in different configurations or organizational contexts.

8. Sybil Resistance and Anti-Spam Measures

• The identity system must prevent spam and Sybil attacks in permissionless environments.

• Nondominium Resource interactions should be gated by roles and credentials.

9. Resilience and Fault Tolerance

• The system should be robust to partial network failure or unresponsive peers.

• All user-facing data and permissions should be recoverable locally from the Agent's source chain (Holochain principle).

10. Ethical Constraints and Governance Neutrality

• The infrastructure assumes a unique governance model, specified for digital and material Nondominium, containing fields and parameters that are specific to types of Nondominium Resources, set by Resource Creators during the creation process of a new Nondominium Resource. 

Governance and Quality Assurance

Governance Philosophy

Nondominium should support non-hierarchical governance based on:

• Peer validation

• Transparent, self-reinforcing norms (stigmergy)

No centralized admin Agents should have irreversible control over Nondominium Resources.

Validation and security

New Resource Validation

• Each new Nondominium Resource must be peer-validated 

  • The validation is done by an Accountable Agent during a first access by another agent.

• Validation rules may be Resource-specific and include:

  • Manual peer review (e.g., 2-of-3 reviewers approve)

  • Role-gated review (e.g., only agents with a “Maintainer” role)

Accountable Agent Validation

Each new Agent is a Simple Agent. In order to become an Accountable Agent the new Agent must satisfy the following requirements: 

1. Must create a new Nondominium Resource which needs to be of interest to at least one Accountable Agent and needs to be validated by one Accountable Agent.

2. Must exist as an individual human with corresponding identification information.

Resource validation

• The validation is done by an Accountable Agent during a first transaction, in which the Simple Agent offers a new Nondominium Resource (sets status to “available” or “needs repair” (for a material Nondominium Resources) or “needs storage” (for a material Nondominium Resources)) that was newly created by the Simple Agent for the first time, and the Accountable Agent is the receiver Agent, in the role of Primary Accountable Agent (wants to use), Repair Agent (only applies to material Nondominium Resources, wants to repair), Storage Agent (only applies to material Nondominium Resources, wants to store).

• The new Nondominium Resource created and set as “available” or “needs repair” (for a material Nondominium Resources) or “needs storage” (for a material Nondominium Resources) may not satisfy any interest for any Accountable Agent and may never enter a validation process, in which case the new Agent will not get validated, until he offers some new Nondominium Resource which will find interest eventually.

Individual validation

• The existence of the new Agent, as well as its identity information are verified by the Accountable Agent. If the offered Resource matches the description, after identity verification, the act of validation changes the Role of the new Agent from Simple Agent to Accountable Agent.

Validation rules may be Resource-specific (configurable per Resource) and include:

• Manual peer review (e.g., one Accountable Agent approves)

• Role-gated review (e.g., only Accountable Agents)

Primary Accountable Agent Validation

Doesn’t need validation. All Accountable Agents can be in the role of a Primary Accountable Agent.

Repair Validation

• Repair Agent validation

  • Any Accountable Agent can become a Repair Agent. A wannabe Repair Agent is validated by another Accountable Agent manually, once the wannabe Repair Agent demonstrates the skills to successfully perform appropriate repair actions. The validation is pending until the material Nondominium Resource is also validated as repaired (see below). The Agent’s Role is marked as Repair Agent Pending Validation.

• Resource Repair Validation

  • Once a material Nondominium Resource is set to “needs repair” or “not functional” it can enter “in repair” status, when accessed by a Repair Agent or by a Repair Agent Pending Validation.

  • A Repair Agent or a Repair Agent Pending Validation can access the material Nondominium Resource for repair.

  • Once the Resource is repaired the Repair Agent or the Repair Agent Pending Validation can set the Resource’s status to “repaired pending validation” and further to “available” or “in use”.

  • If the Resource is “available” or when it changes status to “available” once the duration of the status “in use” has expired, the Resource can be accessed by an Accountable Agent for use or storage. This Accountable Agent that accesses the Resource for use or storage validates the successful repair of the Resource

    • If the repair is successful this Accountable Agent changes the Resource’s status from “repaired pending validation” to “repaired, validated” or “functional”.

      • If the Agent that has made the repair is a Repair Agent Pending Validation, the successful completion of the Resource Repair Validation process with the mention “functional” completes the validation process of the Repair Agent Pending Validation and his Role changes to Repair Agent. 

    • If the repair is unsuccessful this Accountable Agent changes the Resource’s status from “repaired pending validation” back to “needs repair” or “not functional”.

      • If the Agent that has made the unsuccessful repair is a Repair Agent Pending Validation, the unsuccessful completion of the Resource Repair Validation process with the mention “needs repair” or “not functional” completes the validation process of the Repair Agent Pending Validation and his Role changes to simply Accountable Agent.

Storage Agent Validation

Any Accountable Agent can become a Storage Agent. A wannabe Storage Agent is validated by another Accountable Agent manually, once the wannabe Storage Agent demonstrates the capabilities to successfully perform appropriate storage actions.

• Storage Agent validation

  • Any Accountable Agent can become a Storage Agent. A wannabe Storage Agent is validated by another Accountable Agent manually, once the wannabe Storage Agent demonstrates the skills to successfully perform appropriate storage actions. The validation is pending until the material Nondominium Resource is also validated as successfully stored (see below). The Agent’s Role is marked as Storage Agent Pending Validation.

• Resource Storage Validation

  • Once a material Nondominium Resource is set to “needs storage” it can enter “in storage” status, when accessed by a Storage Agent or by a Storage Agent Pending Validation.

  • A Storage Agent or a Storage Agent Pending Validation can access the material Nondominium Resource for storage.

  • Once the Resource is stored the Storage Agent or the Storage Agent Pending Validation can set the Resource’s status to “in storage pending validation” and further to “available” or “needs repair.

  • The Resource can be accessed by an Accountable Agent for use or repair. This Accountable Agent that accesses the Resource for use or repair validates the successful storage of the Resource,

    • If the Resource is found as described by its metadata, this Accountable Agent changes the status from “stored pending validation” to “stored, validated”.

      • If the Agent that has stored the Resource is a Storage Agent Pending Validation, the successful completion of the Resource Storage Validation process completes the validation process of the Storage Agent Pending Validation and his role changes to Storage Agent.

    • If the Resource is not found as described by its metadata, this Accountable Agent changes the status from “stored pending validation” to “non-existent".

      • If the Agent that has stored the Resource is a Storage Agent Pending Validation, the unsuccessful completion of the Resource Storage Validation process completes the validation process of the Storage Agent Pending Validation and his role is not changed to Storage Agent. This Agent becomes a Simple Agent and has to start again.

      • If the Agent that has stored the Resource is a Storage Agent, the unsuccessful completion of the Resource Storage Validation process makes the Agent lose the role of Storage Agent. This Agent becomes a Simple Agent and has to start again.  

To be implemented later

Transport Agent Validation

Any Accountable Agent can become a Transporter Agent. A wannabe Transporter Agent is validated by another Accountable Agent manually, once the wannabe Transporter Agent demonstrates the capabilities to successfully perform transportation actions.

• Transport Agent validation

  • Any Accountable Agent can become a Transport Agent. A wannabe Transport Agent is validated by another Accountable Agent manually, once the wannabe Transport Agent demonstrates the capability to successfully perform appropriate transportation actions. The validation is pending until the material Nondominium Resource is also validated as successfully transported (see below). The Agent’s Role is marked as Transport Agent Pending Validation.

• Resource Transport Validation

  • Once a material Nondominium Resource is set to “needs transport” by a Primary Accountable Agent (user or Repair or Storage) it can enter “in transport” status, when accessed by a Transport Agent or by a Transport Agent Pending Validation.

  • A Transport Agent or a Transport Agent Pending Validation can access the material Nondominium Resource for transport.

  • Once the Resource is transferred under the custody of a Transport Agent or a Transport Agent Pending Validation for transportation, the Resource’s status is set to “in transport pending validation”.

  • The Resource will be accessed by another Accountable Agent that is the receiver. This Accountable Agent that accesses the Resource for use, repair or storage validates the successful transport of the Resource,

    • If the Resource arrives at the destination in possession of the other Primary Accountable Agent as described by its metadata, this Primary Accountable Agent changes the status from “in transport pending validation” to “in use” or “in storage” or “in repair”.

      • If the Agent that has transported the Resource is a Transport Agent Pending Validation, the successful completion of the Resource Transport Validation process completes the validation process of the Transport Agent Pending Validation and his role changes to Transport Agent.

    • If the Resource is not delivered as expected or it’s not conform as described by its metadata, this Accountable Agent changes the status from “in transport pending validation” to “non-existent".

      • If the Agent that has transported the Resource is a Transport Agent Pending Validation, the unsuccessful completion of the Resource Transport Validation process completes the validation process of the Transport Agent Pending Validation and his role is not changed to Storage Agent. This Agent becomes a Simple Agent and has to start again.

      • If the Agent that has transported the Resource is a Transport Agent, the unsuccessful completion of the Resource Transport Validation process makes the Agent lose the role of Transport Agent. This Agent becomes a Simple Agent and has to start again.

Dispute Resolution

Conflicts may arise over:

• Validation outcomes, for all validations

• Resource creation relevance

Mechanisms include:

• Peer-based mediation: Accountable agents (e.g., Mediators) intervene

• Multi-step escalation: Challenge → Mediation → Arbitration

• Open audits: Anyone can view histories and validation logs to contest decisions

Embedded Governance Objects

• Every Nondominium Resource is a programmable object with:

  • Access rules (who can do what)

  • Validation rules (what qualifies as acceptable change)

  • Governance rules (how decisions are made)

  • Ricardian contract: 

• Rules are expressed in standard formats and are machine-readable and human-legible

Appendices

Appendix A: Glossary

• Nondominium: A class of digital and material Resources that are permissionless, uncapturable, and governed without centralized ownership; defined by embedded rules. A new form of property: no one can own, everyone has access, mediated by credentials and rules that are enforced algorithmically. A governance form where no single party has exclusive ownership rights over a resource; all benefit and access rights are governed collectively.

• Agent: An identifiable participant (human) with a digital identity who contributes with Resources, and accesses (uses) resources within the system.

• Profile: A structured representation of an agent's identity, roles, history, credentials.

• Credential: A verifiable proof issued by a peer or system indicating that an Agent has a specific capability, role, or history.

• Role: A behavioral or functional category assigned to an agent (e.g., Simple Agent, Resource creator or Accountable Agent,) with attached permissions.

• Capability Token: A cryptographic key enabling an agent to perform specific actions, following Holochain’s access control model.

• Valueflows: An open vocabulary and data model for economic networks, used to represent agents, resources, events, and value transfers.

• hREA: A Holochain-based implementation of Valueflows, supporting distributed contribution and resource accounting.

Appendix B: References

• Valueflows Vocabulary: https://valueflo.ws/

• Holochain Dev Portal: https://developer.holochain.org

• OVN / NRP-CAS: https://wiki.p2pfoundation.net/Open_Value_Network 

• P2P Models Project: https://p2pmodels.org/

• Commons Transition Primer: https://primer.commonstransition.org/ 

• Baran’s Distributed Systems Topology (1964) – foundational model of decentralized networks

Appendix C: Conceptual Clarifications

Digital Nondominium vs Traditional Open Source

Traditional open-source platforms (e.g., GitHub) host code that is “open” but typically governed by informal hierarchies, lead maintainers, or organizations. In contrast, Nondominium:

• Embed governance and rules into the digital resource itself

• Cannot be unilaterally captured or controlled

Material nondominium vs shared material assets / condominium

A shared physical asset is defined as shared property. A condominium is defined as a material asset that can be separated into parts (an apartment block) and every part is privately owned. In contrast no one can own a nondominium material asset, but access to it and its use is governed by rules that are associated with it. 

Nondominium and Legal Neutrality

The system assumes no specific legal model — no corporation, foundation, or DAO “owns” the commons. Instead, it defines a logic of access and benefit allocation that can run independent of institutional wrappers. Legal bridges can be added by participants, but the infrastructure is inherently legally neutral.

Backend implementation

Modularize the hApp:

• Nondominium DNA

  • Zomes

    • zome_Agent

    • zome_Resource

    • zome_Governance

  • Entry types

    • Agent

    • Resource

    • Governance

Implementation Sequence and UI Workflow Design

Based on comprehensive analysis of ValueFlows ontology, hREA implementation, and current codebase dependencies, this document outlines the proper implementation sequence for Nondominium and proposes UI workflow improvements to avoid runtime errors.

1. ValueFlows Implementation Sequence Analysis

Understanding ValueFlows Component Dependencies

ValueFlows has a clear hierarchy of dependencies that must be respected to avoid runtime errors. Based on the ontology specification and hREA implementation:

Phase 1: Foundation Components (Must be implemented first)

1.1 Units (Highest Priority)

Why first: Every Measure in ValueFlows requires a Unit. Resources, Events, and almost all quantified data depend on Units.

Implementation requirements:

• Create Unit entities following OM2 (Ontology of Measures) standard

• Include basic units: one (each), hour (time), kilogram (weight), meter (distance)

• Support override labels for business contexts (e.g., "each" instead of "one")

1.2 Agents (Second Priority)

Why second: Agents are required for all economic activity. Every EconomicEvent, Process, and Resource needs associated Agents.

Implementation requirements:

• Person agent type

• Agent creation and management

• Agent authentication and identity

1.3 Actions (Third Priority)

Why third: Every EconomicEvent requires an Action that defines its behavior (produce, consume, use, transfer, etc.).

Implementation requirements:

• Standard ValueFlows actions: produce, consume, use, transfer, move, cite, etc.

• Action effects on resources (increment, decrement, no-change)

• Action validation rules

For Material Resources (see Resources below)

• produce - A new resource is created or or an addition to an existing stock resource of the same type is incremented.

• use - Most often use is employed for equipment or tools that are used in a process, but not consumed. After the process, the piece of equipment of tool still exists, but during the process, it is unavailable. The unavailability can be useful to know if the resource must be scheduled, or if one needs to know how much the resource is used.

• pickup - The transported resource or person enters the process; the same resource will appear later in an output of the process.

• dropoff - The transported resource or person leaves the process; the same resource or person appeared in an input of this process.

• accept - This is used as input to a process involving repair, transport, storage, or similar of a resource. The same resource will appear in the output of the process. It is sometimes a bit of a gray area when to use accept/modify vs. use/produce. The choice is based on the need to have the same identified resource before and after the process. Generally if the resource is involved in a series of processes to create it before anything else happens to it, accept/modify is appropriate. If the input resource and the output resource need to be identified as different resource specifications for any reason, then accept/modify is not appropriate.

• transferAllRights - This action gives full (in the human realm) rights and responsibilities to another agent, without transferring physical custody. People might call this "ownership"; or it might be considered "stewardship" or similar. This occurs instantaneously, and does not involve documented physical transfer.

• transferCustody - This action gives physical custody and control of a resource to another agent, without full rights. The physical custodian often has responsibilities associated with custody, however. Examples where transfer of custody is useful are loaning a resource to another agent, or when a resource is transferred to have a service performed by another agent, like transportation or repair.

• transfer - This action gives full (human) rights and responsibilities plus physical custody, combining the last two actions for simplicity.

• move - move changes the location (and possibly the identifier, if location is part of the logical identifier) of a resource, but does not transfer agent rights or custodianship.

For Digital Resources (see Resources below)

• produce - A new resource is created or or an addition to an existing stock resource of the same type is incremented.

• use - Most often use is employed for equipment or tools that are used in a process, but not consumed. After the process, the piece of equipment of tool still exists, but during the process, it is unavailable. The unavailability can be useful to know if the resource must be scheduled, or if one needs to know how much the resource is used.

• work - work refers to labor applied to a process. There is generally no identifiable resource involved, only the provider agent. In this case, the type of work or skill involved can be identified by a resource specification. A possible exception would be if the agent's work schedule is kept on a calendar, representing when the specific agent is available to work.

• accept - This is used as input to a process involving repair, modification, testing, or similar of a resource. The same resource will appear in the output of the process. It is sometimes a bit of a gray area when to use accept/modify vs. consume/produce. The choice is based on the need to have the same identified resource before and after the process. Generally if the resource is involved in a series of processes to create it before anything else happens to it, accept/modify is appropriate. If the input resource and the output resource need to be identified as different resource specifications for any reason, then accept/modify is not appropriate.

• modify - The identified resource that was accepted into a process appears in the output of that process, with modifications made. Note not all modifications require a physical change, for example quality testing. In all cases though, it matters that the resource has gone through that process, and the stage of the resource (the process specification of the process) is then used as part of the logical identification of the resource when the resource is requested as a process input or for a transfer.

• transferAllRights - This action gives full (in the human realm) rights and responsibilities to another agent, without transferring physical custody. People might call this "ownership"; or it might be considered "stewardship" or similar. This occurs instantaneously, and does not involve documented physical transfer.

• transfer - This action gives full (human) rights and responsibilities plus physical custody, combining the last two actions for simplicity.

• move - move changes the digital location (and possibly the identifier, if location is part of the logical identifier) of a resource, but does not transfer agent rights or custodianship.

• copy - A new resource is created for the receiver, an exact copy of the original provider resource, used for digital resources.

Phase 2: Resource Foundation Components

2.1 ResourceSpecifications (Fourth Priority)

Why fourth: EconomicResources should conform to ResourceSpecifications. This provides the "type" or "kind" of resources.

Implementation requirements:

• Resource type definitions

  • Material (equipment or tool, consumable)

  • Digital (Document, Software, Design, etc.)

• Default units for Resources and effort

• Substitutability rules

Resource functional core requirements

• Resource structure includes metadata: origin, location, custodian, governance links, status

• Support for tracking

• Resource is governed by code, not by organizational control

2.2 EconomicResources (Fifth Priority)

Why fifth: Resources depend on ResourceSpecifications, Units, and Agents being properly established.

Implementation requirements:

• Resource creation with proper conformsTo relationship

• Accounting and onhand quantities with proper Units

• Primary accountable Agent assignment

Phase 3: Process and Event Components

3.1 Processes (Sixth Priority)

Why sixth: Processes organize and contextualize EconomicEvents. Events can reference processes they belong to.

Implementation requirements:

• Process creation and management

• Process-Event relationships

• Input/output flow definitions

3.2 EconomicEvents (Seventh Priority)

Why seventh: Events depend on Actions, Agents, Resources, and optionally Processes being established.

Implementation requirements:

• Event creation with proper Action, Agent, Resource references

• Quantity measurements with proper Units

• Process relationships

Phase 4: Advanced Planning Components

Intents and Commitments (Eighth Priority)

Why eighth: These represent planned future activities and depend on all foundation components.

Implementation requirements:

• Intent creation and matching

• Commitment fulfillment tracking

• Agreement relationships

Implementation Sequence Justification

Critical Dependencies Identified:

1. Units → Everything: Without proper Units, no Measure can be created, breaking Resources and Events

2. Agents → Events & Resources: All economic activity requires agent attribution

3. Actions → Events: Events cannot exist without defining their action type

4. ResourceSpecifications → Resources: Resources need types/categories for proper modeling

5. Resources → Events: Most events reference resources they affect

6. Processes → Events: Events can be grouped into meaningful processes

Anti-patterns to Avoid

• ❌ Creating Resources without ResourceSpecifications (causes validation errors)

• ❌ Creating Events without proper Units in quantities (causes measurement errors)

• ❌ Creating Events without valid Actions (causes action reference errors)

• ❌ Creating Resources without primary accountable Agents (causes ownership errors)

Access

One of the most important questions about Nondominium as stand alone, organization-agnostic digital assets, is access: how can people interact with them?

For this particular proof of concept we are only implementing the following actions: 

From Holochain documentation: 

Membrane: One of two types of permeable boundaries that allow or disallow access:

1. The layer of protection around an agent’s cell, secured by capability-based security, that prevents unauthorized access to the cell’s zome functions, source chain data, or view of the DHT.

2. A special validation function in a DNA that checks an agent’s membrane proof and determines their right to become part of the DNA’s network. If a membrane proof is invalid, existing peers in the network will refuse to talk to the agent attempting to join.

Lobby: A Holochain application design pattern, in which one DHT is established as a common space which agents can join and either request access to a privileged DHT or ask privileged agents to mediate access to that DHT using remote calls.

Capability-based security: A security model that allows the owner of a resource to grant others access while maintaining ultimate control. Instead of allowing direct access to the resource, it mediates access and manages privileges by issuing capability claims, or tokens representing access to the resource. In Holochain, an agent’s conductor protects their running cells and authorizes callers’ access to them by issuing and checking the secrets and credentials they supply against existing grants.

User Stories and Use Cases

Simple Agent, who can only search and find listed Nondominium Resources and can also create new Nondominium Resources. Linked to the general capability token.

• As a Simple Agent, I want to use the Nondominium hApp with little effort and without permission.

• As a Simple Agent, I want to be able to complete my identity, to associate my identification information with my Agent identity, such as legal name, physical address, email and a photo ID. 

• As a Simple Agent, I want to search available Nondominium Resources.

• As a Simple Agent, I want to search Agents, see their Roles and the Resources that they have Custody of, for Processes such as use, repair, store and transport, and see their history.

• As a Simple Agent,  I want to be able to create a Nondominium Resource and understand the basic rules related to all the Nondominium Resources and Processes and Roles.  

• As a Simple Agent, I want to be able to create a new Nondominium Resource, making it visible to other Agents, that they can find by searching and access.

• As a Simple Agent, I want to be able to interact with other Agents in case one agent wants to access my new Nondominium Resource that I created.

• As a Simple Agent, I want to be able to make my first transaction, transferring my new Nondiminium Resource to an Accountable Agent.

• As a Simple Agent, I want to be able to become an Accountable Agent after making the first transaction and having my new Nondominium Resource validated and myself validated as an Agent, with personal identification, by another Accountable Agent.  

Accountable Agent, who can signal the intent of accessing a Nondominium Resource. Linked to the restricted capability token.

• As an Accountable Agent, I want to be able to search available Nondominium Resources.

• As an Accountable Agent, I want to search other Agents, see their Roles and Resources that they have custody of and their history.

• As an Accountable Agent, I want to be able to signal my intent to access a Nondominium Resource, for use, repair, transport or storage, depending on my Roles.

• As an Accountable Agent, I want to be able to acquire roles such as Repair, Transport and/or Storage.

• As an Accountable Agent, I want to be able to validate Agents, Resources and Processes.

• As an Accountable Agent, I want to be able to interact with an Agent that is currently the Custodian of a Nondominium Resource and arrange for an access / transfer for use, repair, storage or transport, depending on my Roles.

• As an Accountable Agent, I want to be able to validate the existence and the validity of the identity information of a Simple Agent who engages in its first transaction and of other Accountable Agents.

Primary Accountable Agent is the Custodian of a material Nondominium Resource, meaning that has a material Nondominium Resources in possession, under custodianship. 

• As a Primary Accountable Agent, I want to be able to do everything a Primary Agent can do.

• As a Primary Accountable Agent, I want to access Roles of Storage, Repair and Transport, based on specified validation Rules.

• As a Primary Accountable Agent, I want to validate other Primary Agents who want to access Roles of Storage, Repair and Transport, based on specified validation Rules.

• As a Primary Accountable Agent, I want to apply governance rules programmatically, so that decisions about the access of Nondominium Resources and their modification, use, storage, repair and transport are transparent and fair.

• As a Primary Accountable Agent, I want to hold shared credentials with access conditions, so that resources are protected but not centralized.

• As a Primary Accountable Agent, I want to be able to interact with other Primary Agents, to access Resources for use, Repair, Transport and Storage, if I have the credentials to perform in the possible Roles: user, Repair, Transport and Storage. 

Holochain development environment

Install holonix development environment

On Linux run the following command in terminal (see reference)

bash <(curl https://holochain.github.io/holochain/setup.sh)

This command downloads the setup script and runs it, installing the Nix package manager and setting up a package cache for Holochain.

Set up Nix development environment for Holochain

nix run --refresh -j0 -v "github:holochain/holonix?ref=main-0.5#hc-scaffold" -- --version

At the end of the output, Holochain’s scaffolding tool should print its version string, which will be something like this:

holochain_scaffolding_cli 0.500.0

To scaffold a new Holochain hApp (info here). For this tutorial, we’ll be working in ~/Holochain. Create that folder now and move into it.

mkdir Holochain 

Navigate in that folder 

cd ~/Holochain

When getting started, seeing a simple but fully-functional app can be very helpful. You can have Holochain’s scaffolding tool generate a “Hello World!” application (but for a distributed multi-agent world) by typing the following in your command line terminal:

nix run "github:/holochain/holonix?ref=main-0.5#hc-scaffold" -- web-app

The scaffolding tool will ask you one question — what JavaScript package manager you’d like to use in your project. If in doubt, just choose npm.

So this creates a folder called hello-world After doing a bit of work, it’ll print out these four commands for you to run in order to compile and run the app. Copy them from your terminal or from below:

cd hello-world

nix develop

Nix will then download all the packages you need to build and test Holochain apps. It might take a few minutes the first time. This is a very slow process !! It can take up to 30 min or more. 

Then 

if you use npm you run 

npm install

If you use bash you run 

bun install

Then 

if you use npm you run

npm start 

If you use bash you run 

bun run start

There are a lot of configurations to do, I chose svelt, name for the happ, 

Open your IDE (VSCodium or Cursor for example) and open the folder that you have created

Run 

bash <(curl https://holochain.github.io/holochain/setup.sh)

Your environment is ready to start building your hApp.

You can use Holochain’s scaffolding tool to start coding. For example, you can open the terminal in VSCodium and use this command: 

hc scaffold entry-type

There will be a series of questions to answer, the scaffolding tool will create the code for you. 

hApp architecture

Zomes

• zome_Person

• zome_Resource

• zome_Gouvernance

Entry types

• Person

• Resource

• Governance

Rapid Application Tool for Holochain (Scaffolding tool)

Using the terminal, you are able to generate holochain code for basic components, by answering questions.

Official documentation