Skip to content

Future of cloud-based auto-providers #1302

Closed
@pipermerriam

Description

@pipermerriam

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.

  1. Use something like setuptools entry_points to allow 3rd party providers to hook into the web3 namespace so that a user would install web3-infura and in doing so, be able to import the web3 providers from web3.auto.infura.*
  2. Just relegate all of the cloud ones to 3rd party packages.

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 own web3-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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions