BTP/2.0 #383
BTP/2.0 #383
Conversation
| | 3 | `Prepare` | Request | | ||
| | 4 | `Fulfill` | Request | | ||
| | 5 | `Reject` | Request | | ||
| | 3 | (deprecated) | | |
There was a problem hiding this comment.
To me "deprecated" means "may be removed in the future". If you don't describe those messages at all anymore I would assume that new implementations don't support them at all, so something like "(removed)" or "(outdated)" may be better.
| their balance. If Peer 1 owes Peer 2 100 XRP, Peer 1 could send Peer 2 100 | ||
| XRP on Ripple in order to make their balance 0. In that scenario, XRP ledger is | ||
| the underlying ledger. | ||
| has been sent yet. |
There was a problem hiding this comment.
Should this be "no response has been received yet."?
| who is running your plugin. | ||
| When two Interledger connectors use [OER in HTTP POST bodies](...) as the communication channel between | ||
| them, they each need to act as a HTTP server at times. If one of the connectors runs behind a firewall, | ||
| this may be impossible. Therefore, we foresee in the option of using WebSockets instead of HTTP. With |
There was a problem hiding this comment.
ah sorry, Dutchism "voorzien in" :)
|
|
||
| Data to secure this payment (such as payment channel claims), can be attached | ||
| under the protocol data. | ||
| `Transfer` is used to send payment channel claims to the other connector. |
There was a problem hiding this comment.
True, but I wonder if this is too specific. Could Transfers be used to send - for instance - a PayPal payment ID as well to trigger processing of some other form of outside settlement?
| These allow you to send interledger payments through anyone else on that ledger | ||
| who is running your plugin. | ||
| When two Interledger connectors send ILPv4 packets over HTTP POST, | ||
| they each need to act as a HTTP server at times. If one of the connectors runs behind a firewall, |
There was a problem hiding this comment.
"as an HTTP server"
| @@ -232,7 +209,7 @@ For example, the primary sub-protocol entry of a Message might represent a quote | |||
|
|
|||
| Likewise, only the primary sub-protocol data in a Response indicates whether result of the request from the Message being responded to actually succeeded or not. | |||
|
|
|||
| In Error, Prepare, Fulfill, and Reject calls, the distinction between primary and secondary sub-protocol entries is less strict. | |||
| In Error calls, the distinction between primary and secondary sub-protocol entries is less strict. | |||
|
|
|||
| ## Flow | |||
|
|
|||
There was a problem hiding this comment.
"The request types are Message, Prepare, Fulfill and Reject" should be "The
request types are Message and Transfer"
| @@ -282,140 +259,6 @@ protocol data. | |||
| not include ILP errors such as "No quote found", only the cases in which the | |||
There was a problem hiding this comment.
"ILQP packets" should be "ILP packets"
| `Transfer` is used to send proof of payment, payment channel claims, or other | ||
| settlement information to the other connector. | ||
| The amount should indicate the relative value of this settlement state (compared to the | ||
| previous settlement state), in a unit that was agreed out-of-band. |
There was a problem hiding this comment.
Relative means this can be negative.
Is this description correct?
I thought this was used to carry a sendMoney which means the amount is always positive and the message is only sent by the connector that is making the transfer.
There was a problem hiding this comment.
Good point! I changed "relative" to "additional"
michielbdejong
dismissed
adrianhopebailie’s stale review
all comments address, thanks a lot!
This PR continues the work started in #360, removing the deprecated parts from BTP, and removing some talk about ledgers which no longer applies now that we talk about sending "data" rather than conditional transfers.