search

h-REA / hREA

A ValueFlows / REA economic network coordination system implemented on Holochain and with supplied Javascript GraphQL libraries
https://docs.hrea.io
Other
143 stars 15 forks source link

Requirements-level considerations for modularity #30

Open bhaugen opened 5 years ago

bhaugen commented 5 years ago

I'll add each consideration (think use case, but sometimes more general) in a separate comment with a heading. Occasionally do a summary. Feel free to add other considerations, summaries, or comments.

These pads were written as preparation for discussing HoloREA modularity:

bhaugen commented 5 years ago

Everybody needs to be able to access a lot of the data model

Everybody will need individual Agents and most likely Agent Relationships.

Even if you don't do any planning, you may need to see Plan data. And whatever you are doing, you may need to see elements of the Knowledge level. And the Observation level data will also be needed by more people than are actually logging Economic Events.

Recipe structures might be an exception.

bhaugen commented 5 years ago

Most people should not be able to maintain the Knowledge level

It's been a mess whenever and wherever that has been allowed. Knowledge level concepts, especially Resource Specifications, especially in networks, require significant care and agreement.

So while many people might need to access Resource Specifications, their creation and change should be controlled.

bhaugen commented 5 years ago

The same people will often do both planning and execution of plans.

See https://pad.disroot.org/p/group-agents for examples.

bhaugen commented 5 years ago

One likely smallish suite of apps

Smaller than the whole scope.

By "likely", I mean, I think this suite is likely to be used by more than one group.

fosterlynn commented 5 years ago

Agent Centric-ness

One part of the thought process that I'm not clear we totally understand: how does agent-centric-ness affect this discussion? I have my "ideas" about how that should work, but have not implemented it in any projects. And we know that in HC, there is no clarity on how group agents will work, if they even exist architecturally.

My thoughts are that agents, including group agents, have suites of modules that they use. But there are differences to consider. For example, we think that persons are the agents that will have user credentials of whatever sort. They will act on behalf of themselves or on behalf of a group agent. So they will need modules for both of those activities. I think group agents will want to have data storage for all of the group's data, which will be replicated on other agents' data storage who are interacting with and within the group. So group agents will need modules that are related to validating, storing, notifying, and querying their data.

Another piece of this is that transfers/exchanges are a bit different animals than processes (modification, production, transportation). Transfers are by nature between agents. Most process work goes on within the scope of a group agent (but not all of it). In a group agent, all the involved agents need visibility to processing. Transfers don't take place inside the scope of one group agent, and each involved agent needs a copy of the transfer.

[edit] Thinking of this as agent-centric, including group agents, I think changes things a bit from how I suspect HC thinks of apps/DHT/DNA scope. Like you wouldn't have an app/DHT/DNA that is chat for everyone, for example, or a type of economic activity for everyone, etc.