Skip to content

Instantly share code, notes, and snippets.

@emschwartz
Last active December 1, 2017 18:57
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
Star You must be signed in to star a gist
Save emschwartz/1acbdf811d143866318c44d05aec5a95 to your computer and use it in GitHub Desktop.
Merging lesson from ILP 2/3 back into ILPv1

Lessons

  1. Focus on small payments and have connector limit bandwidth per user
  2. Focus on payment channels for cryptocurrencies instead of escrow or trustlines
  3. We need a production-ready open source connector ASAP

Steps to a real-money-ready connector

Must-Haves

  • Add fulfillment data
  • Have connector forward amount-less payments
  • Decide whether to focus on ilp-kit, ilp-connector, ilp-connector-shard, amundsen, or ilp3
  • Make sure all plugins support binary rejection messages (for example, ilp-plugin-bells still expects JSON)
  • Implement payment channel limits and bandwidth auto-adjuster
  • Support multiple XRP payment channels (either within one "server" plugin or with multiple plugins)
  • Make bidirectional channels optional and make the receiver pay for the connector opening one to them
  • BTC and/or ETH payment channel support
  • Start sending payments through a connector without a UI-based signup (just open payment channel and go)
  • Backup payment channel claim submitter that runs in a separate process and submits claims in case connector crashes
  • Don't persist prepared transfers and assume single process per account
  • Document ILP address prefix scheme for cryptocurrency payment channels
  • Fix routing (either use manual configuration or make sure payments cannot be blackholed)
  • Simple documentation for running a connector with payment channels and/or trustlines

Nice-to-Haves

  • Use levelup-compatible db instead of plugin store or payment channel backend
  • Replace liquidity curves with simple exchange rates
  • Remove ILQP
  • Remove BTP messaging
  • Change LPI to make fulfillment a response and deprecate unnecessary methods
  • Use more composable architecture (something in between plugin and middleware approaches)

Chunked payments

  • Port chunked payment version of PSK from ILPv3
  • Test chunked payments over ILPv1
  • Decide on and document PSK 2.0 specification
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment