hREA demo for NRP-CAS

Part of Digital Environment, linked to Next Gen NRP

Last updated on Dec 20, 2022

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

Read this interesting post.

Description of work to be done

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


The objective of this project is to improve collaboration in commons-based peer production (CBPP). We do that by tracking contributions to digital assets using a hREA implementation of ValueFlows (VF), an ontology for modelling economic processes in a distributed network of agents, on Holochain (HC). For usability, we will add a locally hosted and user-controlled UI (Kendra.io) to search and filter existing digital assets and to interact with the VF data. This allows people to track the evolution of complex digital assets, like open hardware designs, as Git does for code, in its economic context.


We intend to demo a Network Resource Planning (NRP) module that tracks contributions to an uncapturable digital asset, in this case open hardware designs for the Greens for Good (GfG) project in Sensorica. GfG is building the prototype for an open source protein extractor.


Milestones:

1. Wrap Kendraio in electron-HC-runner

2. Create a connector to HC for VF data

3. REA implementation

4. Use Kendraio for developing user-defined interfaces to VF data for people who don’t need the whole planning interface

5. Allow specific files to be referenced as canonical in the VF data

Context: 

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.

Hearing the term ‘digital commons’ we assume it refers to assets shared-by-default, portable and uncapturable, allowing anyone, regardless of organisational affiliation, to further contribute to their development, fork and remix. The present technical reality, though, has these shared digital assets 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. Another major issue that plagues CBPP is the proliferation of random copies of files representing digital assets, which hinders practical collaboration.

By tracking content, in particular complex 3D models and the economic activity data, using Valueflows we generate incentives for collaboration around canonical resources, similar to how collaboration is structured on Github.

These new types of digital assets will be able to exist as standalone entities on a serverless infrastructure, with the following basic features:


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 digital artifact and stored as a stand-alone 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 organization 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. 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, where they are used, etc.). This would require, at least:

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: 

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: 

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

Funding proposals

NGI Assure - deadline 1th Feb. 2023

Get involved

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