search

interledger / rfcs

Specifications for Interledger and related protocols
https://interledger.org
Other
455 stars 111 forks source link

STREAM RFC: codify the conditions for a ConnectionAssetDetails frame being returned from a receiver. #546

Closed theotherian closed 5 years ago

theotherian commented 5 years ago

Information that inspired this issue:

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:

Stateful:

sappenin commented 5 years ago

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.

adrianhopebailie commented 5 years ago

@sappenin and @kincaidoneil https://github.com/interledgerjs/ilp-protocol-stream/issues/112 was never resolved, does it have any bearing on this?

kincaidoneil commented 5 years ago

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.