JSPM

  • Created
  • Published
  • Downloads 474
  • Score
    100M100P100Q100256F
  • License Apache-2.0

Package Exports

  • ilp-protocol-stream

This package does not declare an exports field, so the exports above have been automatically detected and optimized by JSPM instead. If any package subpath is missing, it is recommended to post an issue to the original package (ilp-protocol-stream) to support the "exports" field. If that is not possible, create a JSPM override to customize the exports field for this package.

Readme

ILP STREAMing Transport for Real-time Exchange of Assets and Messaging (ILP/STREAM)

Interledger transport protocol for multiplexing streams of money and data over a virtual ILP connection.

ILP/STREAM is a successor to PSK2 that handles sending multiple streams of money and data over a single ILP "connection" between a client and server. It automatically handles flow control, backpressure, exchange rates, multiple classes of errors, data encryption and authentication, and condition and fulfillment generation.

This protocol combines the lessons learned from PSK with significant inspiration from the QUIC internet transport protocol.

Getting Started

npm install --save https://github.com/interledgerjs/ilp-protocol-stream

See example.js or the TSDoc for the usage.

TODOs

  • Quoting
  • Minimum destination amount and amount arrived
  • Track exchange rate and apply slippage
  • Prevent replay attacks and ensure response is correctly on fulfill or reject
  • Determine Max Packet Amount
  • Events to know when money has been fully sent
  • Retry temporary errors
  • Combine always needed frames into one (and make it appear first?)
  • Length-prefix frames for extensibility?
  • Backpressure
  • Helper functions for sending / receiving and waiting until it's finished
  • Handle stream closing
  • Protocol error frame
  • Padding frame
  • Data stream
  • Should money and data streams use different sets of numbers for stream ids?
  • Multiple packets in flight at the same time
  • Backpressure for data streams
  • Connection closing
  • Don't send extra packet at the end if it isn't necessary
  • Max number of streams
  • Blocked frames (when more is available to send)
  • Refactor handleData and sendPacket functions to make them easier to understand and reason about

Credits

Thanks to @sharafian for coming up with the acronym for STREAM.