propose HIPE: ~please_duplex to ask for 2-way sync comms

[dhh1128]

Signed-off-by: Daniel Hardman daniel.hardman@gmail.com

[swcurran]

Not sure this should be a review or just a series of comments, but there you go.

[swcurran]

I'm not sure I agree that this characterization of "Bob as an institution" is likely. Possible, certainly, but for a number of reasons I can see an enterprise domain containing many agents. We might encourage enterprises to use an Agency to increase the "lost in a crowd" affect - especially early on. They might route messages to queues for Human or backend responses. Until we get some more experience, it's guesswork.

[swcurran]

I'm not sure a general purpose decorator should rely on a dynamic routing config that appears to be point to point. I think that's the rare case, and I believe we have in another HIPE a recommendation that a "single-agent" domain should present itself externally to be a multi-agent configuration to reduce the information it exposes about itself.

The only case where I think this will be common is in the face-to-face bluetooth scenario.

[dhh1128]

@swcurran What about the case of intra-domain A2A?

[swcurran]

This seems complex to develop - having to support both sync and async messages over a multi-agent route. A pure routing agent (e.g domain endpoint or an agent in the "routing agent" role), this seem difficult.

[dhh1128]

Yes, I agree that this is a disadvantage. In my mind, it's the primary disadvantage and might, in and of itself, be enough to sink the HIPE.

[swcurran]

This HIPE in general doesn't feel good to me.

I can't imagine the UX in this. Why and how would an agent (or it's human overlord) decide to switch to sync?

Note that the primary Sender-to-Recipient direct connection case - bluetooth - doesn't really need sync messaging, since in most cases, the two participants are generally facing each other and can tell each other what they are seeing on their end.

This might prove needed in the future, but I think we need some experience to tell if it would be worth the complexity. Further, it might be that if we put effort into better production tracing rather than in sync messages we might achieve better results with less complexity.

[dhh1128]

@swcurran : There is currently no legal way to implement a connection over http or websockets (and maybe over bluetooth?), without two webservers, unless we invent a mechanism like this. If Bob opens an incoming port to Alice over http and sends a message to her, he must express to her in his DID doc a way to contact him in the reverse direction. It is illegal (or at least ignored) for her to just return a response in the http response body. But Bob doesn't know how Alice perceives this incoming channel. From his perspective, it is port 80. But from hers, it is port 23847. He doesn't know that and so can't tell her to contact him back at port 23847. This means both parties must be running a web server in order to connect. That is the constraint we are accepting if we don't invent a mechanism like this.

All the complexity you're worried about is true if mediators are involved--but is trivial if there are no mediators, as in the cases I'm highlighting.

[TelegramSam]

I am very convinced of the need for this behavior for institutional agents, and the argument that institutional agents are often squashed onto a single box.

The best use case for this behavior is institutions that want to allow 'api style' access to their agents via static agents. This helps with internal integration with existing systems, and could also allow outside developers access via the same mechanism.

I'm not convinced that we need this feature for any transport other than HTTP.

Given the narrow need for this using HTTP in static agent cases, I wonder if we should define this behavior in a document that describes the HTTP agent transport.

Also, I anticipate that this behavior will be mostly applied to specific message families that are prepared to return responses immediately. In that case, a general decorator may not be needed.

[TelegramSam]

On a new read of this, I have new thoughts. We have not discussed as a community how A2A messaging applies to various transports such as HTTP, websockets, email, or bluetooth. Each of these transports will have properties or mechanisms that should be considered.

The issues proposed here relate specifically to HTTP as a transport.

Also relevant to this topic is return message routing options for agents unable to offer an inbound route. Do they poll for responses? How do they express that desire?

[peacekeeper]

This HIPE reminds me of something we did in XDI, see this PR: dhh1128#7

[dhh1128]

@peacekeeper Thanks for the pointer! Love it. Added.

[swcurran]

Reread this and I still don't understand how this manifests into an implementation. Suppose I say I want a message to be sync rather than async. Does that mean the A2A message will be treated like a request and answered with a response ("200", "404", etc.), rather than a new message being created in response to the first?

If so, does that means only certain messages/message families could use sync, and they would need to say what a response would mean for each request. Further, as I think is noted in the HIPE, the message family would also have to define a message type with a response for when async is used.

I can't see how this would be any better than a threaded message that is the response to a request message with a suggested/required response time.

Help! :-)

[dhh1128]

This HIPE has now been superseded by @TelegramSam 's work on return routes (see Indy HIPE #116), and will shortly be superseded by yet another generation of the idea as an Aries RFC.