Differences between personal and organizational Agent apps

[bhaugen]

This is the beginning of an exploration of the territory for discussion at this stage, not a proposal.

As mentioned previously, an individual agent would act from their own Agent app, while if a organizational agent needed to execute its agency in some way, it would need an authorized individual to do that, and ~the individual would most likely act from the organization's app~. _Rethinking: all of the actions for group agents could, and probably should, be triggered from individual agent apps, either by agents that are authorized by the group to take particular actions on behalf of the group (and then the group takes the action like a bot) or by means of decision-making protocols offered to the group members by the group, again acting like a bot to offer the decision-making tools and then in executing the decision._

A lot of the apps that would be useful for an organization might also be used by an individual person, but maybe differently.

For example, both individuals and organizations might want to use Recipes and Planning.

But what happens if an individual wants others to help to execute a planned process? In an organization, that would be normal, and the process would live in the organization's app, while the individuals who worked on it would mostly take their individual actions (like committing to and logging work on the process) from their individual apps.

But for a set of people who want to work on a process together that are not a defined group with a group app, where does the process live? It could either live in the individual agent app of one of the participants, or the process could be shared by all the participants by each individual having a copy and the copies syncing with each other, or they could form a group agent or an adhoc group that might live only for the duration of the process.

Another set of differences might occur in forming relationships between agents, for example group-forming and membership apps.

Both individuals and organizations might want to form new groups:

• for the individuals, a new group composed of individuals or possibly both individuals and other groups;
• for the groups, maybe networks or other groups of groups, or subgroups or supergroups.

Groups might have membership apps with procedures for bring in, managing, or kicking out, individual or group members. Individual agents would probably not have membership apps.

But both individuals and groups will want to form a variety of relationships with other agents.

[bhaugen]

All of the agreements and interactions between agents, whether they be persons or groups, will need to have a local consensus mechanism so that each of the agents involved in the interaction agrees on what happened and was decided and what comes next, if that has been defined.

Besides communicating on an unreliable network with unreliable partners, they will need the usual security against the usual zoo of threats.

Next step in this exploration: use cases or user stories.

[bhaugen]

Starting to define user stories. These will be incomplete, mostly to get started and set patterns.

• Two personal agents meet.
  • They want to declare their association with each other. (E.g. friend, mutual follower, whatever).
  • They want to exchange resources with each other.
  • They can select the definitions of the resources they want to exchange from an available source.
  • They need to define the resources they want to exchange from scratch.
  • They can select the pattern for their exchange from an available source
  • They need to define the pattern for their exchange.
  • They just wing it, one of them transfers a resource to the other, and requests a reciprocal transfer.
  • Something goes wrong during their exchange.
  • After their exchange, something goes wrong with one of the resources they exchanged.
  • They like what they did and declare the exchange to be successful.
  • They have criticisms of their exchange.
  • They want to create something together.
  • They have a recipe for what they want to create.
  • They need to create a recipe first.
  • They just wing it and describe what they want to create vaguely and start to work.
  • They have the resources they need.
  • They need to get or create the resources they need.
  • Something goes wrong in their process of creation.
  • They successfully created something.
    • Now what?
  • They failed to create what they intended.
    • Now what?
  • They want to form an organization together.
  • The organization follows a known form.
  • They need to invent a new form of organization.
  • A personal agent meets an organizational agent.
  • Two organization agents meet each other through delegated representatives.

[bhaugen]

Very tentative agent-centric architecture for ActivityPub:

Agents could be individual persons or groups. Each agent, whether person or group, would get its own pub with its own database. All economic interactions between agents would be signed by each participating agent, and each agent would keep a record in its own database of all interactions it was involved in.

In addition, each economic interaction could designate a scope. A scope could be one of the agents (usually a group agent) or it could be a network, a bioregion, or any other area that a group of participating agents chooses.

If the scope is a group agent, all of the interactions mentioning the scope will live in the group agent's database.

If the scope is not an agent, then the participating agents could set up a pub for it, or include it as an actor in a designated pub, and the scope will have its own database.

[bhaugen]

Each agent would also form relationships with other agents, defined by roles, where a role would have its own properties, which could include some logic. https://www.valueflo.ws/introduction/agents.html

Here's a list of agent relationship roles from Sensorica:

Agents would federate with each other according to their relationships, and message traffic from outboxes of one agent to inboxes of others would be routed according to relationship roles and ongoing economic collaborative processes and exchanges.

Agent relationships could also live in scopes:

[bhaugen]

If anybody is looking at this, please ask questions, raise objections, suggest improvements.

[bhaugen]

Here's an example of group and personal agent relationships using an early stage of the VF vocabulary: http://holodex.enspiral.com/

You can click on one of the groups to expose its internal relationships. Enspiral Foundation is the scope.

[bhaugen]

Another aspect of the ActivityPub architecture is that all creation, updating, and deletion of database objects/entities/whatever-you-want-to-call-them is done via events: separate ActivityStreams messages that will be logged by each pub they come from or go to. Those logs could be organized as merkle trees:

They can help ensure that data blocks received from other peers in a peer-to-peer network are received undamaged and unaltered, and even to check that the other peers do not lie and send fake blocks.

[orangeman]

some thoughts:

The degree of decentralization in distributed networks is also known as "trustlessness", i.o.w. how much trust in the integrity of participants/hardware/software.. is required for the system to work. Not having to trust (other) agents (computer setups) improves agency and sovereignty and overall system resilience.

Loca data and many backup copies means not having to trust that connectivity is there and the hdd is fine. Encrypting data means not having to trust others to protect/respect confidentiality/privacy. Pubkeys as identifiers and signatures as auth-proof means not having to trust others to securely authenticate users and correctly enforce authorization rules. Hashes as (shared globally unique) identifiers means not having to trust others to not alter data and coordinate namespaces to map ids without collision (same data iff same id).

Merkelizing (with content-addressable cypherlinks) means not having to trust timestamps (clock sync) when (eventually) converging (consistent) shared state (consensus) after network partition. Hashpointers "trustlessly" proof order in time (as long as the hash function is cryptographically secure)

as seen in protocols: git, dat, ssb, ipfs, matrix, bitcoin, bit torrent, value flows

[almereyda]

We have moved the ValueFlows organization from GitHub to https://lab.allmende.io/valueflows.

This issue has been closed here, and all further discussion on this issue can be done at

https://lab.allmende.io/valueflows/vf-apps-agents/-/issues/1.

If you have not done so, you are very welcome to register at https://lab.allmende.io and join the ValueFlows organization there.