-
Notifications
You must be signed in to change notification settings - Fork 1.8k
Future of cloud-based auto-providers #1302
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Found my way here after a PR was opened to add documentation for another remote node provider here: #1692. I like the idea of deprecating native Infura-specific APIs in favor of a more even playing field. Would be lovely to handle all providers via generic env vars, e.g., |
I think it is reasonable to define a URI scheme for providers that would allow something like I'm still in favor of splitting off and releasing a |
Closing since the decision has been made to move to 3rd party packages. Newer issue here: #1736. |
Uh oh!
There was an error while loading. Please reload this page.
What was wrong?
The maintenance overhead of this API is not something I'd like the core development team to end up spending their time on, but there is value in having a way for users to quickly connect to a reliable cloud based provider.
How can it be fixed?
I see two main options.
web3
namespace so that a user would installweb3-infura
and in doing so, be able to import the web3 providers fromweb3.auto.infura.*
Downsides I see with the entry points based approach is that it makes the imports look like they come from the main web3 library when actually you're importing 3rd party code. This has the potential to mask bad actors, or worse, have malicious code insert itself masquerading as "infura" but actually doing something malicious. This is a major downside.
Because of this I'm inclined to go with option two and to deprecate our existing
web3.auto.infura
imports and move them into our ownweb3-infura
package that we maintain. We could even go as far as providing a template for these repos to make it easier for people like nodesmith to manage their own packages.Last, we could have a curated list of these packages listed in the docs to make them more discoverable.
The text was updated successfully, but these errors were encountered: