True commons
Organization-agnostic, capture-resistant digital assets that exist as standalone entities on a serverless infrastructure.
The primary goal is to establish a technical foundation and demonstrate key user interactions for a collaborative ecosystem where resources, agents, and economic events can be tracked in a decentralized manner. A core objective is to design and prototype digital environments that support stigmergic collaboration —a form of indirect coordination where individuals are guided by the signals and artifacts left by others.
Overview
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 licenses, as commons. Shared digital assets may be computer programs (software), or CAD files (3D models of hardware), and usually include instructions on how to build, use, and maintain, as well as context. When it comes to the material p2p economy, some of these designs are materialized, i.e. 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 technological 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. Moreover, the type of governance implemented on these platforms is private property-centric, meaning that these assets are under the control of an agent (or group of agents).
One major issue that plagues CBPP is the proliferation of random copies of files representing shared digital assets, which hinders practical collaboration. We want to address this issue by incentivizing people to collaborate on the same branch of a digital asset and even make it difficult to simply produce a disconnected copy of such assets, while allowing and facilitating the creation of forks that preserve affiliation links and even propagate economic data.
Since the creation of Bitcoin, we have seen the proliferation of a new form of property, which we call nondominium, which is an uncapturable and organization-agnostic, not depending on a particular agent for its existence, not even the creator. The poster child of this new type of asset, living in the nondominimum property regime is the Bitcoin network. The Satoshi legend of the immaculate genesis illustrates very well the self-regulating aspects of these assets. True commons is an attempt to generalize and to allow the extension to include other types of shareable assets that spans the whole spectrum of property regimes.
By tracking content (in particular complex 3D models) and economic activity data (use of resources, contributions with time, materials, money, etc.) using Valueflows, we generate incentives for collaboration around canonical digital assets, similar to how collaboration is structured on Github.
Using Holochain, these new types of digital assets (true commons) can exist as standalone entities on a serverless infrastructure.
Basic characteristics
Take into consideration Resources and Resource Type.
- 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.
NOTE: A similar project has been recently proposed for blockchain.
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.