hREA demo for NRP-CAS

Part of Digital Environment, linked to Next Gen NRP

Last updated on Dec 14, 2023

Get involved

You can engage via Sensorica's Discord or hREA's Discord, or intervene directly in this document.

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.

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:

organization agnostic
capture resistant
permissionless (anyone can access unencumbered)
rules driven (govern interactions with it, including modification)
unenclosable / uncapturable
hard to clone (hindering proliferation of copies and unrelated versions)
allowing various property regimes, including nondominium (no one owns but everyone has access under certain rules)
shareable by default
- location (traceability, search and find)
- access control (governance, credentials, scheduling) - zero-knowledge proof?
- custody (responsibility)
- maintenance (obligations)
fully specified, machine readable: function, architecture, standards (dimensions, tolerances, quality), …
composable (aggregate into larger assets and pools of shareables)
able to interact with processes, in events like: create, consume, use, contribute with
- processes need to be organization agnostic as well
- peer reviewed, verified and tested (quality control)

The first purpose of true commons is to greatly reduce proliferation of clones, copies, versions of some design, 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 applications. 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 canonial version of the design (into the distro). We can contrastant pare this with Wikipedia or Bitcoin, offering permissionnaires (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 reptation reward to 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.

The first layer of development for these true commons is to make them organization agnostic and detach them from any type of admin, as an entity that has special privileges over the resource. The second layer is to solve the spam or vandalism problem. Various methods can be used, inspired from existing permissionless schemes: voting, consensus building, etc. The third layer is to append quality control mechanisms and standards. These rules for inclusion of new contributions and for quality control and standardization are part of the governance system around these autonomes resources. 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) 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.

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.

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.

hREA is one of the little resource planning platforms that enable seamless supply chain integrations. A module of NRP that exists in We, using Syn for representing an unenclosable digital asset.

We is a groupware that enables federation and composability of different groups using an unenclosable digital asset.

Questions

Is a stand-alone digital asset and process represented as a file or as a hApp?
Is this possible in the short term?
How many people do we need to work on this?
Do we need money and if so, how much?
What else do we need?

Funding proposals

NGI Assure - deadline 1th Feb. 2023 - failed

Get involved

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

Page updated

Google Sites

Report abuse