Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Off-Chain Protocol: Optional Result Field #161

Open
davidiw opened this issue Apr 7, 2021 · 4 comments
Open

Off-Chain Protocol: Optional Result Field #161

davidiw opened this issue Apr 7, 2021 · 4 comments
Assignees

Comments

@davidiw
Copy link
Contributor

davidiw commented Apr 7, 2021


dip: 161
title: Off-Chain Protocol: Optional Result Field
author: Xiao Li (@xli), SunMi Lee (@sunmilee), David Wolinsky (@davidiw)
type: Informational
discussion-to: #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
Copy link
Contributor

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

@dimroc
Copy link
Contributor

dimroc commented Apr 12, 2021

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
Copy link
Contributor

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
Copy link
Contributor

Hi @dahliamalkhi i've incorporated your feedback into the PR for this dip #165 if you can take a look that'd be great!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants