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 
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.
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!
@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. 
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:
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.
Yes! 
Great to see this being worked on, thanks all!
P.S. What’s the Hackalong?
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 
It’s just that there are two sessions, one for EU/US and another for Asia/Pacific.
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 Implement compatibility layer for group agents · Issue #9 · holo-rea/holo-rea · GitHub
ah crap, I accidentally deleted my comment (comment #26) when looking through this thread and I can’t restore it. below is a copy from my notes. it came just before Bob’s comment.
the missing comment:
zeemarx / bergstromm466 - Dec '19
Hi @lynnfoster forgive me if this is too basic, but it looks like this could be achieved with a voting mechanism that allows people to approve, block or abstain from actions, using a vehicle that I’ll call SharedAgents. These SharedAgents are basically just cooperative agreements that allow chosen agents to execute recipes on the groups’ behalf if they have their ongoing consent. In other words, it’s a way to lend agency (for an agreed or indefinite amount of time) to others whom you trust.
Agents who are a part of a SharedAgent can revoke their consent any time they disagree. It might sound tedious and time-consuming, but I think we’re just not used to giving an revoking our consent or acting with full autonomy. I think in the future this will become a Common(ing) habit. Today when we work in a corporation we are giving up our power because without Sovereign Accountable Commons and the Holochain pattern it didn’t seem possible to have a deeper and cooperative level of ownership/involvement.
Taking part in a SharedAgent, your revoking or blocking can lead to an intervention, which can either (1) lead to a beneficial forkable improvement to the application, or (2) be a request for clarity from other members. The agent who intervened can then re-grant access when they are 100% on board again. I am thinking this SharedAgent could look like Loomio’s voting system represented in their decision making pie chart, with a history of shared actions, decisions and consent-giving and revoking.
Once established, the group can speed things up by the agents leaving their decision / consent on ‘yes’ with trusted colleagues. This way their peers can take numerous actions as the SharedAgent without having to ask permission each time. The group will be collectively responsible for any misfortunes, which acts as a natural incentive to improve and simplify documentation/training. The SharedAgent feature can be launched in tandem with a ‘listener’ app that sends messages to peers who can follow the tracks others leave behind, so they can offer support or intervene where needed.
I think we’ve all spent a lot of time waiting for corporations to help us through customer support call centers, or through bureaucratic systems at work. The technologies being developed here will allow a rapid ongoing evolution of social organisms and stigmergic cooperation that will outpace any other system.
For me it is beautiful to see how Holochain and HoloREA can make the complex web of rules and codes we follow in our daily lives much more visible and malleable. It allows us to respond to our community’s individual needs much faster. We will create forkable blueprints for other communities to copy, and for us to be able to copy theirs once they come up with something better. I think with Holochain and HoloREA we can strive towards apps and workflows that have more solidarity and compassion than what is possible today in our corporatist data-centric world.
Edit: I just reread some comments above and saw that @pauldaoust proposed a similar idea. I hope my description provides additional clarity.
