Skip to content

Modules in the HoloREA framework

Jump to bottom Edit New page
pospi edited this page Apr 1, 2020 · 41 revisions

Modules in the Holo-REA framework

Work in progress! Content not yet final, pending discussion with other Holo-REA core contributors.

To explore and understand the rationale behind this plan and architectural decisions, see System design rationale. This also covers some of the terminology 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 relationships

We suspect that the Holochain team might want to provide for this functionality, but aren't sure what the name for that is or where to look for it. The REA team also have a very flexible model for managing agent relationships that has worked well in real projects. Most of the organisational management stuff we've seen on Holochain so far has been based on rigid predefined hierarchical relationships between entities.

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.

It seems ideal to split this module into two zomes- one for managing agent relationships and another for managing group configurations.

The agent relationships zome deals with People, Organisations and recording the AgentRelationships between different entities- nothing further. It manages the governance system of a participant's collaboration space. Having a separate framework zome 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.

@fosterlynn: I wonder if it should be Person:Profile/Persona 1:M, or 1:1, or just the Profile is the Person and we handle equivalence in the vocabulary somehow?

@philipbeadle: what you have is, Device:Person:Personas:Profiles; so yes 1:M

@fosterlynn: Thanks, so 1:M. Note for future conversation, we will want Person:Device as a 1:M (or M:M?), so will need to reconcile that into the picture somehow. (Our Person tries to be actually a person.)

The capability management zome manages sets of zome capabilities across (and beyond) the REA suite of apps. For example- there is related functionality for querying REA Fulfillments on both the 'observation' and 'planning' framework DNAs. Users of a network will often want a shared space to store document attachments which refer to other records; or comment messages to anchor conversations off economic events. A typical 'genesis sequence' for an REA-based Open Value Network might be to deploy one of these 'master' capability management networks which in turn would install a set of dependent framework DNAs & dependent DNAs based on one's initial configuration options (chosen from a bundled UI). This functionality may also fall to "app bundles", but it's as yet unknown what this Holochain core functionality will provide.

It would also assign a set of initial capability grants to the agent deploying it, which that agent would then be free to delegate or share with other agents. The role played by a participant undergoing this process is very much one of the systems administrator.

We probably want this module to orchestrate permissions and bridging for agents who join & leave managed groups, and filter those permissions down through the connected / deployed networks via way of capability grants. In implementing this we may want a split- one zome for the governance processes & agent relationships, another for applying REA-specific capabilities to the rest of the network. The latter would be reusable with other governance frameworks, the former would not. Capabilities (and access control logic) are always local to each module- to modules other than agent relationships, the agents who interact with them are all just anonymous people who happen to have permission to do certain things.

[name=pospi] Turns out I've been interpreting capabilities wrong, so the above is not an appropriate design pattern at all. Holochain capabilities are agent-to-agent— they allow agents to authorise others to write entries into their own source chain. This means that their only applicability with groups is to have a trusted "shared agent" that others in the network can all write to... not ideal.

Rather than capabilities, it's actually standard Holochain validations which provide the necessary groupwise functionality. It will all be custom app logic, with a set of zome API traits that other DNAs will need to integrate with in order to make access & role checks against the group. Will probably develop a mixin zome to handle the registration of groups with a network, and library crates that client DNAs can build with. Will loop back and update the above once there is a working method... these things tend to be easier to figure out by attempting to code them than by speculating as to platform features.

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

  • Ontology modules for referencing agent & relationship classifications
  • Links DNA may be needed to extend network management functionality

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: on hold

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.

(*Note: in almost all cases, the default hard-coded actions are all that is needed.)

@fosterlynn: We think at this point that all the actions will be hard-coded. If a new action is needed, it would be good to get that added to ValueFlows. But we'll see how it goes...

Keeping this module separate from the recipe creation behaviours allows for a more refined data sharing approach than if the two were combined. 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

Collaborators

Observation

Description / rationale

This is the 'bottom' 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.

Collaborators

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.

@fosterlynn: Yeah, I wonder if intent matching, or more so budgeting, should be separate apps. Part of why I say that is that separate apps exist for those things now out in the world. Might depend on architectural considerations. Note the VF model for budgeting is under discussion, related to the discussion on Plan.

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

Collaborators

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.)

Collaborators

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

@sidsthalekar: Potentially, could this be used for non-material wealth like reputation? Validation of any form like claps, likes, ratings etc., which are acknowledgements more than transactions?

Collaborators

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

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

Collaborators

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.

@fosterlynn: I think this is a pretty loose part of VF and can use some work. I suspect that others will take on complex agreement logic (including smart contracts). What we do need in VF is something that acts as an "exchange", bundling commitments that are part of that exchange agreement. Many other kinds of agreements (like say a value equation, but lots of other things) may be referenced outside of VF with "under". Given all that, I'd recommend this should be pretty low priority. Also note that the commitments that are part of an exchange (agreement) are all part of planning, possibly as simple as an order.

@pospi: makes sense. I think it's good to have this super-simple form as part of the suite- simply so that we have a place to dangle something that semantically means 'agreement' in a note and tag some agents in it.

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

Collaborators

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.

@fosterlynn: Thinking about this, it is hard to imagine Proposal in a separate app from Intent. But it might make sense if we can't duplicate schemas in different apps. I have general questions about technical constraints on modularizing by feature or use case vs modularizing by data.

@fosterlynn: Under discussion in VF: the scope of Intent outside of Proposals.

Dependencies

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

Collaborators

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. 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 Holo-REA 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 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

  • May depend on a link indexing DNA for discovering connections between networks.
  • 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.

Collaborators

@pospi has a strong interest in assisting with the development of the value flow explorer UI. See valueflows/#507.

Specialised module breakdown

There are some specific use-cases that consumers of the Holo-REA 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

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.

Collaborators

@tommycp3 and @seajones7 have both expressed a wish to see this module developed.

  • 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.

Collaborators

@tommycp3 is working on this module along with collaborators at NXT.Legal.

  • Status: undergoing initial research & design

Dependent module breakdown

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

Personas

Description / rationale

The standard Holochain 'Personas & Profiles' hApp should be used to manage an REA agent's profile data- limited to name, image, email address, primary location & other basic fields. No bespoke logic is needed, the app services all needs via its detailed 'fieldspec' API.

Dependencies

None.

Collaborators

@philipbeadle is currently leading this project as of July 2019.

Links

Description / rationale

An external "link visibility network" for broadcasting links between Holo-REA (and other) networks. Such a network becomes very important in achieving one of the ultimate goals of Holochain— essentially, an ability to discover new content from neighbouring networks and click-to-install specific user interface applications for interacting with it.

Having a public broadcast space for linked REA data also plays a role in ensuring strong ethics and accountability in the value flow models used by different groups. REA itself has no particular ideological leanings, and it is accepted that 'improper' use of REA datasets may arise— not only can recordings be compromised but the resource flows depicted may omit important details and paint a more sustainable picture than the reality, especially when considering waste or pollution flows. The solution to combat this is visibility of links entering such an obfuscated network- this allows participants to spin up 'observation' DNAs around the offending data and 'fill in' the blanks with crowdsourced corrections and additions.

The most likely applicable format for the data in this module is the XDI standard- many fields of which can be filled in by the Holochain platform request context.

Dependencies

  • The hApp Store is needed to provide on-demand installation functionality

Collaborators

@lucksus is very interested in assisting with development of this module.

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.

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

Official Holochain project, originally started by @RyanHow. Looking for new stewards, please contact @RyanHow or @pdaoust if interested.

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.

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.

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.

Dependencies

None.

Collaborators

@pospi has already started work on this as a learning exercise, but it has been decided that their efforts are better spent on stewarding Holo-REA. The code is being used in Hylo's backend reliably. Module needs to be taken over for stewardship elsewhere. (@lorenjohnson? Perhaps collaboration with @forcize, @delroh, @nmitch17 of Humm?)

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 OAE 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

These are "end-user facing" applications which could be (and are being) built on top of the Holo-REA 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 Holo-REA 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 Holo-REA 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" Holo-REA 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

  • Something as detailed in @lucksus' ultimate goals linked above; probably similar to Noomap in appearance and functionality (Links)
  • 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