search

diem / dip

Libra Improvement Proposals
https://lip.libra.org
Apache License 2.0
40 stars 55 forks source link

Off-Chain Protocol: Optional Result Field #161

Open davidiw opened 3 years ago

davidiw commented 3 years ago

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. The result field, if defined, must contain __ObjectType that should uniquely define the shape or other fields within the result.

Here's an example from DIP-10:

{
   "_ObjectType": "CommandResponseObject",
    "status": "success",
    "result": {
        "_ObjectType": "ReferenceIDCommandResponse",
        "recipient_address": "c5ab123458df0003415689adbb47326d",
    },
    "cid": "12ce83f6-6d18-0d6e-08b6-c00fdbbf085a",
}
dahliamalkhi commented 3 years ago

I don't understand what makes embedding a result field in a response "synchronous", could you explain?

dimroc commented 3 years ago

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.

dahliamalkhi commented 3 years ago

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.

sunmilee commented 3 years ago

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!