Holochain Forum

How will Holochain handle group agents?

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 :stuck_out_tongue:

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

In ValueFlows/REA terms, this gives the ability to generate all of the usual accounting reports plus new analytical reports and visualizations for each agent in a group, as well as the group itself, and when the individuals and multiple groups are part of a network (a higher-level group), for the network as a whole.

See also https://valueflo.ws/introduction/accounting.html and https://valueflo.ws/appendix/overview.html

@pospi cool, thanks for the clarification yet again. So a ‘stdlib’ sort of thing — a lib with the backing of the org and the community as embodying the patterns we’ve decided on for group agency?

The thing I’m struggling with now is how easy it will be to “provide visibility of the group agent’s internal audit trail [at] variable levels” with the primitives that Holochain offers. I can only see a few options (in this table, ‘marketplace’ means larger economic spaces the group acts in, and ‘group space’ means the internal economic space of the group):

Wish I’d brought my scribbling tablet with me; a drawing would make it much easier.

The key thing here is that you can’t bridge a DNA to another DNA — but an agent can bridge their DNA instance to another one of their DNA instances. Bridging always happens through the agency of one node. (Although that node could be the ‘group agent bot’ we were talking about earlier.) A “member in good standing” can simply mean “still a part of the group DNA”. So my big question about the private/complex square is, how do agents who do belong to the group DNA prove that they do? It still seems to fall back on some “group rules” entry in the marketplace DNA — something that says “here’s how to verify the proof of any agent claiming they belong to group X”.

But once you establish that you’re talking to someone who belongs to the group DNA, they can definitely give you a capability token that lets you make calls into their DNA — or rather, you can ask them to make calls on your behalf, which is how capabilities work.

Thoughts? My first thought is that proof of DNA membership has something to do with signature chains, with a signature root established in the public group rules entry. Revocations can be handled by those with authority to update that entry.

Count me in! Looks like I’ll be learning Rust and doing some library development in the new year.

heh, at present 100% redundancy is the only thing the network layer supports :wink:

Agents have relationships with other Agents. Forming groups is accomplished by creating Relationships. Relationships have Roles.

So if I have a relationship with some Group Agent, both me and the group agent will know, and can answer what the relationship is and what role I play in that group.

Lots of other logic can be built on those components.

I like the sound of that, yeah. Sounds like, if both the group and I know what our roles in our relationship are, the group can back me up if I claim that I can exercise a role. That seems to necessitate publicly accessible definitions of our relationship and roles — or at least accessible to the people who need to check that information.

2 Likes

how do agents who do belong to the group DNA prove that they do?

Third-parties are invited to the group’s DNA. They are granted readonly capability tokens for a restricted set of query API methods that they can use to query whether any agent is really a member of the group.

still seems to fall back on some “group rules” entry in the marketplace DNA

It falls to the “group rules” API logic embedded within the group DNA. All the marketplace DNA has is a zome API trait as contract that the group responds to queries in the way it expects. Standardised group agent implementations could be validated by network hash.

once you establish that you’re talking to someone who belongs to the group DNA, they can definitely give you a capability token that lets you make calls into their DNA — or rather, you can ask them to make calls on your behalf, which is how capabilities work.

Sounds sensible to me!

2 Likes

@pospi @pauldaoust @bhaugen thanks for digging deeper, sounds like we are making progress on the design. I’m pretty sure this will be useful for a lot of people in holochain land. :heart:

4 Likes

A possibly interesting and possibly useful discussion of groups in ActivityPub:

I’ve been having some really indepth and interesting conversations with @guillemcordoba around these topics in a private thread which I’d like to open out for discussion here.

First a quick update: Guillem and I have been scheming to start some weekly community calls (or perhaps I’ll bring them to the Virtual Hackalong) to build group functionality. The intention is to build independent modules which are useful along the way- this “agent registration” work is one of the first sub-components of what’s needed for groups. The other benefit to this approach is that it can be mixed with different membrane keeping logic (eg. “social triangulation”) for different use-cases without requiring edits to the agent registration code itself.

This zome-based composition seems to be working well, even if the tooling makes it a bit awkward in depending on all things being cloned locally (AFAIK you can’t publish zomes on crates.io since they have a different internal format. As an MVP for deployment we could use a similar “web URL + SHAsum” method to what Holoscape uses?). Git submodules have been suggested as a way of addressing this but at this stage I’m preferring to have a master manifest repository that checks out exactly one of each relevant repository, otherwise I may end up with submodules-inside-submodules and multiple diverging copies of the same repos on disk. (Note that you don’t have to use the manifest repo, you can just clone each individual repo into the appropriate sibling directories.)

Some reasons to get moving on group agents now:

  • It’s something that app developers will need to think about- they will have to understand its zome traits and know how to integrate the API calls into their own apps. This doesn’t apply to a lot of other things (reputation being one of them), because for reputation the data flow is one-way: eg. a “votes” DNA doesn’t need to consider reputation at all, because reputation DNAs will pull data out of the votes DNA and make their own calculations separately.
  • It impacts the modularity and maintainability of authentication logic. Breaking zomes down into separate crates will be a related necessary best practise in order for cross-DNA data architectures to be maintainable. In the breakdown I’ve done, it’s particularly important to split RPC data structures out from internal storage code and different-zome-same-DNA library functions: otherwise anyone who wants their DNA to call into yours will have to define their own structures to match yours and keep them maintained in parallel. FWIW this module structure took a lot of deliberation to arrive at, please take heed of the concerns and learnings driving the decision (;

There is a lot of overlap in terms of the modularity conversation and potential architectural repercussions, which I’ll try to summarise in a new thread.

3 Likes

Discuss this on tomorrow’s Hackalong? @pospi @guillemcordoba?

2 Likes

Yes! :smiley:

Great to see this being worked on, thanks all! :heart:

P.S. What’s the Hackalong?

Here is the introduction for the hackalong: Introducing the Holochain Virtual Hackalong

1 Like

Looks like some important collaboration is going on here; great to see it.

This is another, non-EU Hackalong, though, right? :o

Nono, this is the hackalong, everything is under control :slight_smile: It’s just that there are two sessions, one for EU/US and another for Asia/Pacific.

1 Like

I’ve put together a rough spec for some zome API traits that seem sensible for implementing a set of cooperating zomes to support “group agent” functionality.

All comments and feedback welcome :slight_smile: https://github.com/holo-rea/holo-rea/issues/9#issuecomment-637985563

2 Likes