-
Notifications
You must be signed in to change notification settings - Fork 111
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
STREAM RFC: codify the conditions for a ConnectionAssetDetails frame being returned from a receiver. #546
Comments
ConnectionAssetDetailsFrame
.
After discussing with @theotherian and @nhartner, we think the following are the correct path forward (also represented by PR #551):
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 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
Yes, there are already stateless receivers in the wild that work just fine, so the RFC should not preclude them.
See #551. |
@sappenin and @kincaidoneil interledgerjs/ilp-protocol-stream#112 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. |
* Fixes #546 * Update STREAM RFC to clarify how `ConnectionAssetDetails` are communicated for a given STREAM Connection. * Clarify the relationship between `ConnectionAssetDetails` and `ConnectionNewAddress `. Signed-off-by: sappenin <sappenin@gmail.com> * Update 0029-stream/0029-stream.md Co-Authored-By: Kincaid O'Neil <kincaidoneil@users.noreply.github.com> * Update per PR comments. Signed-off-by: sappenin <sappenin@gmail.com> * Remove redundant clarification. Signed-off-by: sappenin <sappenin@gmail.com> * Remove wordy sentence Signed-off-by: sappenin <sappenin@gmail.com> * Remove language about ignoring subsequent frames. Signed-off-by: sappenin <sappenin@gmail.com> * Removing breaking proposed changes. Signed-off-by: sappenin <sappenin@gmail.com> * Remove whitespace Signed-off-by: sappenin <sappenin@gmail.com> * Remove inaccurate example. Signed-off-by: sappenin <sappenin@gmail.com> * Bumping draft number to test the build scripts Signed-off-by: sappenin <sappenin@gmail.com> * Reducing the draft num Signed-off-by: sappenin <sappenin@gmail.com> * Restoring correct draft number Signed-off-by: sappenin <sappenin@gmail.com> * Skip Version Check Skip Version Check Signed-off-by: sappenin <sappenin@gmail.com>
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:
ConnectionNewAddress
and aStreamMoneyFrame
frame from a sender, it should reply with aConnectionAssetDetails
frame.Stateful:
StreamMoneyFrame
for a given connection, it should reply with aConnectionAssetDetails
frame.The text was updated successfully, but these errors were encountered: