search

interledger / rfcs

Specifications for Interledger and related protocols
https://interledger.org
Other
455 stars 111 forks source link

LPI v3 #396

Closed michielbdejong closed 6 years ago

michielbdejong commented 6 years ago

We now have client plugins and server multi-plugins, and I was about to even create a few additional ones:

And then there is also https://github.com/ripple/ilp-plugin-xrp-paychan which is a third xrp-paychan-related "ledger plugin"! :)

Having two plugins (one client and one server), or even three, for each underlying ledger is a downside of LPIv2. Another downside is that server plugins are not really supported by LPIv2; for sendData they have to do deep packet inspection, connect/isConnected is used for listen/isListening, unrelated to whether or not anybody is connected, and sendMoney is even ignored altogether, leading to unintuitive problems like https://github.com/interledgerjs/ilp-connector/issues/413.

Also, since ledger plugins not only deal with ledger stuff but also with BTP stuff, there is a lot of shared code between plugins.

And there are now a lot of BTP side protocols that are not really documented because each plugin can reinvent the wheel for opening, updating, and closing channels.

Therefore, I think we need to move the BTP server/client functionality into the connector, and create LPIv3, which will be just ledger-specific functionality like dealing with api keys, cryptocurrency accounts, payment channels, and things that are really different between e.g. XRP and Stripe. Also, you would only need one of those, and not two or three.

emschwartz commented 6 years ago

I agree that having the client and server plugins is a bit strange and leads to some duplicate code. However, unless this is causing substantive problems right now, I would prioritize getting working integrations for the different ledgers we want to connect over doing another internal refactor. It would be fine for us to build the integrations using LPIv2, figure out the over-the-wire protocols for each one, and then refactor the internal code to use a different module structure while maintaining compatibility with the V2 plugins.

for sendData they have to do deep packet inspection

It's dirty but I think it's fine for now

there is a lot of shared code between plugins.

Isn't that handled by all of them extending the same base classes?

And there are now a lot of BTP side protocols that are not really documented because each plugin can reinvent the wheel for opening, updating, and closing channels.

Actually I think this is fine. All of the integrations for different ledgers can define the ledger-specific operations however they want. The main reason to document (and version) them is so that multiple implementations can stay compatible with one another. But it doesn't matter that much how much similarity there is between different integrations.

michielbdejong commented 6 years ago

I would prioritize getting working integrations for the different ledgers

This work would be part of that.

sharafian commented 6 years ago

The asym-server, asym-client, and symmetric cases all represent different trust models so I think it makes sense that they would be different modules. We have shared code between them in ilp-plugin-xrp-paychan-shared, so I think if we want to do refactoring to make them simpler then that's where the shared code should go.

stale[bot] commented 6 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. \n\n If this issue is important, please feel free to bring it up on the next Interledger Community Group Call or in the Gitter chat.