Hub/Agent Action Meta Protocol

Hub/Agent Action Meta Protocol

Thursday 13A

Convener: Sam Curren

Notes-taker(s): Thomas Berry & Sam Curren

Tags for the session - technology discussed/ideas considered:

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

1. Notes received from Thomas Berry:

Action interface and its merits:

• things you do has flows
  • Example of the hub flow model
    • Collections endpoint (is CRUD with semantic) 
      • Objects embedded: Gs1.com, products
    • It has things like storage for states
    • The interfaces are setup to be able to talk to common components
  • for actions [inherited], the way that tasking works...
    • Image a numeric map, unique
    • [C: This is Threads]
  • states can keep accruing; the addition of new state objects
    • In the application it shows as a chunk of data
    • An object string that evolves over time
  • the schema is model-less; it is inherited
  • Offer: bid/ask
  • C: [the hub is not only thing involved in the flow] 
  • [The interacting agent is in on the task]
  • The task is only relevant to the aspect of relationship between two agents
  • The hub doesn’t necessarily hold the actions of all agents; but, it can when the task depends on it.

Use case

• Buyer/seller interactions tasks are only involved in the actions from each perspective (not unified)
• Bidder/Auction interaction tasks are collected as a whole; all actions across all agents are consolidated

What we’re trying to do is charted (not centralized, decentralized, or distributed) state-management between parties; when there is a central server (hub) involved, each party holds the transactions between the parties.

State is what you want state to be.

Two agents are developed independently; the agents what to have they’re attributes and states.

But, there are generics that pertain to all parties; everything is an action (schema.org/actions)

What common properties must every interaction have?  schema.org/actions

Attributes (required in bold)

• Status
• Agent (driver of the action: john wrote a book)
• End time
• Error
• Instrument
• Location
• Object (of the action: john’s book)
• Participant (co-agent or co-author or role)
• Result
• Start time
• Target (for an action)

Whoa!  This hasn’t been built yet.

Not everything being done is a “task”

Are the objects being passed around? Only if the action is relevant to the interaction between the two parties Invite->RSVP... don’t pass the invite back if RSVP is being conveyed.

C: [schema.org/actions] attributes doesn’t apply; if you use schema/actions you have to use it is documented in schema/actions

[Trying to find a way for business actions to operate]

Message family

@type trustping/1.0/ping

@id ~

@type trustping/1.0/ping_response

@id

~thread { ... }

Actions

Alice’s Phone app

POST to HUB

@type Action

payload: { action object for ping }

HUB inserts it into an array

Bob’s phone app

GET from HUB

@type 

The model for protocols interjects agent-to-agent comm to storage ...

You can never operate outside the paradigm

• Hubs are intended to replace wire messages with routing
• Something is posted to the hub and synchronized around to the intended destination
• The Hub is nothing but a data store that agents interact

The wire protocol would allow the Hub to arbitrarily act on an action

The action is intended to have a dumb HUB which takes no action on a message

*********************** ************************* *************************

2. Notes & Photos received from Sam Curren:

We discussed the approaches that DIF Hubs use for Protocols called the Action Interface. We compared that to IIW Protocols as message families.

Outcomes:

We will further compare the approaches using existing examples from the Indy community in more detail to draw out important elements of each approach.

That work will happen in DIF Storage and Compute WG calls and in Hyperledger Aires Community calls (if necessary for openness).