How will Holochain handle group agents?

[lynnfoster]

I’d like to get up to date with the current thinking about group agents. I know there have been a few discussions in mattermost and elsewhere, but I don’t know of any conclusions. And I’d like to also try to explain our needs in HoloREA as input to further discussion.

I understand holochain considers itself “agent-centric”, which is really important. So far it seems like that is limited to individual people (leaving aside for this discussion what is a user, persona, profile, etc. vs a person).

But groups also can have agency in the human realm. The simplest conventional example is of course companies of various sorts. But also less formal groups will have agency as a group if they want to and have some form of governance that can make that work. Yes, it can often (always?) be individual people acting on behalf of a group; but that doesn’t take away the group’s agency to act as a group. For example if a person makes a commitment on behalf of a group, and the person leaves the group, the group is still committed.

HoloREA treats agents of all sorts basically the same in the core model. (A of REA is for Agents.) Almost all of our known use cases involve group agents to some extent. Couple examples:

• A network of related food agents such as farmers, transporters, restaurants. The restaurants want to document where the food they serve came from. In HoloREA, you can look back along the chain to see how the food was grown on the farm (inputs applied etc.), and how it got to the restaurant from there. These events (the E) might include say some grain from a certain farm and even lot being transferred to a restaurant, and the restaurant transferring some money in return (or whatever, doesn’t have to be money). In any case, each event has a provider agent and a receiver agent. Those agents are the farm and the restaurant, not whatever people happen to be logging or approving those events.
• An investor engine wants to facilitate people (or groups) investing in holochain projects. If someone wants to invest in HoloREA, they don’t necessarily want to invest in any individual person. And when the investment arrives in HoloREA, the team might figure out together how to use it. And if money comes back from HoloREA to the investor, it should come from the group agent.

In addition, why should an agent relate only to one app or set of apps? Shouldn’t the farm in the first example be able to also use other kinds of holochain apps and still be known as the same agent? Perhaps it is a co-op farm and needs a decision-making app. For this reason, it hasn’t made much sense to us to develop Agents in HoloREA, seems too limiting.

So from our perspective, the requirements are:

• Cross-holochain persistent identity for each group agent.
• A way for the group to manage its relationships with other agents, like members, trading partners, etc.
• A way for the group to control permissions to its data, just like a person can.
• The ability to record a group or a person as an agent wherever agents are a relevant data element, in any app.

So, what do y’all think? Thanks!

[freesig]

I might be missing something but I think the way you want to group agents is with the actual membrane that they have access to. So to group a bunch of individuals together they would all be given access to a single membrane (which is the network associated with a particular dna).

Does this answer your question?

[lynnfoster]

Thanks, @freesig. Of course I could be missing something too, I’m not very deep into the technical details of holochain.

But it seems like a real-life group agent (a business, co-op, project or network with agency, etc.) would have several dna’s, like a suite of apps for the group, because groups do many things. So I don’t know if this could provide a definitive hash token that could uniquely identify the group agent based on just the dna or dht hash.

Perhaps some kind of specific “group agent” app/dna could do that for each group? Perhaps based on one known holochain app that would be used by each group to define and identify itself to the holochain world?

[dhtnetwork]

Perhaps some kind of specific “group agent” app/dna could do that for each group? Perhaps based on one known holochain app that would be used by each group to define and identify itself to the holochain world?

Hi @lynnfoster we spoke with Art about this topic today. With Holochain, actions, keys, and signatures are linked to an individual agent and not a group. The concept of a ‘group agent’ does not exist with Holochain.

Art said he will be providing a response to your inquiry.

[artbrock]

Lynn,

First, I think we need to clarify AGENCY.

Even though the “A” in REA accounting is the word “Agent,” the definition of Agent in this context is very different than the requirements in Holochain for agent-centric computing. In the REA context, an Agent is any abstraction who can enter into an economic agreement. Agreements can be made on behalf of individuals or groups.

