Transport Return Route #116
Conversation
Signed-off-by: Sam Curren <telegramsam@gmail.com>
Signed-off-by: Sam Curren <telegramsam@gmail.com>
| ```json | ||
| { | ||
| "~transport": { | ||
| "return_route": "all" |
There was a problem hiding this comment.
What does "all" mean, and what are the other possible values of "return_route"?
There was a problem hiding this comment.
Presumably, this means that the agent receiving the decorated message should attempt to send responses back over the same channel?
There was a problem hiding this comment.
added pointer to the reference section.
text/return-route/README.md
Outdated
| } | ||
| ``` | ||
|
|
||
| Outbound messages can return the `~transport` decorator as well, with a `queued-message-count` attribute. This is useful for HTTP transports which can only receive one return message at a time. |
There was a problem hiding this comment.
We need a lot more detail here. If such a decorator is seen, how does the queued-message-count get used? Does the client call in with , and get a response that bundles the whole queue or some subset thereof?
There was a problem hiding this comment.
added additional commentary.
text/return-route/README.md
Outdated
| } | ||
| ``` | ||
|
|
||
| Outbound messages can return the `~transport` decorator as well, with a `queued-message-count` attribute. This is useful for HTTP transports which can only receive one return message at a time. |
There was a problem hiding this comment.
"queued-message-count" should be snake_case
There was a problem hiding this comment.
fixed. (this was not consistent with the rest of the doc)
| "@type": "?/1.0/noop", | ||
| "~transport": { | ||
| "return_route": "thread", | ||
| "return_route_thread": "1234567899876543" |
There was a problem hiding this comment.
I don't get what "return_route_thread" means, or why it would be different from a normal @id that establishes a thread. Is this allowing us to change the return route for a thread that already exists?
There was a problem hiding this comment.
This means that only messages with a matching thread ID would be returned. This allows the agent to only receive response messages to something they sent, and not messages of a type they might be unprepared to process at that moment.
text/return-route/README.md
Outdated
|
|
||
| - `none`: Default. No messages should be returned over this connection. | ||
| - `all`: Send all messages for this key over the connection. | ||
| - `thread`: Send all messages matching the key and thread specified in the `return_route_thread` attribute. |
There was a problem hiding this comment.
What "key" is specified in the "return_route_thread" attribute? I only see a thread id.
There was a problem hiding this comment.
I meant cryptographic. added.
|
Sam, this doc feels like a very promising one to me, and I'm glad it's in process. I think it should replace the ~please_duplex HIPE that I wrote several months ago (https://github.com/hyperledger/indy-hipe/blob/08927ab49754698de671862a2742ff486d8b2d06/text/please-duplex/README.md), because this is far simpler. However, there are several concepts from that HIPE draft that need to be discussed here. For example, what happens if someone doesn't want to honor the request for a return route? Is it illegal to use a different channel? Should an error or a warning be returned, and should it flow back on the channel over which the decorator arrived? What happens if the route is complex (flows through mediators and relays; maybe uses more than one transport) rather than simple--can we decorate forward messages with the decorator to ask intermediaries to support the routing, or is that out of scope? How can the sender of this decorator express the relative importance of the request, from their perspective? |
This question is interesting. As the |
Signed-off-by: Sam Curren <telegramsam@gmail.com>
|
@TelegramSam @dhh1128 I like this HIPE however it has some implications around how agents will handle and manage messages. The implication this HIPE has is that all agents, if they have a message to send another agent and fail to find an endpoint in which to dispatch the message (or the message fails to transmit with the provided endpoint), it then must put in a que for that agent? If that is the case I think we need to have a broader discussion about this behavior before this progresses? |
|
@TelegramSam - I think this needs more about the use case. I think I get it, but it's really fuzzy. A detailed example of how it would be used for a mobile and cloud agent to message back and forth would be a big help. |
describes how a message over a transport would signal that the connection serves as an acceptable return route. This helps client only agents, including mobile apps.