Generated wrappers for contract partners or plugin system for contractkit

[yorhodes]

Expected Behavior

Ability to integrate easily with contract projects on top of Celo

Current Behavior

Contract developers must redo work in ContractKit/kliento

[nambrot]

@aslawson @yorhodes This IMO feels pretty useful for me

[yorhodes]

devx was discussing the plugin system for the CLI and concerns of security in 3rd party plugins came up maybe we should add a dependency on having a cLabs cap signature scheme

[nambrot]

Doesn't that seem different though? This wouldn't be to include 3rd party code in contractkit, but to allow developers to have the same interface?

[aslawson]

but to allow developers to have the same interface

^ @nambrot what do you mean by this? as in developers can plugin for their personal use case vs provide 3rd party extensions to others?

[nambrot]

Take the example of Moola Market. If a developer wanted to make contract calls to Moola Market, they would have to:

1. fetch the ABIs from somewhere
2. construct the lower-level web3.js contract
3. have no type guarantees 4.1. either submit the tx themselves with the promievent abstraction and estimate gas and all the celo fields themselves 4.2. Or know how to use the toTransactionObject helper we have in contractKit

Instead, we could allow moola to use much of the tooling we've built in contractkit so that something like a MoolaMarketWrapper can be offered in an NPM package that has the same ergonomics as the wrappers for the Celo Core Contracts.

[aslawson]

Sure -- so then I'm unclear how its different from what we are exploring with CLI then. Our wrapper structure allows a lot of room for 3rd party code.

[nambrot]

The CLI is a different layer of abstraction IMO. I.e. the contract wrapper layer would be for developers, while the CLI would be for end-users. I.e. the moola market CLI would benefit from the global flags that are existing in the celocli (i.e. for key management, node management)

[aslawson]

True -- though in allowing plugins we still open it up for third integrations (even if the intent is just to let devs extend the functionality for themselves)

A third party like moola could offer the plugin for download and another developer could integrate it and would need to trust it to do what it claims to do. So if we go the plugin route, I would think similar considerations would apply (ample warnings against using third party plugins in the docs and command line when running plugin installs). but we likely don't need the extra considerations to safely support third party plugins like signatures/whitelists unless there appears to be a demand for that.

[nambrot]

Agreed, but it's still a different concern for this ticket right? I.e. your point very much applies to #6738

I.e. as a developer integrating moola, they wouldn't go down the CLI route, would they?

[github-actions[bot]]

This issue is stale and will be closed in 30 days without activity