However, in the Holochain agent-centric context, an agent is anyone with the agency to produce a change to the state of an application. More specifically, the ability to record the state change to themselves locally (with local time, sequence, and cryptographic proof of authorship) and then publish the state change globally to the DHT for validation. Even if YOU as a single human, want to run twitter-on-holochain from your phone and your laptop, those would be separate local chains and keys, hence separate agents.

So REA agency is about attribution and workflow. Holochain agency is about source of change. An abstract group is not a source of change. A purchasing agent authorized to act on behalf of that group could be. An automated trading engine able to trade on accounts could be. But in each case there an agent (or some workflow among a series of agents) which actually produces the change. This is what Holochain requires to be modeled very precisely since our data integrity model relies on provenance for all state changes.

Second, your requirements, seem to be able to be hnndled with workflows and name-spacing.

1. Cross-holochain persistent identity for each group agent.
2. A way for the group to manage its relationships with other agents, like members, trading partners, etc.
3. A way for the group to control permissions to its data, just like a person can.
4. The ability to record a group or a person as an agent wherever agents are a relevant data element, in any app.

1. Namespacing: You simply need a space in which to declare this group. One way could be to do it as a unique content anchor (using a format akin to the following JSON to ensure no namespace collisions by using state registration IDs) where the hash of this entry becomes a unique, persistent identity reference, usable across any DNA.

{
   "orgName"="HoloREA Accounting Club",
   "regJurisdiction"="Queensland, Australia",
   "regNumber"="137923729"
}

2. Workflow: You can define users (actual Holochain agents) and their roles and permissions within various workflows to ensure that the actions of these individuals who can actually perform state-changing actions conform to whatever level of group workflow validation you need (e.g. 3 signatures, or 1 sig from group A + 1 sig from group B (approvers) or whatever)

3. Workflow: Again, if by this you mean permissions to act or change state, it would be included in the roles, permissions, workflows as defined above.

4. Namespacing?: I’m a little unclear which usage of “agent” you are using in this sentence, but whether you want to use hashes of uniquely identifying anchors for groups, or public keys for Holochain agents, this is just a function of specifying what name space / address space you’re using. The unique identifiers remain unique and easy to use.

Third, the issue of private keys

To reason about agent-centric, cryptographic data-integrity in Holochain, you should ask these two questions:

