- Focus on small payments and have connector limit bandwidth per user
- Focus on payment channels for cryptocurrencies instead of escrow or trustlines
- We need a production-ready open source connector ASAP
- Add fulfillment data
- Have connector forward amount-less payments
- Decide whether to focus on
ilp-kit
,ilp-connector
,ilp-connector-shard
,amundsen
, orilp3
- 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
- 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)
- Port chunked payment version of PSK from ILPv3
- Test chunked payments over ILPv1
- Decide on and document PSK 2.0 specification