Off-Chain Protocol: Optional Result Field

[davidiw]

---

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]

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

[dimroc]

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]

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]

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