Open davidiw opened 3 years ago
I don't understand what makes embedding a result field in a response "synchronous", could you explain?
One doesn't have to do a subsequent JSON-RPC query to get a result that's more informative than just status: success
. In this case, the desired information is the recipient_address
normally in a ReferenceIDCommand
. By having it in a result
field, it saves a second round trip, simplifying and reducing latency for a P2M flow.
Put another way, one can issue a command and get the response in a single JSON-RPC command as opposed to two: doAction, getRecipientAddress.
Thanks for the explanation @dimroc . This makes total sense, but the terminology "asynchronous/synchronous" don't apply here. I would remove them, and just leave the explanation that a response field can include information that may prevent the need for another message exchange.
Hi @dahliamalkhi i've incorporated your feedback into the PR for this dip https://github.com/diem/dip/pull/165 if you can take a look that'd be great!
dip: 161 title: Off-Chain Protocol: Optional Result Field author: Xiao Li (@xli), SunMi Lee (@sunmilee), David Wolinsky (@davidiw) type: Informational discussion-to: https://github.com/diem/dip/issues/161 created: 2021-04-07 updated: 2021-04-07
Overview
Both the Off-Chain Protocol and Travel Rule Exchange (or PaymentCommand) are defined in DIP-1. The Off-Chain Protocol was defined in such a way as to support the minimal requirements for these exchanges, specifically, in this case, asynchronous responses to requests. Many types of communication benefit from synchronous responses as it provides for both protocol simplicity and reduced latency. In order to support synchronous commands, the
CommandResponseObject
can leverage an optional field:result
. Theresult
field, if defined, must contain__ObjectType
that should uniquely define the shape or other fields within theresult
.Here's an example from DIP-10: