Nondominium and the True Commons

Part of Digital Environment, linked to Next Gen NRP

Last updated on Jul 3, 2025

Get involved

You can engage via Sensorica's Discord or hREA's Discord, or intervene directly in the working doc and Github repo.

Objective

Create simple demos using Holochain / hREA and based on Valueflows that could later be recycled into NRP-CAS development.

Reason: This would gather attention on the potential of Holochain, hREA and Valueflows to support glocal material peer production and stimulate capacity building for a fully functional NRP-CAS application to support open value network (OVNs).

Grounding: We would base this demo on a real case of an existing open venture, namely Greens for Good.

The basis

Holochain is beta, Holo will be live in mid 2004.
hREA has already released the first minimum-viable, feature-complete release with a stable externally-facing API
Greens for Good is an open venture with 2 years of demonstrated commitment, prototype-level hardware development stage, handling funding.

Read this interesting post.

Resources

Other notes

NOTE: this is a first proposition. There's also a document about this...

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 assets, which are openly shared under various permissive licences, as commons. Shared assets may represent code (software), or CAD files (3D models of hardware), and usually include instructions on how to use or build, as well as context. Eventually, these designs are materialized / fabricated by users or intermediaries. Hearing 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 the current technical reality, these shared digital assets are stored on platforms like Github for software, or Thingiverse for hardware designs, where they are subject to the platform’s rules and limitations and are not very portable (transportable accros platforms). Another major issue that plagues CBPP is the proliferation of random copies of files representing digital assets, which hinders practical collaboration. This problem is more acute in open source hardware, which requires much higher costs to implement and test and compare a version against others. By tracking content (in particular complex 3D models) and the economic activity data (use of resources, contributions with time, materials, money, etc.) using Valueflows, we can generate incentives for collaboration around canonical digital resources, similar to how collaboration is structured on Github, but without the aspects of platform centralization.

One purpose of true commons is to greatly reduce proliferation of clones, copies, versions of some designs, especially unrelated versions that evolve in silos. The problem of proliferation plagues the open source hardware communities, as it adds costs to getting the proper version for a specific application. In order to reduce this proliferation we can act on both sides of the problem: reduce friction to collaboration and generate positive incentives to collaboration. The current situation in open source hardware development and fabrication is spoiled by bureaucracy. Each project is managed by a group of individuals who have the power to accept or reject contributions from others. This is the situation on Github for example, where various governance models are used on the wide spectrum, from benevolent dictator to more democratic and consensus based. Apart from the human factor, which introduces preferences that are detached from the technical development itself, friction arises from the fact that one needs to develop some type of relation with those in charge, in order to have their contribution inserted into the canonical version of the design (into the distro). We can contrast this with Wikipedia or Bitcoin, offering permissionless (identity-blind and frictionless) access to participation. Keep these systems in mind for a second... When it comes to positive incentives to incite collaboration on a shared digital resource, rather than making a copy and developing it in another silo, we can provide two examples. First, there is a reputation reward for contributing to a shared digital resource. 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 these autonomous resources are augmented with contribution accounting and tied into tangible reward schemes, you can be paid for your contributions. That is precisely the goal of Sensorica, to use these autonomous resources, with autonomous processes within NRP-type systems, in order to make commons-based peer production self-sustainable.

Another motivation for the development of these true commons is to make them organization agnostic and detach them from any type of admin agent, as an entity that has special privileges over the resource. This requires solving a few problems: How do we mitigate spam or vandalism in a context without admin functionality? Various methods can be used, inspired from existing permissionless schemes: voting, consensus building, red flagging, etc. How do we recover quality control and adherence to standards in this context? The solution lies in the Governance layer, implementing access (inclusion) and validation rules for new contributors and contributions, coupled to incentive systems to increase the likelihood of quality outputs, respecting sound standard.

Lastly, we need to append the mechanics of versioning, forking and remix for the residual propagation and diversification of these resources, in order to keep track of their proliferation, taking into consideration signals of trust / quality, application context, etc. associated with every branch.

These new types of digital assets (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 rules
Organization Agnostic: Exist independently of any single organization. They are only associated with individuals as creators and contributors, not organizations.
Capture Resistant or Unenclosable: No single party can control or delete resources, Cannot be captured or monopolized
Self-governed: Rules driven (govern interactions with it, including modification)
- Roles: Set of activities or types of interactions that an agent can access with respect to the resource. Also related to custody (responsibility), maintenance (obligations), validation of modification requests, etc.
- Access control: Rules associated with roles, membranes, to grant permissions to modify resources and to validate requests to modify - can be anonymous using zero-knowledge proof.
Self-regulated: Peer reviewed, verified and tested (quality control)
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 (rules) and incentives to make unnecessary copying of a resource unlikely.
Shareable by Default**: Resources are designed for sharing and open collaboration
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.

One purpose of true commons is to greatly reduce proliferation of clones, copies, versions of some designs, especially unrelated versions that evolve in silos. The problem of proliferation plagues the open source hardware communities, as it adds costs to getting the proper version for a specific application. In order to reduce this proliferation we can act on both sides of the problem: reduce friction to collaboration and generate positive incentives to collaboration. The current situation in open source hardware development and fabrication is spoiled by bureaucracy. Each project is managed by a group of individuals who have the power to accept or reject contributions from others. This is the situation on Github for example, where various governance models are used on the wide spectrum, from benevolent dictator to more democratic and consensus based. Apart from the human factor, which introduces preferences that are detached from the technical development itself, friction arises from the fact that one needs to develop some type of relation with those in charge, in order to have their contribution inserted into the canonical version of the design (into the distro). We can contrast this with Wikipedia or Bitcoin, offering permissionless (identity-blind and frictionless) access to participation. Keep these systems in mind for a second... When it comes to positive incentives to incite collaboration on a shared digital resource, rather than making a copy and developing it in another silo, we can provide two examples. First, there is a reputation reward for contributing to a shared digital resource. 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 these autonomous resources are augmented with contribution accounting and tied into tangible reward schemes, you can be paid for your contributions. That is precisely the goal of Sensorica, to use these autonomous resources, with autonomous processes within NRP-type systems, in order to make commons-based peer production self-sustainable.

Another motivation for the development of these true commons is to make them organization agnostic and detach them from any type of admin agent, as an entity that has special privileges over the resource. This requires solving a few problems:

How do we mitigate spam or vandalism in a context without admin functionality? Various methods can be used, inspired from existing permissionless schemes: voting, consensus building, red flagging, etc.
How do we recover quality control and adherence to standards in this context? The solution lies in the Governance layer, implementing access (inclusion) and validation rules for new contributors and contributions, coupled to incentive systems to increase the likelihood of quality outputs, respecting sound standard.

Lastly, we need to append the mechanics of versioning, forking and remix for the residual propagation and diversification of these resources, in order to keep track of their proliferation, taking into consideration signals of trust / quality, application context, etc. associated with every branch.

Context of application: Breathing Games.

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

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

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.

3. Demonstrate stigmergic collaboration

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

Is a stand-alone digital asset represented as a file, a hApp or a DHT entry?

According to our latest thinking, a Resource is a structured entry in Holochain’s DHT that:

Has internal metadata (name, type, access rules, governance model, etc.)
Stores or links to file content (e.g., JSON, Markdown, STL, etc.)
Has relations to:
- its creation Process
- its contributors (Agents)
- usage in other Processes
- improvements, forks, and derivations
Has access governed by capability-based tokens Is stored immutably with versioning logic implemented in zomes.

This entry is written to the DHT, and can be linked to:

EconomicEvent (what process created it)
Process (production or improvement workflow)
Contributors -Governance metadata

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.

See working document

Funding proposals

NGI Assure - deadline 1th Feb. 2023 - failed

Get involved

You can engage via Sensorica's Discord or hREA's Discord