Skip to content

Modules in the hREA framework

Jump to bottom Edit New page
pospi edited this page Sep 14, 2022 · 2 revisions

Modules in the hREA framework

See Terminology for a description of some of the terms used on this page.

Core module breakdown

These are the set of modules deemed to be necessary to implement a general-purpose REA economic coordination network that can fulfil the most common real-world use-cases.

Agent profiles

A configuration layer for describing the profile metadata of various Holochain agents, and to facilitate the creation of abstract "group agents" which correspond to organisations rather than single-agent Holochain public keys.

Description / rationale

Holochain by its nature is fully agent-centric and manages provenance entirely on the basis of singular entities writing to its datastores. As such, there is no built-in facility for group management; and groups must be abstracted as they are in the real world— as groups of people with different roles local to the group.

In order to maintain a uniformity of how agents are described in REA terms, it is therefore necessary for all agents to be described via associated storage abstractions within a shared Holochain DHT local to each collaboration space.

Dependencies

None.

Status

Public beta

Agent relationships

REA has a very flexible model for managing agent relationships that has worked well in real projects.

Description / rationale

A common use-case in REA networks is to have application-specific behaviour in other modules coded to respond to different types of AgentRelationships. For example, a Person who is a member of an Organisation may have special privileges that non-members do not.

The agent relationships zome deals with recording the AgentRelationships between different entities- nothing further. It manages the governance system of a participant's collaboration space. Having a separate module to record this information allows for organisational structures to be experimented with and evolved more easily, without requiring the logic for managing the permissions stemming from such structures to be replicated in each module.

It may be accessed via other modules to perform access checks; though it is more likely that such access checks would reference their local Holochain capability register rather than data in other modules.

API compatibility patterns

The expected parameters needed to allow for delegated authority are detailed in this Github issue but the details are pending decisions to be made by the HDK core team.

Further reading

Dependencies

Collaborators

@thedavidmeister has been leading discussions on group-related functionality as it relates to Holochain's capability-based access control and has useful insight for anyone aiming to implement such behaviour. It seems certain that any delegated authority patterns will need to access the Holochain capabilities API in order to achieve their goals; and this API has not yet stabilised at the time of writing.

As such, it is recommended that development of this module be postponed until an appropriate implementation architecture becomes clear, and that extensive consultation with the Holochain core & HDK teams is undertaken prior to starting any development.

Status

Pending implementation

Specification

Description / rationale

This module is provided to manage the ResourceSpecifications which define the behaviour of types of Resources, ProcessSpecifications which define the behavior of types of processes, Unit types for measuring resources, and Actions which define the behavioural characteristics of different Events.

Such specifications need to be referenced in other modules when identifying resources & events (eg. observation & planning), as well as in flow planning workflows like recipe creation. It is also likely that they can be integrated with registry functionality in order to intelligently discover and manage the ontological relationships between data from different networks.

ResourceSpecifications, ProcessSpecifications, Units and Actions are tightly coupled since they form the core 'signal' grammar found within each collaboration space (where ValueFlows is the 'carrier' grammar which transmits the signal). As such, it makes sense to have these attributes encapsulated within the same module in order that other DNAs which need to know about the semantic cartography of networks can query them.

Being able to have globally accessible deployments of this module which come with preconfigured records that can be copied into localised module configurations seems like a worthwhile goal. For example, we could publish every measurement unit in the QUDT vocabulary into a QUDT specification DNA and groups who are setting up new installs could pick a starting set of measurement units from a list.

Dependencies

  • May have a dependency on agent relationships functionality for managing access, or may simply be administered by a participant in a 'sysadmin' type role.
  • Ontology modules for referencing related classification data

Status

Public beta

Observation

Description / rationale

This is the most concrete layer of the REA vocabulary and serves to record participant's observed details about the real world into an economic ledger. It includes:

  • EconomicResources (the 'things' in the economy) & EconomicEvents (which track when EconomicResources are transformed, transported, or transferred by Agents)
  • Processes (which transform or transport input EconomicResources into outputs)

