Nondominium and Holochain
Part of Digital Environment, linked to Next Gen NRP
Developelopment done under the Nondominium venture
Embedded Files
Last updated on May 27th 2026
Get involved
Get involved
You can engage via Sensorica's Discord or hREA's Discord, or intervene directly in the working doc and Github repo.
Objective
Objective
Build dweb tools to reduce friction in resource flows, to support the peer sharing economy and peer production- Nondominium
Use Holochain / hREA and Valueflows, get inspired from NRP-CAS development.
Reason: Support glocal material peer production and stimulate capacity building for open value network (OVNs).
Grounding: There are immediate applications for Nondominium: ArtCoin, PEP Master, NOICE.
The basis
The basis
Holochain is beta, Holo is in launching phase in 2026.
hREA has already released the first minimum-viable, feature-complete release with a stable externally-facing API
Sensorica can provide real world contexts (ventures, projects) to build infrastructure, ex. PEP Master, ArtCoin, NOICE.
Other notes
Other notes
NOTE: this is a first proposition. There's also a document about this...
About true commons
About true commons
Commons-based peer production (CBPP) is a new mode of production mediated by Internet technology, first described by Yochai Benkler in 2002, in the context of open source software. Since then, the practice has evolved in all spheres of human activity, including material peer production. In essence, people coordinate globally to create various types of digital artifacts (assets, resources), which are openly shared under various permissive licences, as commons. Shared artifacts may represent code (software), PCB designs or CAD files (3D models), and usually include instructions on how to use or build, as well as context. Eventually, these designs are materialized / fabricated by users or intermediaries.
When we hear the term digital commons we assume that it refers to assets shared-by-default, portable and uncapturable, allowing anyone, regardless of organizational affiliation, to further contribute to their development, fork and remix. In reality, these shared digital resources are stored on centralized platforms like Github (for software) and Thingiverse (for 3D models), where they are subject to the platform’s rules and limitations and are not very portable (transportable across platforms). Shared assets that are captured by centralized platforms are, in this context, not true commons. So we need to free these digital assets, to make them portable and uncapturable. Thus, true commons will be able to exist as standalone entities on a serverless infrastructure, with the following basic features:
Permissionless Access: Anyone can Access Resources under defined governance rules
Organization Agnostic: Exist independently of any single organization. Not owned or controlled by any single Agent or organization.
Capture Resistant or Unenclosable: Uncapturable and resilient to monopolization. No Agent or group of Agents can control or delete Resources.
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 in specific ways, Role-related. Is pseudonymous.
Self-regulated: Peer reviewed, verified and tested (quality control)
Shareable by Default: Resources are designed for sharing from inception
Reputation-enabled: Built-in accountability through cryptographically-signed participation tracking
Process-aware: Supporting structured Economic Processes (Use, Transport, Storage, Repair)
Fully specified: Machine readable in terms of function, design architecture, standards (dimensions, tolerances, quality), etc.
Composable: Resources can be combined into come complex resources, allow fork and remix
Hard to Clone: Governance, set of rules and incentives to make unnecessary copying of a resource unlikely.
Lifecycle Managed: Resources have managed lifecycles from creation through validation to end-of-life.
Traceable: Full provenance and economic activity tracking, affiliation to component resources.
Future characteristics: accommodate various property regimes, including nondominium (no one owns but everyone has access under certain rules), which is an implementation of the pools of shareables concept.
The Problem of Proliferation: The Fragmented Digital Commons
The Problem of Proliferation: The Fragmented Digital Commons
See the Problem of Proliferation.
Issues
Philosophical and Directional Conflicts: These are disagreements about the fundamental nature, goals, or future of the software.
Governance and Social Issues: These relate to the management and human dynamics within the original project.
Technical and Practical Needs: These are practical requirements that the original project is failing to meet.
Solutions
Culture & Social Solutions
Promote a "Merge-First" Ethos: Cultivate a community culture where forking is seen as a temporary exploration tool rather than a permanent path. Developers should be encouraged to make a good-faith effort to reintegrate (merge) their work into the main project before deciding on a hard fork.
Decouple Criticism from Identity: Foster an environment where technical critique is separated from personal attacks or identity. This reduces the social friction and personal acrimony that often drives developers to fork simply to escape a hostile environment.
"Feeder Project" Recognition: Officially recognize and give credit to forks that serve as test-beds for new features. The main project can publicly list these "feeder projects," acknowledging their valuable role in experimentation and signaling to users which forks are likely to feed back into the canonical version.
Governance Solutions
Clear and Transparent Decision-Making: Implement a well-documented governance model that clarifies how decisions are made (e.g., voting, consensus, BDFL-dictated) and who holds the power. This prevents forks driven by confusion or the feeling of being shut out.
Formalize the Project Split/Fork Process: Establish clear, agreed-upon criteria for when a legitimate hard fork is warranted (e.g., philosophical schism, major technical divergence). A formal process can help the community recognize and support two distinct projects rather than a confusing, fragmented mess.
Establish a Technical Review Board (TRB): Create a rotating group of trusted, senior contributors from various factions to mediate technical disputes that often lead to forking. The TRB's role is to objectively assess and recommend integration strategies for controversial features.
Infrastructure & Methods Solutions
Modular Architecture and Microservices: Encourage developers to design the project with a highly modular architecture. This allows developers to fork or replace only the specific component (or module/microservice) they want to modify, rather than the entire codebase. This minimizes the scope of the diverging code.
Standardized API/Interfaces (Contract-First): Enforce strict interfaces (APIs) between project components. As long as a developer's fork maintains compliance with the main project's established API, the original codebase can safely integrate the forked component, lowering the barrier to merging.
Canonical Artifact Hash Registry (Web3 Concept): Borrowing from the Web3 concept of provenance, the core project could maintain a public, immutable, and easily verifiable registry of cryptographic hashes for all official releases (the digital commons). This allows developers and users to quickly and automatically verify if a file they obtained is the canonical version or a modified copy, directly addressing the integrity and provenance issue you raised.
Economic Solutions
Sponsor Coordination Efforts: Encourage and fund third-party organizations or individuals whose explicit role is coordinating development between the main project and major, active forks. This formalizes the relationship and resources for merging.
Bounties for Integration: Offer financial bounties specifically for contributors who successfully merge features developed in a fork back into the main project. This incentivizes the reconciliation of parallel development efforts.
Incentivize Tooling for Diffing and Merging: Fund the development of advanced tooling that automatically highlights, compares, and suggests merge strategies for deeply divergent codebases. Reducing the technical cost of merging makes it a more attractive option than continued isolated development.
These solutions aim to use social pressure, clear rules, and technical tools to channel parallel development efforts back towards a central, canonical stream, maximizing the collective benefit of open-source freedom.
Socioeconomic solutions specific to Nondominium
Building on the OVN model, in Nondominium (using Valueflows), for every NDO we track content (ex. a 3D model) and economic activity (use of resources, contributions in time, materials, money, etc.). Forking a project-type NDO generates a link to the original, similar to Git (ex. Github), but without the aspects of platform centralization. Since we apply the OVN license to every project-type NDO, a pie chart of past contributions associated with every project-type NDO. The license legally enforces the transfer of the pie chart of the original project-type NDO to the fork project-type NDO. Moreover, all NDOs come with their own governance, which enforces the OVN license at the code level. Despite the fact that past contributions are necessarily passed to new forks, the system generates intrinsic incentives for collaboration around canonical digital resources.
First, there is a reputation reward for contributing to a shared digital resource (a project-type NDO). Your contribution in this context is submitted to a peer review process, to analysis and testing by other parties, to a shared and transparent process of quality control. Thus, your contribution is already vetted, validated, it acquires value, which is not necessarily the case if you just publish your work on your personal blog.
Second, if contributions to a project-type NDOs it tied to a tangible reward scheme (tangible benefit redistribution per OVN model), you can be paid for your contributions.
When it comes to social and organizational frictions, each traditional open source project is managed by a group of individuals who have the power to accept or reject members and contributions. In contrast, Wikipedia and Bitcoin offer permissionless (identity-blind and frictionless) access to participation. Nondominium sits in between these two cases of gated vs permissionless participation. A project-type NDO is permissionless, governed but organization agnostic. In other words,
A project-type NDO can be accessed by individuals and organizations, similar to how we engage with open source projects. See the notion of Lobby, Group and NDO in Nondominium.
Contributing to a project-type NDO is permissionless like most open source projects, but there is no admin in the traditional sense of web2 applications (an entity that has defacto special privileges over the resource). Decision is made by contributors, which are granted access to decision making processes by a benefit redistribution algorithm (based on the OVN model), i.e. it is based on past contributions, or meritocratic.
When it comes to forking a project-type NDO, the operation is accessed from the NDO itself, as a stand alone entity (with its own DHT, forming its own network). This operation is disabled by default and it is only enabled if a threshold of social interaction is met, enforced by the NDOs governance. In other words the idea here is to create some friction to the process of forking. For example, the agent that wants to perform a fork must open a chat or file a proposal and engage all contributors of this particular NDO (no matter which organization they belong to), present the why, what’s the plan, etc. This action allows all contributors at least to be informed about this action. They may realize that this fork may not be necessary, as the proposition can be well integrated into the present NDO as an improvement, and they all decide to collaborate on it. The group of contributors to this NDO doesn’t have the power to stop the forking process, but since there is a requirement of a process enforced by the governance of the NDO the agent that wants to perform the fork is given the chance of rethinking the decision. Perhaps he discovered that his resources can be merged with the resources of the group to accelerate the development and increase the potential benefits for all.
In some cases, forks are beneficial. The idea is not to stop them, just to provide some level of social friction to avoid knee-jurking forking, for no apparent reason.
Lastly, we need to append the mechanics of versioning, forking and remix for the residual propagation and diversification of project-type NDOs, in order to keep track of their proliferation, taking into consideration signals of trust / quality, application context, etc. associated with every branch.
In some cases, pressures to resist forking arise at the ecosystem level. This is the case of HealthNet, developed in the context of PEP Master, an open initiative to develop open source and DIY medical devices and associated software. In this case, the patient-doctor relationship requires a high level of trust, therefore forking a canonical NDO that has not been validated makes it unusable. This is part of what we call the Trust Economy scheme.
Commons are shared artifacts or assets that should be freed from organizational context and ownership.
Bob develops an open source irrigation system for his garden. Everything you need to know about this irrigation system is packaged into a single (composable) digital artifact and stored as a stand-alone digital artifact, a Resource. This digital artifact contains information about how to build the irrigation system (content), but also about how the irrigation system was created in the first place (economic data): Bob's activities, their type, duration, money spent on parts, the organizational context in which the work was done, everything is recoverable.
Lynn evolves within another organizational context, geographically removed from Bob. She would like to build an irrigation system for her own garden. She performs an online search and finds a digital artifact that Bob created, detailing an irrigation system, a model. She accesses the model using her own digital environment and can now follow instructions to produce the irrigation system. Whenever she has questions she can message Bob, right there, on top of this Resource, similarly to how we create comments in a Google doc and tag someone in it. But Lynn needs to add a new feature to this device, so she develops it and appends it to the same digital artifact that Bob first created (content), including some information about her efforts (economic data). The new version of this digital artifact will continue to live its life as a stand-alone resource, waiting for someone else to interact with it, use it, improve it, fork it or remix it with something else. It does not depend on its original creator, Bob, the same way the Bitcoin Network does not depend on its mysterious creator Satoshi Nakamoto.
1. Demonstrate flow of resources across organizational membranes
1. Demonstrate flow of resources across organizational membranes
We can take the easy case of digital resources and show how they can exist outside of an organizational context (outside a community, company, platform, etc.), providing the ability to search and retrieve, collaborate, improve or fork. This digital artifact would have no owner, i.e. anyone can interact with this asset according to a set of rules, and no one can have more privileges than what the rules provide for anyone else, no one is above these rules, no one can delete this resource. A nice add-on would be to make these digital resources real-time collaborative, with versioning and history (ex. something like Google Docs). Would be even nicer to associate with every digital resource data about the process of its creation (agents, contributions, commitments, organizational context, where they are used, etc.). This would require, at least:
Ability to represent stand-alone digital resources (a text doc for example).
Ability to create new such digital resources.
Ability to set interaction rules, including access permissions.
Ability to search/discover and view digital assets (text files), made by anyone.
Ability to create lists of digital resources in own digital environments.
Ability to modify such digital resources.
NOTE: This stage is under development as of July 2025, open doc.
Sharing processes makes possible interfacing open networks and communities.
Bob has developed an open source irrigation system for his garden and needs to make some modifications. To structure his work, he creates a Process, i.e. a plan of action, a series of tasks, associated with the stand-alone single digital artifact like mentioned in the previous story. This Process will have as an output a new version of the irrigation system and it expects as inputs the original version of the design and some resources, such as skills / time, money, materials, etc.
Lynn evolves within another organizational context, geographically removed from Bob. She would like to build an irrigation system for her own garden. She performs a search and finds Bob's fully functional irrigation system represented by a digital artifact. She also finds Bob's Process associated with this digital artifact, in which Bob is active, improving the irrigation system. Looking at the Process, Lynn has access to the latest information about Bob's attempts to improve the design, including all his contributions in terms of time and money spent on parts, even his failed attempts. She accesses the Process and can now collaborate with Bob on making the improvements. Once their work is done the Process is closed and all their activities and the new set of technical specifications are packaged into a single digital artifact, stored as a stand-alone Resource (the new version). This artifact will wait for someone else to open another Process to interact with it, use it, improve it, fork it or remix it with something else, to which someone else can also contribute.
2. Demonstrate processes shared by different organizations
2. Demonstrate processes shared by different organizations
We can take the simple case of Sensorica - TaoDAO interface, where peers from the two networks (organizational contexts) collaborate on content production (production of digital assets). For example, a blog post is co-created at this interface, peers from both organizations have access to the process (planning, tasks, roles, commitments, contributions, etc.). This shared process would produce a digital resource as described in 1. Note that this collaboration between Sensorica and Tao-DAO is mostly active in the context of Greens for Good. This would require at least:
Everything in the previous example.
Ability to represent a minimalist process associated with a stand-alone digital resource, in abstraction of organizational context and ownership.
Ability to create a new process.
Ability to assign a minimal set of rules to govern the process.
Ability to create lists of processes
Ability to search / discover processes created by anyone.
Bureaucracies can't deal with complexity.
Bob has developed an open source irrigation system for his garden and needs to make yet another modification. To structure his work, he creates a new Process, like mentioned in the previous story.
Lynn evolves within another organizational context, geographically removed from Bob. She once worked with Bob on this digital resource, but is now minding her own business. Bob needs some help with programming and creates a task that requires these skills, in the new Process. Because of her past contributions to this same Resource, Lynn receives a notification asking if she could help Bob, also offering her diner at her favorite local restaurant upon completion of the task. She accesses the Process and can now collaborate with Bob. Bob and Lynn package everything into a single digital artifact that is saved on a distributed database (as a stand-alone Resource). Once their work is done the Process is closed and all their activities and the new set of technical specifications are packaged into a single digital artifact, stored as a stand-alone Resource (the new version). This artifact will wait for someone else to open another Process to interact with it, use it, improve it, fork it or remix it with something else, to which someone else can also contribute.
We can build on the content co-creative process described in 2. The idea is to create a minimalist digital environment on top of the Resource, in which agents can interact via digital pheromones (described here). This would require at least:
Everything in the previous example.
Ability to represent pheromones in a digital environment (can be a comment associated with the Resource or a Process associated with this Resource, a To Do call, a call for a decision process). See more on pheromones.
Ability to create pheromones and associate them to Resources and Processes.
Ability to filter pheromones based on their type
Ability to subscribe to specific pheromones, based on filter.
Ability to receive notifications based on subscriptions.
In order to demo the above-mentioned features, we would need a way to store data permanently, in an unenclosable fashion, and a UI to interact with the Resource. When it comes to representations of digital work environments build around the a Resource we can take Daniel Harris' advice of user-defined interface, i.e. decouple the interface from the app, which is itself detached from the data. In other words, digital environments don't need to look the same for everyone engaging with the same Resource.
NOTE: All the above is just a preliminary proposition that will be refined in our discussions. This page will be kept up to date. You can ask for edit rights on Sensorica's Discord.
Some other info
Syn is an engine for unenclosable digital assets on Holochain. It enabled collective contribution to digital assets. It has been used on talking stikies and collective calendar hApps, which require collective contribution. We is a group ware hApp that creates an ecosystem of Syn based hApps, a groupware that enables federation and composability of different groups using an unenclosable digital asset.
hREA is one among the few resource planning protocols that enable seamless supply chain integrations. We can think of a module of NRP that exists in We, using Syn for representing an unenclosable digital asset.
Questions
Questions
An NDO (stand-alone digital asset) is represented as a DHT entry?
Why Not a hApp per Resource?
This would lead to:
Unnecessary complexity (every resource has its own DNA? → high overhead) -Loss of discoverability and composability across resources
Redundant logic — each DNA would replicate the same code Instead, a single or few shared DNAs (within a hApp) can manage millions of independent resources, each with its own rules, contributors, and history.
Think of it like GitHub managing millions of repos with one software stack.
Funding proposals
Funding proposals
NGI Assure - deadline 1th Feb. 2023 - failed
Get involved
Get involved
You can engage via Sensorica's Discord or hREA's Discord
Page updated
Google Sites
Report abuse