That’s really interesting because I hadn’t thought of doing validation by interrogating the validation rules of another app to see if the source is valid. I had pictured it as validating using an apps own rules before storing some data.
Scopes came from the experience of Sensorica where it was called a “context_agent”. Sensorica was a network that was related to a lot of projects. Many of the projects want to be able to see all of their activities in the context of Sensorica, their network.
ValueFlows changed it to “scope” because elf Pavlik also wanted to use it for geographical areas.
So now it is very flexible: can be a group agent, or can be something else, depending on network needs.
Oh, sorry for confusing, I didn’t mean another app — I mean that, for every DNA that knows about an ontological entity known as “group agent”, that DNA has validation rules for determining whether an action that is purported to be an action of a group agent really is an action of that group agent. Hope that clarifies rather than confuses!
I think group agents could be very useful for validation. Would most likely also have some of their own rules.
We’ve been working on other pieces, but we are soon getting to where we need this for HoloREA.
What we think we want to do given the discussion:
- create a group REA-agent app that can be installed one per group REA-agent
- simplest thing possible to start with
- it will provide a way (similar to what @artbrock suggested) to do namespacing, creating a unique hash identifier for a group, which can be used across holochain
- it could be part of bundling apps into an installation for a group agent
- later we can add managing REA-agent relationships and roles, although we may need that to be sooner if we need role-based permissions
- for now for person REA-agents, we can use Holochain-agent (profile), as suggested by @yeff , but will eventually need something that represents the REA-person, to tie together person-on-phone and person-on-PC kind of thing
Would we like help? Sure, if there is interest!
- app requirements review and suggestions
- technical design help
- coding help
- financial support for a dev
1 Like
@zeemarx_jeremyboom8 your description is pretty close to how I have been thinking about it. Thanks for the additional angles, I think I like them, but we’ll need to get some experience with whatever mechanism evolves.
2 Likes
@zeemarx_jeremyboom8 thanks much for the response! Love your fluid vision and detailed description of how it could work with this technology. And hope I wasn’t implying group REA-agents should be corporations or anything like corporations. From your description I think SharedAgent is a group REA-agent, in addition to being an agreement among peers, let me know if you disagree. And I would love to see it in action.
For HoloREA, I think we will want to be governance agnostic for the most part, and be open to all kinds of experiments. Hopefully experiments that can plug in more or less seamlessly per each group’s desires, once a group has its unique ID and can bundle its suite of apps in some way. Step by step.
1 Like
@zeemarx_jeremyboom8 if I understand you correctly, I think this is along the lines of what @artbrock is suggesting too. The actions of a group are manifested by the actions of its authorised humans (where ‘authorised’ is defined in the constitution of the group — and that constitution can be encoded in such a way as to be algorithmically enforceable).
@lynnfoster @bhaugen @pospi it sounds like there a few orthogonal needs for ‘groups’; have I got them right?
- Group agency, both internal and in relation to external agents — people performing actions that are considered actions of the group. E.g., a purchasing agent buying things for the company, or an HR officer issuing paycheques. I think that the pattern described by @zeemarx_jeremyboom8 and @artbrock can answer that, for the most part.
- Group context — things pertaining to the activities of the group. I imagine this could be dealt with by creating a scope anchor for a group and linking events/resources/etc to it, just like any other scope.
- Group privacy — when a group wants its internal activities to be hidden, they could use a set of forked DHTs. I think this has some overlap with other things — e.g., it implicitly creates a scope, and it also gives various sorts of group agency to those inside the membrane.
I feel like I identified another, but can’t remember it, sorry.
1 Like
Here’s my list of use cases again: https://github.com/valueflows/vf-apps-agents/issues/3
@lynnfoster added some others.
@pauldaoust yes, thanks. I think the minimum we need to just get HoloREA working for any use case that has groups (almost all of them) is basically a simple app where a group can be defined and get a unique hash for its id. And we have workable ways to get that suggested in the thread.
Then there will be other things like you mentioned, probably sooner than later, but we can address those as we run into them, when people start using HoloREA.
I think this is a holochain-wide application opportunity, but we can do what we need in any case. (Says she who is not coding. 
)
1 Like
Thanks @bhaugen! You jogged my memory:
- Group continuity: it must survive changing membership, and all of its information must be retrievable by the right parties. I think there are a few aspects of this:
- External agency: the DHT of the greater contexts of the group agent (e.g., the bioregions, supply networks, markets, OVNs, and alliances they participate in) can hold on to their external actions, including the constitutions that define who can exercise group agency in those spaces.
- Internal agency: as long as someone is running the internal app, the data exists. For small groups it might be useful for someone to run a headless node just to keep the DHT alive.
- Ease of data retrieval: I like the idea of a ‘group bot’ that witnesses all the group activities. It’s not entirely necessary cuz you should be able to get all this from the DHT, but it could speed things up to have it recorded on one chain. It could also be part of the group’s constitution to have everything ratified by this bot.
Thinking about this:
- Authorized individuals could be act for the group in more than one way, for example:
- An individual agent who is an authorized member of the group sends a message to the group to cause the group to do something that only the group can do, for example, any of the use cases where the group does something.
- The authorized member could act “on behalf of” the group in some context where actions “on behalf of a group” are attributed accurately to the group.
I think the second option is definitely the most Holochain-idiomatic, although it does require changing a lot of assumptions about how economic exchanges work — and how they may be modelled in Holochain in a way that’s attack-resistant.
The big issue I see here is that, if we use the good ol’ pattern of counterparty signing + unbranched source chains, we run the risk of orphaned resources if one agent accepts stewardship on behalf of a group then disappears (device drops in the toilet, employee gets fired, etc).
An easy answer would be your first option, what I might call a ‘group bot’ or ‘group notary’. Not so Holochain idiomatic, but super simple to implement even with the current HDK.
oh @lynnfoster I see you responded while I was typing! Guess I’m getting ahead of things
3 Likes
Good to hear that is easy to implement. Is “sorta-kinda” holochain idiomatic in that it is basically making a source-chain like thing?? So a REA-agent-but-not-HC-agent can get some agent-like privileges and protections. Just takes agent-centric a step further… or not, but if it will work, that’s all we need…
Guess I’m getting ahead of things
Nah, keep it up! Thanks very much for engaging on this topic! 
I personally think there ought to be room for bot agents like this, even if they kind of go against the grain. Anyhow, there aren’t any technological barriers that I can see. The DNA does have to have rules/functions for the human agents and the bot agents, but that’s not such a huge deal. To clarify: this bot agent would be an REA group agent and a Holochain agent. Sure I’ll get some flak from Art for even suggesting this 
To clarify: this bot agent would be an REA group agent and a Holochain agent.
Oooh, I didn’t think we could do that… but if we can, oooh… (we gotta go, hopefully something more substantive later 
)
there are ways, all involving node-to-node messaging A node can respond automatically to another node’s message if it doesn’t need human intervention or outside data. Or it can use signals for more complex flows:
- Alice the cook wants to buy a crate of apples for the cafe. She commits a purchase order and sends a processing request via node-to-node messaging to the group bot.
- The group bot receives the request, emits a signal to take note of action required, and sends a response to Alice saying her request was received.
- The receiver of the group bot’s signal is a UI on the same machine, controlled by Bob, the cafe’s accountant. His UI receives the notification, loads the purchase order, and asks him if he wants to proceed.
- Bob says yes, so his group bot finishes the transaction with Carol the orchardist.
The UI could be completely replaced with a daemon that does nothing but approve requests, if that’s how the cafe is run.
I think there’s brittleness and robustness in both approaches.
- With agency exercised by humans in alignment with the group’s constitution, the group risks losing control of a certain asset (though not necessarily; depends on how you define your data structures and validation rules). But you don’t have a vulnerable central node processing all transactions.
- With agency exercised by a group bot at the request of human agents, the group bot is only as safe as the machine it lives on — Bob could walk away with the group’s entire agency if he’s having a bad day and quits. But it can be assumed that the bot node is managed by a trusted administrator, so the business’ assets aren’t at the mercy of a bunch of flaky individuals.
1 Like
Really enjoying the clarity that is coming through in this thread of late… hopefully I can add some more pieces to ground this (:
Other than what follows, in agreement with everything else being said here. And really appreciate the clear distillation from @zeemarx_jeremyboom8 of some of the common abstract logic at play. Validating to see the thinking here aligned with some of the fundamental insights I remember people in the blockchain space coming to as they developed programmatic governance systems (“multisig is a fundamental abstraction”).
group agency
An overlap here is “group accountability”, and it’s all intertwined with the mechanism for how to act “on behalf of” the group. Given that groups have no native agency in Holochain this means that abstractions for representing groups must be created, and APIs must be made manually compatible with them. So it will be up to each Holochain app whether it allows the participation of group agents or not. In terms of technical details, we think this requires onBehalfOf parameters at the zome API layer.
This means we need a standard set of APIs for dealing with groups. In REA, group agents can do anything that singular agents can do. So, any references to Holochain agent IDs also need to be able to reference group agent IDs. We think this necessitates a Holochain URI scheme- the document linked in this issue proposes a format which we believe allows us to elegantly differentiate agent, entry and DNA addresses.
We’re not sure what “group agent IDs” actually are in terms of Holochain’s fundamentals; but I think they’re probably DNA hashes. It makes the most sense to me from an encapsulation perspective to use permissioned DNAs to represent group agents; bridge them to other DNAs that the group needs to interact with; and internally code them with whatever governance rules the group wants to use (we have some suggestions, but they imply the development of that standard set of APIs to interrogate group agent DNAs for privileges).
You would end up with paired DNAs which store the group configuration data, and library crates which provide the API for other DNAs to make checks against the group’s membership and authority. Note that in this case we are talking about other DNAS, not other zomes- integration of something like this probably isn’t tied to a particular network, but interacts with many. So the interface would likely be via hdk::call rather than the internal entry & link manipulation API.
“checking with the group” pattern vs “ignorant DNA” pattern
(not a reply, just a heading :P)
The above is one path we could take, but it feels like a failing of “separation of concerns”. It would be cleaner if modules wanting to support group agents mostly didn’t have to think about the logic of group agents at all. The other path is to use the group agent as a controller DNA that mostly just manages capabilities in other DNAs. We described this as 2 complementary zomes which go together to form an “agent relationships” DNA.
Basically, there may be a lot of cases where groups are about delegating individual members to do different things. In these cases, the group could just be coded to delegate capability tokens to its members. More advanced cases, eg. where groups have “role based access control” internally, would potentially require other DNAs to inspect the group in order to verify authority. So I think it’s likely a mix of these two techniques.
Regardless, you still need to pass in onBehalfOf and deal with it if you want your modules to track the groups who’s authority was used to perform certain actions.
It’s for this reason that I believe this module needs to be treated as Holochain core infrastructure, and care given to standardisation and ease of adoption. Incompatible group agent implementations means incompatible hApps.
“orphaned resources” and continuity
I’ve recently put some thoughts together about what splitting out sub-projects might look like. For public and permissioned, discoverable sub-projects, you could certainly go down the path of running “headless nodes” to keep the DHT alive. But I think that’s a bit hairy.
You could make it less hairy for the parent org by registering sub-project members and network IDs within the organisation’s collaboration space. That way, at least you have a record of who was involved and can correlate any dangling group agent IDs with those people if the group has been taken offline.
Next level would be translating & replicating entries from the sub-project network into the main network. It’s essentially data duplication, but that’s not necessarily a bad thing in distributed environments with semi-permeable access membranes. For REA networks this is a per-record setting; because economic participants can enter event observations scoped for publication in many accounting scopes. Say for example the sub-project needs to enlist the skills of another worker from the group’s collective- they could publish an Intent into the sub-project that is also broadcast into the wider network’s skills marketplace so that a contributor can be located.
At the end of the day, there’s nothing you can really do about people creating entirely private groups that your parent collaboration space has no knowledge of. But at the very least we can create tools to facilitate easily “spinning off” projects in ways that are coupled with the “parent” collaboration space where the goal is to keep them connected. But you want loose coupling, because you want the sub-projects to be able to expand into collaboration with others outside of their originating organisation.
Ok, I’ve said a lot. Am I getting us closer to an MVP, or am I adding extra complexity? What do we pare all this back to?
2 Likes
Trying to think about architecture and grok REA lingo/needs at the same time. Stretches the brain, whoof!
@pospi when you say group ‘accountability’, what does that mean and how does it differ from agency? I mean ‘agency’ in the sense of ‘how the group is able to perform actions’, or more accurately 'who’s allowed to do things on behalf of the group.
I’m just going through your idea of having groups be manifested as multiple DHTs. I think that lines up with my vision? Not sure yet; still understanding eveything that’s been written. The way you’re describing it, it sounds to me like:
- one private DHT for the group’s internal workings (economic activity, governance, etc)
- one ‘group agency’ interface DHT that defines the rules for that group. This starts with some sort of ‘genesis entry’ that defines the initial rules and how they can be replaced. (E.g., maybe you start out with a partnership, and the rules say “only these two agent IDs may represent the group”, but then you hire some employees so you upgrade the rules to say “additionally, anyone bearing a grant for action X, signed by the two founders, can perform that action”. But then some employees get a little fast and loose, so you upgrade the rules to say “actually, employees X, Y, and Z all need to have every one of their actions signed by a higher-up”. Something like that.) Group representatives and people who want to interact with them both belong to this DHT, so that they can check the validity of actions via bridge calls rather than duplicating functionality in every single DNA.
- Action happens in a separate DHT, and everyone who receives an action must bridge to the group agency DHT to make sure the agent is allowed to perform it. I see an issue here, and that’s that we want to make validation deterministic. That likely means no bridge calls, because they could introduce changeable information. But there are two kinds of validation: entry validation (which is performed by third-party validators on published entries) and counterparty validation (which is performed by two people in the act of transaction, and can be as non-deterministic as you like). But if these two kinds of validation differ from each other, that creates a bit of a nightmare. I would love to figure out some way where the validity of your entry could refer to conditions that another DHT satisfies, and have the subconscious resolve those conditions behind the scenes. Don’t know if this makes sense; I can elaborate if desired!
1 Like
It means “being able to tell that the group was responsible for something”. Technically, that boils down to being able to refer to the group via its own unique identifier in every action that was carried out on its behalf.
one private DHT for the group’s internal workings (economic activity, governance, etc)
The group DNA only manages the internal governance of the group. Since economic activity is recorded in observation, planning and other DNAs which are entirely decoupled from the group and may involve agents other than the group, it is always kept in separate shared network spaces.
‘group agency’ interface DHT
For me this would be the same DHT as the aforementioned “group’s internal workings”; ie governance, permissions, access roles. The rest of what you’re saying about this DNA sounds aligned with my thinking. Except for-
Group representatives and people who want to interact with them both belong to this DHT, so that they can check the validity of actions via bridge calls rather than duplicating functionality in every single DNA.
I don’t think “people who want to interact with them” need to belong to the group’s DHT, but it may not pan out that way. I would prefer this not to be the case… it’s just a poor separation of concerns.
Action happens in a separate DHT
Yep. These are the related observation and planning DNAs.
everyone who receives an action must bridge to the group agency DHT to make sure the agent is allowed to perform it
Again, I hope not. I think it depends on the action- in cases where an agent has full authority to act on behalf of a group, the check could be handled entirely by a capabililty token within the target DNA; the group DNA should not need to be consulted.
counterparty validation (which is performed by two people in the act of transaction, and can be as non-deterministic as you like)
This is probably mostly what we have in Holo-REA (see #82 & #83). For our purposes we will probably have a separate API endpoint to sign an existing EconomicEvent, and have the API coded such that events which have not yet been counter-signed are interpreted as not existing until verified.
3 Likes
thanks for the clarification @pospi; it sounds like I’m mostly tracking with you but had some misunderstandings about how you were thinking about the group-as-agent in the wider world — specifically, how do agents interacting with the group-as-agent figure out whether a human acting on behalf of the group is actually allowed to perform that action? I misunderstood you as saying that this could happen in two separate layers: one DNA for economic events, and another DNA for defining and verifying permissions, and anyone who wants to interact with the group-as-agent would have to belong to both.
But if you’re saying that both of those roles could be collapsed into one DNA, that’d be cool. Or maybe you’re just saying that this would be true for simple privilege definitions. But I think it’d be possible to do it even for complex definitions, in a way that still permits changes to the group agent.
You suggested that group agency is something that ought to be supported by Holochain Core, and I forget where I read that. My current thinking is that it could be supported in app-land instead, by simply creating a library and watching it become the standard. Happy to be proven wrong though — what were your reasons for saying it should be part of core? I remember something about avoiding competing standards, but I wonder if you also brought up concerns about cross-DNA validation?
More ambiguous wording! English is fun huh 
It’s for this reason that I believe this module needs to be treated as Holochain core infrastructure, and care given to standardisation and ease of adoption. Incompatible group agent implementations means incompatible hApps.
“Core infrastructure” wasn’t meant to imply it should be part of holochain-core, just that it is something that should be abstract enough to have widespread utility and adoption (and set a good precedent for that); similar to the Personas or DPKI hApps.
To bring the private email chain I forwarded you yesterday into the light; I now envisage this situation:
- The reality is that some apps will need to query the group agent to determine particular permissions (eg. “has the group approved the action X to be taken on zome Y?”). I don’t think it will be possible to do what is necessary with capability tokens alone.
- Consider the group agent conceptually as “a record that some group of humans banded together and formed a group”.
- In an auditing situation, other networks interacting with group agents may want to know about the authority of those groups, the processes which lead to decisions being made, and the actual humans responsible for all of the above.
So accordingly— we create a group agent abstraction that:
- operates as a self-contained DNA.
- implements a set of zome traits that define how groups should be interacted with and queried.
- can implement whatever additional API endpoints and other logic it wishes to to manage the group’s internal operations, via use of “library crates” with bindings to “mixin zomes”.
- interfaces with “third party DNAs” by a similar mechanism to the
#[validate_agent]source chain initialisation hook. In other words, the group agent DNA needs to register with the foreign DNA in order for it to be allowed to participate. That registration would (by default) grant capabilities (via some group agent registry “mixin zome”) for all participants in the “third party DNA” to query the group agent DNA and check permissions.- (I’m saying “all participants” because I think that’s probably the sensible implementation, given there is no way to guarantee the breadth of impact a group agent could conceivably have on the data stored within a DNA.)
By the nature of Holochain’s architecture, this would provide visibility of the group agent’s internal audit trail to all networks that the group has interacted with. That visibility could have variable levels, if the generic capabilities we assign to the group agent’s query API are given more nuance.
For this we would need to get a working group together and define the protocol(s) for both the group agent zome API methods and also the permission structure to overlay on top of it.
I’m not sure whether or not core supports it, but group agents might be a good use-case for where you’d want your redundancy factor to be 100% of the network size. For small groups in particular, the likelihood that a majority of parties may collude to suddenly exit the network and leave data orphaned is not inconsequential.
1 Like