added ipfs resolver wrapper to default config

[krisbitney]

This PR embeds the IFPS URI Resolver and IPFS HTTP Client wrappers in the default config, and removes the IPFS and IPFS Resolver plugins. It also cleans up the URIs in the default client config.

The IPFS and IPFS Resolver plugins have been moved to a folder labeled "deprecated" in the IPFS repo: https://github.com/polywrap/ipfs

The wrapper schemas can be viewed here:
IPFS URI Resolver wrapper: https://github.com/polywrap/ipfs/blob/main/uri-resolver/async-uri-resolver/src/schema.graphql
IPFS HTTP Client wrapper: https://github.com/polywrap/ipfs/blob/main/http-client/ipfs-http-client/src/schema.graphql

This PR also updates the UriResolver interface to make the methods accept an optional Env, which can be defined by the implementation. If a wrapper implementation of the interface does not need an env, it can define an empty env type type Env {}. The interface update is published to wrap://ens/wrappers.polywrap.eth:uri-resolver-ext@1.1.0.

Some differences from the IPFS plugin:

• The env is associated with the ipfs resolver wrapper, whereas before it was associated with the ipfs plugin
• The HTTP plugin is a dependency of the ipfs resolver wrapper

Adding the ipfs resolver wrapper to a custom client config is slightly different from adding a plugin. An object has been added to the default config to make it easy for users to instantiate an instance of an embedded package.

// use to create a package instance
export const defaultEmbeddedPackages = {
 ipfsHttpClient: (): IWrapPackage => getEmbeddedPackage("ipfs-http-client"),
 ipfsResolver: (): IWrapPackage => getEmbeddedPackage("ipfs-resolver"),
};

In a client config, simply call the method to create a new instance of the package:

export const getDefaultPackages = (): Record<string, IWrapPackage> => {
 return {
   [defaultInterfaces.ipfsHttpClient]: defaultEmbeddedPackages.ipfsHttpClient(),
   [defaultPackages.ipfsResolver]: defaultEmbeddedPackages.ipfsResolver(),
...

Closes #1177

[cbrzn]

i am so happy to see this PR :-) thanks for pushing this Kris 🙏

the only thing that I am still not sure of is that we are storing the ipfs wrappers in the client config builder; even tho I think this is a smart approach because we are embedding, would also make more sense that we push these built wrappers somewhere and just fetch them using the http plugin? (i think that something like this https://github.com/polywrap/rust-client/blob/develop/packages/client/tests/test_uri_resolvers.rs#L42-L54 can be achieved); I am just thinking out loud here and don't have a clear path (because in that example we are pulling from the test harness, but these wrappers like IPFS can not live inside of this repository), but just wanted to share in case someone agree 😛 . Also, I've realized that GitHub is a good source to fetch packages, and it's really used in the software development ecosystem (swift, go)

Ignoring my previous paragraph, I think this looks amazing 😄

[krisbitney]

i am so happy to see this PR :-) thanks for pushing this Kris 🙏

the only thing that I am still not sure of is that we are storing the ipfs wrappers in the client config builder; even tho I think this is a smart approach because we are embedding, would also make more sense that we push these built wrappers somewhere and just fetch them using the http plugin? (i think that something like this https://github.com/polywrap/rust-client/blob/develop/packages/client/tests/test_uri_resolvers.rs#L42-L54 can be achieved); I am just thinking out loud here and don't have a clear path (because in that example we are pulling from the test harness, but these wrappers like IPFS can not live inside of this repository), but just wanted to share in case someone agree 😛 . Also, I've realized that GitHub is a good source to fetch packages, and it's really used in the software development ecosystem (swift, go)

Ignoring my previous paragraph, I think this looks amazing 😄

That's a fantastic idea! I especially like the idea of pulling it directly from github. I'll update the PR very soon.

[dOrgJelli]

Hey @cbrzn @krisbitney, I'm on the fence about using github via http to fetch the IPFS wrapper each time.

IMO a more web3-friendly way is to have IPFS resolution built-in, and fetch all other URI resolvers (ENS for example) from there.

[cbrzn]

Hey @cbrzn @krisbitney, I'm on the fence about using github via http to fetch the IPFS wrapper each time.

IMO a more web3-friendly way is to have IPFS resolution built-in, and fetch all other URI resolvers (ENS for example) from there.

@dOrgJelli I don't have a strong opinion about the built-in wrappers for the default build, I think it makes sense to improve the URI resolution performance. But I think we should relay on github to use any other wrappers

[krisbitney]

@dOrgJelli @cbrzn sounds good. If we embed the ipfs wrappers, we can eventually create an http resolver wasm wrapper in the future and fetch it over IPFS.

I think we should continue looking at solutions for ipfs reliability. For example, we could give users the option to automatically retry resolving a wrapper if it fails. Sometimes ipfs resolution fails even when i know the wrapper is pinned at ipfs.wrappers.io.

[Niraj-Kamdar]

@dOrgJelli @cbrzn @krisbitney I really like the idea of having an HTTP URI resolver fetching the IPFS wrapper and URI resolver. I agree some people in web3 may not like fetching using HTTP but we are currently doing the same with wrappers.io which is a centralized solution. The only downside would be the need to fetch the IPFS wrapper which can also be improved by caching.

I remember we discussed different kinds of default config for client config builder. Ex: Polywrap can have polywrapDefaultClientConfig, gelato can have gelatoDefaultClientConfig, tezos can have tezosDefaultClientConfig, decentralizedDefaultClientConfig (don't even use wrappers.io), etc.

We can't have one solution that fits for all so by offering all these different default client config flavors, users can choose what is the most appropriate for their app.

[krisbitney]

@dOrgJelli @cbrzn @krisbitney I really like the idea of having an HTTP URI resolver fetching the IPFS wrapper and URI resolver. I agree some people in web3 may not like fetching using HTTP but we are currently doing the same with wrappers.io which is a centralized solution. The only downside would be the need to fetch the IPFS wrapper which can also be improved by caching.

I remember we discussed different kinds of default config for client config builder. Ex: Polywrap can have polywrapDefaultClientConfig, gelato can have gelatoDefaultClientConfig, tezos can have tezosDefaultClientConfig, decentralizedDefaultClientConfig (don't even use wrappers.io), etc.

We can't have one solution that fits for all so by offering all these different default client config flavors, users can choose what is the most appropriate for their app.

I'm happy with both solutions.

I think one caveat is that maybe the IPFS resolver should fetch an HTTP resolver wrapper instead. I updated the IPFS wrapper to retry fetches when they fail, and it is working much better.

Maybe we should make wrappers available at multiple URIs so that users can choose HTTP, IPFS, ENS, embedded, etc. ?

[krisbitney]

I changed the UX for working with the embedded packages and updated the PR description

[Niraj-Kamdar]

LGTM! I like the new UX for embedded

[dOrgJelli]

Going to work on removing the problem mentioned below now.

[dOrgJelli]

This will cause problems in the browser. Instead we should be embedding the raw bytes of the files within a JS module so that reading from a file is not needed.