potential RFC, not ready to merge: 0547 Invite Action Protocol #550
Conversation
Signed-off-by: Daniel Hardman <daniel.hardman@gmail.com>
|
|
||
| The official name of the protocol is "Invite Action"; its official version is 0.9. This is reflected in its [PIURI](../../concepts/0003-protocols/README.md#piuri): | ||
|
|
||
| >`https://didcomm.org/invite-action/0.9` |
There was a problem hiding this comment.
Just a question: why 0.9 and not 1.0 like every other protocol?
There was a problem hiding this comment.
I'll update to 1.0 after it's socialized with the community a little bit. There are a couple parts of this protocol that I don't feel confident about yet.
|
|
||
| The `invitee` state machine looks like this: | ||
|
|
||
| [](invitee_states.puml) |
There was a problem hiding this comment.
It would be useful to show in this state machine how a DIDComm protocol would be spawned off as a co-protocol (RFC0482)
There was a problem hiding this comment.
I added a paragraph after the state machine of the invitee, explaining how this protocol would relate to a coprotocol or ordinary protocol invocation. I did not update the diagram itself. Please have a look and tell me what you think.
There was a problem hiding this comment.
Unlike Co-protocol Protocol, the Invite Action does not support ongoing yielding of intermediate outputs
I assumed the result(s) of the activity being invited to perform would depend solely on the goal code's semantics. There can exist a goal code involving streamed data or pushed data; this verbiage would restrict use solely to the provisioning of a streaming endpoint or a self-asserted credential that the invitee will push results on the clock every hour, respectively. I'm not sure we should preemptively limit our flexibility this way.
There was a problem hiding this comment.
If Alice sends a goal code to Bob who is stranded on the side of the road with a flat tire, her goal might be to get him up and running... but Bob may also send an invite-action back asking for progress reports.
There was a problem hiding this comment.
Bob may also send an invite-action back asking for progress reports.
This is really interesting to me. It suggests that maybe we should have a progress reporting protocol. Right now, as written, I'm using advanced ACKs to address that need. Maybe that's suboptimal. Not sure. If we make progress reporting a protocol, then we also have to adjust the arity of invited actions, so that you invite agent X to take an action and also invite it to engage in a progress reporting protocol as the action unfolds. That starts to stray into the coprotocol protocol... But it's interesting to ponder.
| - Why is this design the best in the space of possible designs? | ||
| - What other designs have been considered and what is the rationale for not | ||
| choosing them? | ||
| - What is the impact of not doing this? |
There was a problem hiding this comment.
Have you looked at "Action Menu"? I believe both this and Action Menu are trying to solve the exact same problem, but Action Menu does it in a more general way, allowing the user to see a menu of things they can do vs. just one, and allowing the invitee to include data as part of the request to act. Action Menu also allows the invitee to say "Hey, send me your menu so I can see what services you offer".
I think at least it should be included in the list of alternatives.
There was a problem hiding this comment.
Yes, I have. As a matter of fact, I re-read its RFC before I started on this. I didn't see it as an exact equivalent, because it goes the opposite direction (agent willing to act proactively publishes a menu, instead of passively receiving an invitation). But I agree that it should be included in the list of alternatives.
There was a problem hiding this comment.
Sounds like we didn't explain it well. Action Menu was very much was intended to be either side starting the conversation, the "service-provider" offering a menu of options (could be just one as is the case here), and the "service-user" requesting the menu if necessary and on receipt, selecting what to use in moving forward.
We definitely need to get goal-code in into Action Menu, but I would be really interested in trying to merge these and make sure that we are covering the necessary cases. I think there is too much in common with these approaches.
There was a problem hiding this comment.
I've added a section to the comparison table talking about Action Menu. I identified the things that we might have to resolve to collapse the two.
There was a problem hiding this comment.
These are the aspects of Action Menu that stand out to me:
- allows one Agent to present a set of heirarchical menus and actions to another user-facing Agent in a human friendly way
- requires an active DIDComm connection before it can proceed.
- the responder presents a list of actions which can be initiated by the requester. Actions are contained within a menu structure.
- can be initiated by either the requester asking for the root menu or the responder sending an unsolicited root menu.
It sounds a lot like RFC0031 "Discover Features Protocol" but a little bit more oriented towards enabling a human-friendly display of the actions. It also sounds a lot like a "service provider".
It makes sense for Action Menu to require a DIDComm connection between agents because, just like in RFC0031, an agent may wish to limit service exposure to un-trusted parties. An agent could theoretically send some sort of out-of-band menu request with a goal code and receive a tailored action menu in response. The agent would then need to take their pick.
It was hard for me to grok this inversion because normally human beings and software with logic just ask one another what to do with the expectation that the other party knows what they must do. The expectation is usually derived from the requester's context. If the requester now has to query a navigable menu received in response to the original request and then point the responder to the exact thing they'd like to be performed then that is adding a bit of overhead to the exchange.
Coming back to Daniel's auction example: Alice is auctioning a Rembrandt and would like to invite Bob to bid for it. She needs to send a message to Bob telling him the action, the subject, and the location. Bob either understands the message or he doesn't. He could reply with an Action Menu if he doesn't, but now Alice needs to understand Bob's action menu.
And I just realized something: the RFC proposed in this PR includes action (goal code) but does not include subject nor location. We're missing something here...
There was a problem hiding this comment.
A couple of thoughts on @llorllale comments:
-
Action Menu and Discover Features are not the same as Discover Features returns a list of protocols supported, while Action Menu is a list "business things you can do at this time". It's intended to be at a much higher layer. The fact that an agent supports "Issue credential" tells me nothing about what credentials are offered in the current context.
-
Action menus are not hierarchical, although a hierarchy can be constructed via a sequence of interactions. The telephone IVR system is the target -- at any point, the user gets a menu of things that they can do, including some that lead to other menus, others that lead to talking to a person for a specific reason, others that just send you to the operator.
The use of Action Menu will be needed when an Agent can be used to execute an entire business transaction vs. the current model we are seeing where the transaction is happening in a browser, and the agent is being used to provide a proof or receive a credential as a side-effect of the transaction. If you could use your agent to contact your bank and execute one of a set of transactions (check balance, transfer funds, open bank, get proof of balance), then the richer features of Action Menu become necessary.
Coming back to Daniel's auction, Alice could be auctioning a Rembrandt and present a menu of actions that Bob can take -- request proof of authenticity, see picture of painting, make a bid, request bid history, exit the bidding. And since, Alice is running an Auction house, Bob may start at a top menu allowing searching current auctions, see the painting of the day, pay invoice, talk to Alice.
There was a problem hiding this comment.
That all sounds good. The Action Menu RFC should be updated to enable all these use cases.
There was a problem hiding this comment.
I have begun a PR that would remove this RFC and update the Action Menu RFC. I'll try to finish that up.
Signed-off-by: Daniel Hardman <daniel.hardman@gmail.com>
Signed-off-by: Daniel Hardman <daniel.hardman@gmail.com>
| mechanism | what's alike, what's different | ||
| ----------|----------------- | ||
| Basic Message Protocol | Lets humans invite one another to take arbitrary actions, but requires human intelligence for decision-making. Arbitrary attachments — available in all DIDComm contexts — can carry machine-actionable payloads, but the history of email demonstrates that it's unsafe to trigger machine actions based on attachments without predefined semantics. Also, the mime type of an attachment does not necessarily indicate which action is desired (is an attached PDF supposed to be saved, printed, displayed to the user...). And there's no useful way to separate messages intended for human interpretation from messages that automation should handle. | ||
| Out of Band Protocol (RFC 434) | Like Invite Action, OOB lets the sender propose to the receiver that the receiver take an action — and automation can be built on the receiving side, because the action is described with a formal goal code. However, OOB is for situations where no channel is known to exist between two parties, and it always involves transmitting a message over a non-DIDComm channel. OOB assumes that either a handshake protocol or `~request-attach` is relevant; it doesn't allow a goal code to be sent in isolation. Only Invite Action supports actions that are not protocols in the DIDComm sense. |
There was a problem hiding this comment.
OOB [...] always involves transmitting a message over a non-DIDComm channel
note: OOB messages can be forwarded through DIDComm channels with the introduce protocol (aries-framework-go already does this).
dhh1128
changed the title
|
Discussed on B call, Oct 14. Outcome: we're not sure how we want to harmonize this with the Action Menu Protocol and the Please Play Role Protocol. We're going to let it simmer for a while. |
|
I’d like to close this PR as lacking sufficient interest in the community. |
Signed-off-by: Daniel Hardman daniel.hardman@gmail.com