1. Where is the private key held? By whom?
2. What source chain are changes written to? (and signed by the key in #1)

In your case of REA group agents, you can’t really answer either of these questions. The group doesn’t have a secret key. If it did, and you gave it to any users, they could act on their own without following any workflow. And what source chain do you look to to find the state changes of the group?

It may be possible to emulate a bit of this behavior, but you don’t fundamentally have these characteristics which are central to data integrity on Holochain.

1. In the future, we might be able to provide some multi-sig extensions which use homomorphic functions on the elliptical curves to emulate a “group” signature which is actually a mathematical combination of individual signatures. For now, I’d encode it in a workflow.
2. You can create an anchor in an app (possibly using the JSON pattern above) that you could link any state changes that an individual signs to their respective chains so that all members of a group could see any state changes applied to that group. Or a group might have it’s own DNA / private network context for such things.

I hope that helps!

-art

[artbrock]

@lynnfoster I didn’t directly reply or tag you, so I’m just making sure you know this response to your questions has magically appeared.

[lynnfoster]

@artbrock yes I did get it (“hearted” it to let you know, but that doesn’t magically notify either, does it? ). Thank you very much for a clear explanation and helpful ideas, it is much appreciated. And thanks for checking back! Was delaying a more substantive response (which will include more how we think we want to work with that) until we could have a full team chat about it, and also do more research into the Profile-Persona work, which may be connected. Coming soon…

[yeff]

Hi @lynnfoster and @artbrock tnx for clarifying.

HoloREA implements Value Flows - as you both know very well - and VF contains enough semantics to model an organisation/group as these are subclasses of foam:Agent. VF also blends in org:Organisation for added semantics so, that’s covered. VF adds the vf:AgentRelationship and vf:AgentRelationshipRole, so responsible (signing) foaf:Person(s) can be nicely modelled in the VF workflow.

A foaf:Person data “could be” covered via the Holochain identity app, which supports personas in which any data attribute can be used, at least that’s what I read here, so foaf:Person attributes are usable (wink to @philipbeadle).

So how I understand it, currently a Holochain agent is ONLY ONE person holding the identity key (private/public), absolutely agent-centric by design. With the identity hApp, a main identity can create multiple personas, each having their own keys that only the main identity can proof its from them, respecting privacy (correct me if i am wrong).

So what can we do “now” - since co/multi-signing is not (yet) supported by Holochain - to create an organisation for HoloREA/VF having these tools? I’m suggesting this:

• One person should create a Holochain persona specifically “representing” the organisation (identity hApp feature);
• (A bit of legal matters) If this organisation is a legal person, then this persona is NOT even private, it should be containing personal data that are verifiable via a notary act (inside the articles of association), which opens interesting possibilities for a hApp supporting this logic, but for now, it could be solved by adding a data attribute in the persona’s profile linking to a website where such notary act can be found (this is lo-fi, but better then nothing);
• The organisation agent’s Holochain chain is then bound to the persona (Holochain feature);
• With HoloREA/VF this representative person will have to get the appropriate role assigned (HoloREA feature), evidently using the correct persona (and hoping no mistakes are made). Fortunately, the hash of the persona identity is used in HoloREA and can be cross-checked by everyone, since this is a public persona. This might not be present in HoloREA at this very moment, but it should be a requirement for them (bridging to the identity hApp, wink at @pospi ), so this is sort of a half-gap;
• A Holochain hApp should deal with the approval of other organisation members, agreeing with this persona’s role. This - lets call it “organisation governance dApp” - is not included in HoloREA nor in the VF spec, nor is this part of the identity hApp, so this is a gap to fill by some.
• Then the economics, the group/organisation dynamics are all happening in HoloREA, particularly the distribution of value from the organisation to the members (persons). Off course, with the help of some Holochain current-see (when these arrive, we will see when). HoloFuel could be used, potentially others. So this is also a kind of half-gap, as I don’t know the status of these projects.

But the initial value will be collected by the organisation and only one persona has the key to that chain, and off course, that is a weakness - that some of the other crypto chains out there have solved - that should be solved in Holochain as well, “in the future” as said by @artbrock, using a multi-sig extension.

I hope this will happen not too deep in the future, as this is a vital governance instrument for any type of organisation, from a little restaurant (with 3 owners/workers) up to a farmers collective, to stay with @lynnfoster example. This touches the heart and soul of the Holochain community, doesn’t it?

I would love to see the gaps filled to get the new economics going, both with an organisation governance dApp and the necessary multi-sig Holochain infra in place, to support multiple organisation members governance.

[bhaugen]

An automated trading engine able to trade on accounts could be. [a Holochain agent…]

That is pretty much what I have envisioned group agents to be. A bot-like hApp. More at https://pad.disroot.org/p/how-group-agents-work

It would be able to have its own holochain token (pretend to be a user but nobody could/would log on as that user). But that gives it its own source chain, which would be nice. A group will want to have its own accounting and analytical reports, and group members will want to see the activities of their groups.

The group agent bot would make its own entries into its source chain, but it would do so either only or mostly on orders from an authorized member of the group.

The group agent hApp would also need procedures for making decisions and bringing in new members etc.

I can see at least two scenarios for group agents:

1. the group exists already and wants to bring itself into holochain as a group.
2. some individual agents meet in a holochain chat environment and want to set up a group agent to do something, like a Sensorica project.

Here are also a growing list of use cases for group agents:

P.S. so far, this is just my opinion. The HoloREA team has not had a chance to decide whether we all agree with every last bit or not. But Lynn and I are going on the road for a couple of days and I wanted to get it out there.

[pospi]

A few things I want to untangle here which I think are all important but separate projects; I don’t want some of them to get overshadowed or lost in others

Use-case: capability mangement for organisations

You simply need a space in which to declare this group.

[…]

an organisation governance dApp

[…]

So to group a bunch of individuals together they would all be given access to a single membrane (which is the network associated with a particular dna).

We saw this as two zomes: one for “agent relationships management”, one for assigning capability tokens for related DNAs managed by the permission management app.

We think there are probably helpers that can be created for capability management; but that each app will have different capability grants based on the access roles configured in its “agent relationships management” DNA.

Use-case: signing on behalf of a group

You can define users (actual Holochain agents) and their roles and permissions within various workflows to ensure that the actions of these individuals who can actually perform state-changing actions conform to whatever level of group workflow validation you need (e.g. 3 signatures, or 1 sig from group A + 1 sig from group B (approvers) or whatever)

[…]

In the future, we might be able to provide some multi-sig extensions which use homomorphic functions on the elliptical curves to emulate a “group” signature which is actually a mathematical combination of individual signatures. For now, I’d encode it in a workflow.

For us, this may mean including an optional extra parameter in our requests to identify group agents; but may also simply mean adopting a URI format for agents. A standard format to remain consistent with Holochain URI namespacing could perhaps work as follows:

• human agent (Holochain key): hc:AGENTKEY@DNAHASH
• group agent (workflow abstraction): hc:DNAHASH:ENTRYHASH
• group agent (DNA collaboration space): hc:DNAHASH

Potentially, “workflow abstraction” group agents are indistinguishable from human agents… I’m not sure what URI formats the core team are leaning towards…

Use-case: group notary

Nothing that special about this, it would be called an “oracle” in blockchain parlance. Basically a trusted machine with its own agent key that watches the DHT for events where it is the receiver, and automatically counter-signs them. We see this as a different workflow than “signing on behalf of a group”, where the purpose of signing is more about having a second pair of (human) eyes over the transaction than it is about witnessing the event.

[pauldaoust]

I like how this conversation is progressing. @bhaugen you’re bringing up some illuminating points about pulling data for reporting and whatnot:

But that gives [the group] its own source chain, which would be nice. A group will want to have its own accounting and analytical reports, and group members will want to see the activities of their groups.

Is this simply a matter of making it easy for a group to discover all the events its human agents have initiated, when those events take place in a larger space involving many groups? And the source chain of a group notary bot would be the simplest way of doing that? If so, I think I’m finally beginning to understand… (would love to have an actual Zoom call with the three of you about this, but time is scarce right now)

[bhaugen]

Is this simply a matter of making it easy for a group to discover all the events its human agents have initiated, when those events take place in a larger space involving many groups? And the source chain of a group notary bot would be the simplest way of doing that?

Those would be the entries that the group itself emitted, when an authorized member told the group agent to post something, if I understand correctly. Lots of other entries would be emitted by other agents that might mention the group agent as their scope, which would also be interesting for group accounting and analysis.

Best way to do all this stuff is beyond my current understanding of holochain internals, thus this forum thread and some side conversations with @lynnfoster and @pospi

[pospi]

On “signing on behalf of the group”, I’ve started an issue here to track possible configurations and permission schemes if anyone has input on what should be provided https://github.com/holo-rea/holo-rea/issues/83

[pauldaoust]

@bhaugen

@bhaugen

Those would be the entries that the group itself emitted, when an authorized member told the group agent to post something, if I understand correctly. Lots of other entries would be emitted by other agents that might mention the group agent as their scope, which would also be interesting for group accounting and analysis.

Thanks for your patience with my continued lack of understanding Is this statement correct?

• A group agent does things in the economic space that surrounds the group (e.g., a marketplace).
• A group scope defines the economic space for all inside-the-group activities (e.g., payroll

@pospi should we continue the conversation on your GH issue?

[bhaugen]

• A group agent does things in the economic space that surrounds the group (e.g., a marketplace).

Pretty much. A group agent is a group that has agency. Economic exchanges in a marketplace would be one example.

• A group scope defines the economic space for all inside-the-group activities (e.g., payroll

A scope is a reference on economic activities to some context that they are happening in. Could be a group agent or could be a network or a geographical area. Unless a scope references a group agent, the scope is not an agent in itself. But it could be used for accounting and analytical reports covering all the activities that referenced the scope.

[lynnfoster]

• A group agent does things in the economic space that surrounds the group (e.g., a marketplace).

Pretty much. A group agent is a group that has agency. Economic exchanges in a marketplace would be one example.

@pauldaoust I’m a little nervous about the phrase “economic space that surrounds the group” because what you mean by that is not clear to me? A group/organization agent can do mostly the economic things a person agent can do - trade, give, create useful things, deliver services, make promises to other agents, make lots of kinds of decisions. A group agent might have more complexity in some of these endeavors because it needs some kind of governance where people agree first that it is an agent and then how it should operate.

Just to be clear in the conversation, we are still using the term “agent” differently than holochain uses it, which is more technical, and involves what a user with a token can do in different technical spaces. We are thinking more of agency in the world irrespective of technology, maybe we should call it REA agent or something.

[pauldaoust]

@pauldaoust I’m a little nervous about the phrase “economic space that surrounds the group” because what you mean by that is not clear to me?

Here’s how I meant it: A group is a membrane. Outside the membrane, the group looks like an agent that wants to participate in a larger economic space (say, a bioregional market). Inside the membrane, we see that the group is also its own economic context consisting of its members and its concerns (the ‘whole under management’, to borrow from Holistic Management). Its agency outside its membrane is really just a projection of the agency of its members who are authorised to represent it (whether those members are individuals or ‘group oracle’ bots). Kind of a holarchic structure.

I agree that it’s tricky to talk about these things cuz Holochain has already staked a semantic claim on the term ‘agent’. Maybe ( REA group agent / REA individual agent ) → REA agent would be useful (on this forum at least, and only for the sake of newcomers to the conversation).

@bhaugen

A scope is a reference on economic activities to some context that they are happening in. Could be a group agent or could be a network or a geographical area. Unless a scope references a group agent, the scope is not an agent in itself. But it could be used for accounting and analytical reports covering all the activities that referenced the scope.

Sounds like it’s a persistent ID that identifies a context for economic activity; is that right? And I’m guessing that some scopes would want to be entirely encapsulated for privacy’s sake (you wouldn’t want payroll in a group scope to be leaked to the outside world), but other scopes would want to occupy a shared space?

[lynnfoster]

Its agency outside its membrane is really just a projection of the agency of its members who are authorised to represent it

Yes, sort of. Which could be more or less or not democratic. But it also seems a little more than that. For example, if the members change or just change their minds, the group agent still can’t just go back on prior agreements. Say it still needs to pay for something it purchased last month. And even member agents that are authorized to represent a group agent are not necessarily able to do what they would want to do as an individual agent, but might be bound by policies or other decisions the group has made about itself.

So I think there are some subtleties that make the agency of the group more than just a projection of the agency of its members, which puts things in more of a set of individuals mindset than a community mindset for example. Perhaps a sign of the times? I don’t think corporations are people by any stretch (reference is to a horrible US Supreme Court decision) - but I still think there is something that is qualitative about a group’s agency that is not just a sum of the members’ agencies.

[lynnfoster]

And I’m guessing that some scopes would want to be entirely encapsulated for privacy’s sake

Yes, degree of internal privacy would be up to the scope, which in your example is a group agent.

[pauldaoust]

Ah yes, I think I understand what you’re saying — it’s not just a projection of the agency of its members; it’s a projection that’s filtered through the things that define and constrain the group. Governance, acknowledged group membership, prior agreements, capacity to enter into future agreements, etc. If a group is defined as a set of rules, group agency is the collection of actions that conform to those rules.

Ideally in Holochain-land these rules would map nicely to entry validation rules, so that when you receive a piece of data from me that purports to be an action of a group agent that I claim to represent, you could analyze and verify for yourself that it really is valid. That’s the core purpose of Holochain’s validation rules, and validation rules are the core of a Holochain DNA.