STREAM RFC: codify the conditions for a ConnectionAssetDetails frame being returned from a receiver.
theotherian opened this issue · comments
Information that inspired this issue:
- interledgerjs/ilp-protocol-stream#69
- Discussion on interledger/interledger-rs#273
- Discussion on hyperledger-archives/quilt#261
Proposal:
STREAM RFC (il-rfc29) should codify the conditions for a ConnectionAssetDetails
frame being returned from a receiver.
Question: What is the correct way to indicate a new Connection for a receiver?
Option1: Treat sequence of 1 as a new connection.
Option2: Whenever a ConnectionNewAddressFrame and a SendMoneyFrame are encountered.
Option3: Leave the RFC as is, which suggests only stateful receivers (see next question).
Question: should there be stateless receivers, or is this a protocol violation?
Question: What should a receiver reply with on a new connection?
Stateless:
- When receiver receives a
ConnectionNewAddress
and aStreamMoneyFrame
frame from a sender, it should reply with aConnectionAssetDetails
frame.
Stateful:
- When receiver receives its first
StreamMoneyFrame
for a given connection, it should reply with aConnectionAssetDetails
frame.
After discussing with @theotherian and @nhartner, we think the following are the correct path forward (also represented by PR #551):
Question: What is the correct way to indicate a new Connection for a receiver?
We want the RFC to be able to support stateless receivers and bi-directional streams (not at the same time, but in general -- and maybe only in the future). To this end, we shouldn't specify returning ConnectionAssetDetails
on the first stream packet sequence number, because this may not be the point in time that one side or the other requires this information.
Instead, we should maintain the current Javascript Connector functionality (which is also what the Java Stream receiver does) and simply mandate that any endpoint receiving ConnectionNewAddress
should respond with ConnectionAssetDetails
. See the RFC PR (#551) for exact semantics here.
Question: should there be stateless receivers.
Yes, there are already stateless receivers in the wild that work just fine, so the RFC should not preclude them.
Question: What should a receiver reply with on a new connection?
See #551.
@sappenin and @kincaidoneil interledgerjs/ilp-protocol-stream#112 was never resolved, does it have any bearing on this?
was never resolved, does it have any bearing on this?
Not really, I think it just underscores that it's important for the sender and recipient to exchange asset details, so we should support that for stateless receivers. AFAIK, David's PR should be fully compatible with the existing JS Stream implementation.