Skip to content
Evan Schwartz edited this page Feb 9, 2017 · 3 revisions

Ideas for improving Interledger and ILP-Kit

Bitcoin (Lightning) or Ethereum Integration

Enable Interledger (micro)payments over one of the major cryptocurrencies. This mainly entails figuring out how to support the Interledger Ledger Plugin functionality using the new ledger.

Build Micropayments Into an App or Protocol

Imagine the Web without ads, Torrents where seeders compete to upload files to you as fast as possible, or the Internet without DDoS attacks. Interledger micropayments can be used to enable each of these visions.

Implement an ILP Client in a New Programming Language

The main ILP client is in Javascript now and we've got a Java one in the works. Are you a Go, Python, C, or Elixir guru? Let's enable sending and receiving ILP payments in as many programming languages as possible!

Social Media Integration

When users run an ILP-Kit node the first thing they need to do is find other people they trust that are also running nodes so they can peer with them.

If they could link a social media profile and let ILP-Kit access their list of connections then we could co-ordinate a "match-making service" of ILP-Kit administrators through their existing social-media connections.

New Settlement Options

ILP-Kit allows two peers to pick a settlement mechanism that they both agree on (cash, bank transfer, etc). The more settlement options we have available the easier it is for two nodes to peer.

Easy deployment

Many potential ILP-kit users are not technical but have available liquidity that they can add to the network. We need to make it really easy for them to deploy and configure a node.

Possible solutions are "packaged applications" that are available on many cloud hosting platforms. Ideally the user experience for deploying ILP-kit would be to run through the deployment flow defined on the hosting platform following which a fully-functional ILP-kit is up and running at a URL of the deployer's choosing.

Monitoring

ILP-Kit currently outputs a number of logs which are useful for technical debugging but it would also be valuable to produce instrumentation data that can be used to monitor things like liquidity, performance, reach etc.

It would also be useful to have a mechanism to aggregate (and anonymize) this data and submit it to a central monitoring service that can monitor the health of the entire network.