Dependencies

  • observation isPlannedWithin zero or more planning modules:
    • An EconomicEvent may fulfill some Fulfillment
    • An EconomicEvent may satisfy some Satisfaction
    • A Process may be plannedWithin some Plan
    • A Process may have Intents to undertake it recorded against its inputs & outputs
    • A Process may have Commitments claimed against its inputs & outputs
    • A Transfer may explicitly log Commitments to 'give' & 'take' the resource
  • observation isGovernedBy zero or more agreement modules:
    • EconomicEvents may be recorded under some Agreement
    • EconomicEvents are a realizationOf some Agreement if they help to complete it
  • observation hasClaimsMadeBy zero or more claims modules:
    • A Claim may be triggered by a previously logged EconomicEvent
    • Claims may be settledBy any newly created EconomicEvents
  • observation isDesignedBy zero or more recipe modules:
    • A Process may be basedOn some RecipeProcess
  • Observation data may be mixed and matched between different networks (eg. a process completed partially within different organisational scopes)
    • Observation data may be 'broadcast' to other linked networks at the discretion of each participant in each action, with automated ontological translation of fields
  • Specification modules for referencing shared resource specifications, measurement units and action types
  • Ontology modules for referencing resource & process classifications
  • Location mapping to link observations & resources to physical locations

@fosterlynn: I don't think the need for data 'broadcast' between networks is a real one. If there is no organizational scope, then it will be done by different agents without considering themselves a team or project or whatever. But I think mostly there will be an organizational scope, and every agent working on a process will have some relationship with that organization. But, probably needs some discussion and an example, I may be wrong.

Status

Public beta

Inventory

Description / rationale

There is a future plan to move EconomicResources (the 'things' in the economy) out of the Observation module and into their own separate piece of functionality.

This would allow for experimentation with different architectures for inventorying, for example event sourcing for conflict-free updates vs explicit conflict checks to avoid double-spending. It also makes the complexity of deriving EconomicResource states from EconomicEvent inputs an optional feature that implementations can choose to skip implementing if they don't feel it is needed.

Planning

Description / rationale

The middle layer of REA is planning, which allows Agents to map out future events & processes and coordinate their actions toward completing them. It includes:

  • Intents (a specification by an Agent that they desire some action to occur in future)
  • Commitments (an acknowledgement by an Agent that they have agreed to perform some action)
  • Satisfactions (to record when Commitments or Events have contributed towards an Intent) & Fulfillments (to record when Events have contributed towards completing Commitments)
  • There are also some experimental structures such as Plan, which allows Agents to group related Events, Commitments, Processes etc into logical units for managing.

@fosterlynn: The name Plan and some details of the model are under discussion, but the structure is needed and has been used in applications in production. For example, a Plan is what is created from a Recipe.

Note that not all organisations use Intents - if an organization plans with no need to seek matches for Intents because the committing agents are pre-agreed, then planning can be done with just Commitments.

The planning module will be often used with the observation module for operational apps, as most organizations combine these functions, planning their work then recording the actual work. The planning module could be used by itself for such applications as intent matching, budgeting, etc.

Dependencies

  • planning isObservedWithin one or more observation modules:
    • Commitments and Intents are linkable as the input / output of a related Process or Transfer
    • Commitments may be fulfilledBy an EconomicEvent
    • Intents may be satisfiedBy an EconomicEvent
    • Plans can be linked to Processes which describe what work must be undertaken to complete the plan
  • planning isGovernedBy one or more agreement modules:
    • Commitments & Intents may be recorded under some Agreement
    • Commitments are a clauseOf some Agreement if they help to complete it
  • planning isCoordinatedWithin one or more proposal modules:
    • An Intent may be publishedIn a Proposal
  • Planning data may be mixed and matched between different networks (eg. a process completed partially within different organisational scopes)
    • Planning data may be 'broadcast' to other linked networks at the discretion of each participant in each action, with automated ontological translation of fields (eg. broadcasting Intents to skill & resource marketplaces)
  • Specification modules for referencing shared resource specifications, measurement units and action types
  • Ontology modules for referencing resource & process classifications
  • Location mapping to link observations & resources to physical locations

Status

Public beta

Recipe

Description / rationale

The 'top' layer of the ValueFlows vocabulary provides functionality for complex process templating, improvement and experimentation. This includes:

  • RecipeProcess (for declaring that a certain Process should be carried out as part of a larger task)
  • RecipeFlow (for indicating what type of Events need to happen via their intended Actions & RecipeResources)
  • RecipeResource (for defining the type of resource as it relates to the RecipeFlow)

Thus, this module provides an ability to create repeatable "blueprints" from planning & events undertaken in 'lower' modules, as well as deploying patterns to follow in the form of Intents, Commitments & Events in order to complete different tasks.

If an organization wants to plan from recipe (for repeatable production or business processes), then this module will be needed along with planning. If an app provides standalone facility for open recipe creation, this module should be sufficient.

Dependencies

  • Specification modules for referencing shared resource specifications, measurement units and action types
  • Ontology modules for referencing resource & process classifications

It is yet to be determined as to the appropriate coupling between Recipe modules and related planning & observation DNAs. It may make sense for a planning DNA to read the recipe definition directly from the DNA when creating a set of Intents & Commitments from recipe data; or alternatively, it may make more sense for the UI to pass the data through & perform some optional modifications on the way.

@fosterlynn: I picture a frequent use case that people planning and working will use other people's recipes. Open hardware designs kind of thing for example. Also, once planning is done from a recipe it often happens that the plan has to be tweaked. Once the plan is made, it is basically decoupled from the recipe, and does not know where it came from, except that is references "types" that are embedded in the recipe currently. I also think I need to rethink a couple things in VF based on this, also referenced above - but for ResourceSpecifications /classifications as well as process classifications.

@bhaugen: Depending on whether we want to do reactive replanning, and how we want to do it, the plan might need to access the recipe. The references to the "types" do couple the plan to the recipe, maybe sufficiently. If we allow multiple recipes for an output ResourceSpecification, we might need to know which one. But those considerations can wait until we have live user groups that want them.

@fosterlynn: I did a PR for ValueFlows to separate out the specifications (types) from the recipe. This should help, and I think that while we are waiting for VF to wind through its sometimes lengthy discussion, we should go with that here. In general, I think the planning and observation layers should be decoupled from the recipe, but will need to know their specifications. But I agree with Bob, we'll find out in practice. (We have practice with planning from recipe, but we haven't tried versioning and forking of recipes, or more than one recipe that creates a specified resource.)

Status

Unstarted, implementation TBC

Appreciation

Description / rationale

A separate framework DNA for handling "gift economy" appreciation data. Allows for EconomicEvents to be loosely linked in appreciation for one another.

It is thought it best to keep this functionality in a separate module as it both isolates raw production observation data to its own module in observation; and keeps contentious reciprocation logic isolated into a small decoupled unit that can be experimented with in different ways. It also allows for events recorded in different networks to be marked as appreciations for one another.

It should be noted that there are many differing views about how appreciations should be recorded in the gift economy— for example, some commentators believe that recording an acknowledgement transforms an act of gratitude into a transactional obligation.

Dependencies

  • appreciation recordsAppreciationsFor one or more observation modules:
    • Appreciation.appreciationOf some EconomicEvent
    • Appreciation.appreciationWith some EconomicEvent

Collaborators

We'd love to hear from anyone interested in building this functionality or in creating alternative implementations with different social considerations.

Status

Unstarted, currently low priority.

Claim

Description / rationale

A module which is perhaps the direct opposite of the appreciation module? Allows for participants to make a claim for future events based on the occurrence of past events and some prior agreement. You could look at this as being part of the gift economy, or as subverting the gift economy by providing a facility for participants to demand payment for past gifts. The outcome depends on how the module is leveraged- especially when considering who has the ability to create such claims (ie. the intended recipient or the provider of the claimed resources).

Given the way this plays into the social dynamics of the gift economy and contributory economies it is left as a separate module so that it can be experimented with and deployed independently.

Dependencies

  • claim isGovernedBy zero or more agreement modules:
    • Claims can be created under any previously created Agreement
  • claim isSettledBy the events in one or more observation modules:
    • The recording of EconomicEvents may trigger participants to create Claims
    • Observed EconomicEvents may settle the requirements of previously created Claims

Status

Unstarted, currently low priority.

Agreement

Description / rationale

A dedicated framework DNA for managing agreements between various actors allows for more fluid organising than if agreement data was bundled with any particular set of observation or planning data- participants can form agreements across organisational boundaries readily without needing to deliberate access permissions.

It also allows for more complex agreement processes or agreement records to be implemented in place of a basic no-frills agreement tracking module. For example, a conversation for action module could generate its own agreement data and be used in place of this DNA; or it could be connected via a bridge and simply drive the management of agreement records rather than re-implementing them.

Dependencies

  • agreement governs one or more observation modules:
    • An Agreement may have EconomicEvents recorded to track its progress
    • Any EconomicEvent may reference an Agreement that it is loosely a part of
  • agreement manages one or more planning modules:
    • An Agreement may require that Commmitments be logged to indicate that parties are prepared to carry out the required steps
  • Likely depends on agent relationships in order to manage more complex agreements between groups of participants

Status

Public beta

Proposal

Description / rationale

Proposals are a proposed addition to the ValueFlows spec which allows relating a series of Intents into a singular proposal to undertake some body of work. This may include specification of what the returns are intended upon carrying out the 'give' side of the work.

Rationale for keeping this separate is much the same as for agreement— namely, more fluid collaboration across organisational boundaries and an ability to experiment with alternative proposal creation & management workflows.

Dependencies

  • proposal coordinatesActionsWithin planning:
    • A ProposedIntent may publish any Intent considered part of the proposal

Status

Public beta

Ontology

Description / rationale

A robust ontology system for defining the classifications of Events, Resources, Processes & AgentRelationships is of utmost importance when considering implementing a ValueFlows app. Essentially, defining your own terms here means you're making it harder for other economies to integrate with yours (eg. if you have two different ontologies with ideas about "tomatoes", you are going to have to translate between those two types of Resource classifications when managing interactions between them. If they are the same, it already works without effort).

It seems sensible that the ontology service always be deployed as a separate isolated DHT so that ontologies can be readily used between networks without also needing to share actions & resource specifications. We will probably also want multiple ontology DNAs per network, and want to leverage redundancy by having more commonly used ontologies shared between networks. It also likely makes sense that every existing semantic web ontology be deployed as its own DNA, and that these be global public services which anyone can join and help to distribute.

@fosterlynn: A terminology note to minimize confusion. Some people (like me) would call this "taxonomy", although it will include more than taxonomies - other classification schemes like facets, tags, etc. So maybe "classification" or something similar. Those people would call models like REA an "ontology" (a domain ontology in that case) - because it contains relationships besides hierarchy. I understand some people use the word "ontology" in the way used here, at least for the taxonomy structure. So all cool, maybe just clarify the definition somewhere.

An added benefit we get when using Holochain for ontological storage is versioning of ontology data, which we don't get with the current web. With Solid, for example, if the person hosting an ontology you're referencing decides to change it you have no visibility of this and can't do anything about it (unless they provide a Linked Data Notifications service, you have subscribed to it, and you have setup your own storage / logic to manage updates).

@fosterlynn: That's a big benefit if mostly true. It makes me nervous though in terms of keeping things in sync. But I don't have any real opinion on it yet. If we just use the web, where does retrieving web based linked open data happen in the HC architecture? and how does it get updates from that system of record?

@pospi: It doesn't. If we "use" web-based architecture, we would simply be using the URLs of semantic web ontology terms as IDs from within Holochain. There would be no real linkage or updates, except when done manually (probably only at import time).

Dependencies

None.

Collaborators

Despite the importance of this feature it is a low priority for the hREA dev team, who need to focus on the core ValueFlows system first. Appropriate emphasis on the importance of good ontological choices should be made at every available opportunity when assisting app developers with the creation of ValueFlows systems. We acknowledge that this is a far from perfect solution, and that developers are lazy. Some mess is bound to occur which will have to be resolved when proper stringent ontological frameworks are in place... but hey, it's an imperfect world and this is the nature of software. In the meantime developers should simply reference existing semantic web ontology terms via their absolute HTTP URLs.

Good places to start searching for common vocabs are https://lov.linkeddata.es/dataset/lov and http://linkeddata.org/data-sets. Also check out https://www.wikidata.org/wiki/Wikidata:Main_Page. And there are lots of domain specific ones - the food/ag group has a number identified.

Status

Unknown, though some pre-existing work likely exists.

Registry

Description / rationale

Some public registry of all REA-based networks is also likely to be needed. This would be similar to the "hApp of hApps"- kind of like an app store.

In addition to registering networks for discovery, it will likely also need to contain some metadata about the various networks to assist new groups in integrating. This includes, but is not limited to:

  • The ontologies that each network uses to describe its resources, events & processes. In other words, the language spoken within the network.
  • Expectations for how other networks may integrate (which types of records are considered to be useful in marketplaces, for example).

Further details will be uncovered naturally as development progresses.

Dependencies

  • Likely depends on the specification DNAs from different networks in order to discover resource & action types.
  • Will probably also depend on the observation and planning DNAs from other networks in order to explore and make visible their flow data.
  • Depending on the amount of detail desirable in the master flow explorer UI, could bridge to yet more apps to (for example) show the status of agreements between networks by accessing an agreements DNA.

Status

Unstarted, implementation TBC.

Specialised module breakdown

There are some specific use-cases that consumers of the hREA framework will likely want solved in some particular scenarios. Good examples are environments that require more legal rigour around agreement management procedures, repudiation and accountability.

Value Equations (income distribution)

A Value Equation is an algorithm originally proposed by Lynn Foster and Tiberius Brastaviceanu as part of Sensorica's original NRP system. Value equations codify sets of contribution / reward agreements and manage automatic equity distributions in response to recorded REA event observations.

Further reading:

Dependencies

Status

Unstarted

Conversations for Action

Description / rationale

Conversations for Action is a framework which describes a simple state machine to model the process of Agents coming to agreement about a task to be performed or trading of resources. This is useful in situations where insight into the current progress of creating an agreement is needed. VF intends to also extend this for multi-party agreements.

Though not defined yet in ValueFlows, the intention of the module in VF terms is to enable Agents to agree upon the Commitments they will make together in order to satisfy an Intent or ExchangeAgreement. We feel the best way to implement this is in a decoupled fashion such that the input flows are referenced by ID.

Further reading:

Dependencies

  • Could be coupled with a threaded conversations module in order to not reinvent the wheel and keep the human-readable conversation data separate to the CFA machine status.
    • Possibly has advantages in discoverability;
    • Possibly disadvantages in being able to see the conversation outside CFA context (may lead to participants breaking association between ongoing dialogue and CFA status).

Collaborators

@bhaugen has a strong interest in consulting on development of this functionality with anyone who is interested in the implementation.

Status

Unstarted

Compositional smart contracts

Description / rationale

These will be a useful component in many cases where legal enforceability is desired to hold an agreement in place.

Further reading:

Dependencies

TBC.

Status

Unstarted

Legal dispute resolution

Description / rationale

A useful component for any collaboration spaces coordinating loosely-trusted parties who may require help in solving disputes from time to time. We could focus on Alternative Dispute Resolution (ADR). Alternative Dispute Resolution is an umbrella term for a variety of means designed to assist people and organisations to settle a legal dispute without having to go to court. The current accepted ADRs are:

  • Mediation
  • Conciliation
  • Arbitration
  • Justice Mediation
  • Collaborative Law

As a first cab off the rank, we could focus on one of these out of court legal processes where each party submits written evidence of their case.

All these also need to fall under a jurisdiction.

Dependencies

TBC.

Status

Unstarted

Dependent module breakdown

These are lower-level modules which are not considered part of the hREA components, but are necessary building blocks in order for an REA-based collaboration space to function.

Location mapping

Description / rationale

Many records in ValueFlows reference a location where something occurred or was located. It makes sense to keep such locations in a separate module such that they can be shared between other modules easily. It also makes sense to have external parties collaborate in such mapping activities in order to facilitate sharing and discoverability of new locations. We also want to provide for groups which share location data with different expectations of privacy- achievable by allowing multiple location databases to reference other network spaces.

Dependencies

None.

Collaborators

@vanarchist has been working on a module which uses geoJSON for location data. It uses geohash to group points into buckets to reduce DHT hotspots.

Status

Unknown (contact author)

File uploads

Description / rationale

Utility zome- most components are going to want such functionality. Integrators will also want an ability to have a mixture of different file repository networks, with different levels of trust extended to collaborators.

Dependencies

  • May depend on an indexing DNA for fulltext search capability over document content.

Collaborators

@GuillemCordoba is developing an implementation of file uploads in the HC Open Dev Github group.

Status

In progress

Indexing

Description / rationale

Similar to the Holodex written for the Holochain Go prototype. It may be highly advantageous to have a plug-and-play module that can provide high-performance search capabilities over data from other networks so that such functionality does not have to be written within the source DNA each time.

At present, there is indexing functionality included within hREA as locally stored search indexes within each module.

Dependencies

None.

Collaborators

@willemolding has expressed an interest on working on this app and essentially packaging up holochain-collections for easy integration in other DNAs.

Status

Various experiments ongoing.

Threaded conversations

Description / rationale

Pretty much every piece of data in REA needs an ability for participants to comment on it, negotiate & generally discuss things. An abstract "comments" module could easily service this functionality with the correct architecture.

The Flux codebase is likely to provide pluggable commenting functionality as part of their "social toolkit" in the near future, in a format that would be easily combined with hREA's modules.

Dependencies

None.

Collaborators

Other than the efforts of Flux, there is also a very outdated but much simpler threaded comments implementation created as a learning exercise here. It is mentioned as it fills all necessary requirements for this module, namely: an ability to use any arbitrary URI as a comment anchor, and an ability to thread recursively.

Status

Experiments ongoing.

UI framework

An important part of the roadmap is migrating all the UIs building value-based Holochain apps toward using GraphQL to interface with the DHT. This enables composition of multiple ValueFlows applications at the UI layer, including implementations authored on other platforms (such as Scuttlebutt and ActivityPub). To quote the Open App Ecosystem description: the goal is to make experimenting with "transparent, democratic, and decentralized organizing" as frictionless as possible.

Some effort needs to be put in to align us all on common UI patterns and reusable UI kits. With so many efforts underway it is hard to know who should take the lead on this.

That aside, all ValueFlows-based apps (Holochain, Scuttlebutt, ActivityPub / Solid & Django) are converging on the vf-graphql specification for their API bindings. Building to this standard will ensure that any UI components created for VF apps can be pulled into other systems and correctly link up to other backends with zero coding or reconfiguration needed.

Listed in order of start date:

See also https://github.com/valueflows/vf-apps.

UI collaboration

There is some ongoing thought between @pospi, @ivanminutillo and @lorenjohnson about how to structure UI toolkits, with the last documented thoughts between @pospi and @ivanminutillo available here.

Another thing to note about UIs is that most groups seem to be focused on React. It may be time to move past this into W3C standard web components; so that UI kits can be used in vanilla JS apps as well as React, Angular, Polymer or anything else a developer might choose to create a UI with. Svelte or Stencil could be appropriate technology choices; but support for Flow or TypeScript, as well as the difficulty of integrating routing & GraphQL UI components, needs to be explored further.

UI applications wishlist

These are "end-user facing" applications which could be (and are being) built on top of the hREA DNA modules. Note that they also aim for compatibility with Scuttlebutt, Django and other REA implementations via the vf-graphql schema bindings.

Each application is listed along with its DNA module dependencies. Those under active development are expanded with details & current status of the project.

Network configuration

General-purpose functionality required for configuring & managing groups and organisations in fractally composable Holochain networks.

(Holochain Core functionality?)-

  • Network deployment wizard (?)
  • Network connections management (?)
  • Visibility of managed networks and the users whom have access to various capabilities within the network (?)
  • Profile pages for editing one's own details in the REA ecosystem directory (Personas)
  • Administration dashboard for configuring organisational structure and permissions / capability grants (Agent Relationships)

(Indexing & discoverability)-

  • Network index showcasing and describing the economic activity of every publicly registered hREA collaboration space (Registry or built-in Holochain hApp store functionality)
  • Master value flow explorer allowing traversal of resource flows between networks (Registry or built-in Holochain hApp store functionality; plus connected Observation, Planning & potentially Recipe DNAs)

Knowledge management

  • Semantic data explorer, similar to eg. TopIncs (Ontology)
  • Ontology mapping capabilities for authoring translations between networks (perhaps stored in separate DNAs) (Ontology & Specification)
  • Management of any supporting ontological bindings which may assist with interpreting a collaboration space's data records (Ontology)

Economy configuration

More or less any application integrating with hREA will require these interfaces to be present in order to configure and set up a network.

  • Administrative configuration interface for managing available resource, process & unit types (Specification)
  • UI for importing predefined configurations and/or knowledge definitions from other DNAs (Specification)
  • UI for managing linked ontology data in resource & process specifications (Specification & Ontology)
  • Interfaces for connecting & managing linked ontology data accessible in recipe authoring workflow (Recipe & Ontology)
  • Graphical value flow design interface for building recipes (Specification & Recipe)
    • @pospi has a strong interest in assisting with the development of the value flow design interface; see valueflows/#507.

Operational system

These are "runtime" hREA modules which the bulk of participants interact with in their daily activities.

  • Supply chain provenance & resource tracking apps (Specification & Observation)
  • Inventory management (Specification & Observation)
  • Project management (Specification, Observation & Planning)
  • Work logging & time tracking (Specification, Observation & Planning)
  • Skills marketplace / Intent matching functionality (Specification, Observation & Planning)

    @fosterlynn: There will be other kinds of intent publishing and matching than skills. Also it will be for stuff, think classified "ads" (for lack of a better word atm), or even most of e-commerce.

    @fosterlynn: I have also wondered if it makes any sense to split transfer/exchange and process/produce into different apps. There are a lot of apps that are for exchange, but don't want to do any production. Don't know the answer.

    @pospi: like what you're thinking on all of the above. I haven't listed "marketplace" as a UI in any DNAs yet since I was thinking that marketplaces might be domain-specific third-party DNAs which connect to the related networks they're brokering between to add the intent matching functionality there. But you're right, we also need that as a UI somewhere in this mix so there's a built-in one for participants based in the same collaboration space. And we can pull that same UI into higher-order marketplace components we might build down the track for easily connecting economic networks via resource exchanges.

  • Perhaps a "gratitude dashboard" showcasing the giving in one's local economy, similar to @utunga's designs for KinPesa (Specification, Observation & Appreciation)
  • Status dashboard allowing users to see the progress towards settling their open claims (Specification, Observation & Claim)

Agreement management

  • View & inspect prior agreements with other participants and check on the progress of agreed work (Specification, Observation, Planning & Agreement)
  • View & inspect prior proposals with other participants and check on the progress of agreed work (Specification, Observation, Planning, Agreement & Proposal)
  • Matchmaking features to locate proposals which may be of interest (Specification, Observation & Proposal)
  • Interfaces for viewing current agreements being attempted and progressing through the CFA process (CfAs, Agreement & Proposal)
  • Ability for parties to pre choose their jurisdiction legal process before entering into an agreement (Legal dispute resolution)
  • Interfaces for viewing current agreements and ability to select transactions to escalate to a dispute resolution process (Legal dispute resolution, Agreement)
  • Forms for parties involved in dispute to submit further evidence (Legal dispute resolution, Agreement, Planning, Observation & Specification)
  • Interface for a chosen mediator to review all further information and final decision made where economic resources could be requested to be redistributed and perhaps a ranking system if an agent does not follow through with the legal resource reallocation order (Legal dispute resolution, Agreement, Planning, Observation & Specification)

Dependent functionality

  • Map interface for authoring and exploring geospatial datasets (no proprietary UI frameworks preferred- use Leaflet & OpenStreetMap instead of Google Maps!). Ability to share and collaborate on mapping efforts. (Location Mapping)
  • File manager for accessing, searching and viewing all files (File uploads)
  • A powerful search interface similar to LogStash or GrayLog which redirects to the appropriate app for interacting with matched content (Indexing)
  • Conversation dashboard; something like an email client for checking your messages and responding to posts (Threaded Conversations)
Add a custom footer
Add a custom sidebar
Clone this wiki locally