propose HIPE: ACKs

[dhh1128]

Signed-off-by: Daniel Hardman [email protected]

Explains how one party can request, and another party can send, acknowledgment
messages (ACKs) to confirm receipt and clarify the status of complex processes.

[swcurran]

Typo - "2 hours" should be "6 hours"

[swcurran]

My challenge with this proposed HIPE is how this kind of cross-cutting message type will be used. This feels like an optimization/refactoring of code that has not yet been written. It might be a good idea, but until we have working code and experience using that code, we don't really know.

I can't see many developers embracing ACKs when building the first few message families vs. putting in explicit ACK message types within a Family where they make sense. I think those first message families will try to be inclusive - encapsulating all of the context of the goal interaction (e.g. issue/receive Credential, proof request/proof, etc.). If so, an independent ACK will be a challenge (non-intuitive) to integrate, since it is handled by a different message family but needs access to the context of the instance of the goal interaction message family to form a reply. My guess is that in order to really support generalized ACKs, each message family will have to expose an "ACK" handling method. Since that means each message family has to implement ACK handling - why not just let ACK be an explicit part of message families? It's less abstract to build and maintain - all the message types and context are in the same message family spec.

But that's where the potential refactoring comes in. Maybe it will be easier/better to have an independent ACK message type and to structure the message families to be callable for handling the "interaction specific" logic of the ACK without duplicating the rest of the ACK handling code. For example, each message family must define what "Outcome" means in the context of a specific transaction (obviously a single global ACK handler can't) and so the message family could expose "Outcome" details, and the ACK message type could handle the rest of the interaction.

A separate aside: It seems to me that this proposal does lead us to a conversation about how an Agent message handler should be constructed. Given we have message families, threads, state and cross-cutting message types (Ack, Problem Report) - what is the best way to structure an agent?

[TelegramSam]

Two things:

1. I think the utility of a 'message received ack' is very useful. This can be processed in a message pre-processor to make this consistent across all received messages. Using a decorator to request this type of ack is I think a good idea.

2. The rest of this HIPE deals with much more complicated situations, including requesting an ack for a previously sent message and ack of internal protocol state. I think we are far too young as an ecosystem to be discussing this level of standardization between message families. I recommend that this deeper discussion be tabled until we have developed examples of such complex needs.

[dhh1128]

@swcurran and @TelegramSam : I have moved the fancy stuff about acks for messages other than the current one, and about outcomes and so forth, into an "experimental" section to make clear that it is not a required part of the 1.0 protocol. I also added a note about how to adopt acks into other message families. I hope this resolves the concern about routing that Stephen noted above, and about premature standardization.

[TelegramSam]

There are two open TODO sections on this HIPE, but I believe both can be removed and saved for a future update with more advanced use cases. With those removed, I believe this is a candidate for FCP.

[dhh1128]

There are two open TODO sections on this HIPE, but I believe both can be removed and saved for a future update with more advanced use cases. With those removed, I believe this is a candidate for FCP.

@TelegramSam Which are the two open TODO items? My previous comment ("I have moved the fancy stuff") addressed what I thought were the TODOs, so I am wondering if I missed something.

[dhh1128]

This has been superseded by Aries RFC 0015. See https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0015-acks/README.md.