ipfs-shipyard / ipfs-provider Goto Github PK

Add docs and code examples for creating a custom provider.

(I suspect existing API is not the best for this, we may need to export a nice helper function that takes care of applying globals such as connectionTest)

..or we could simply show how to re-use jsIpfs for this

There should be a way to customize the order in which providers are tried.
For example, if I want to ensure my app tries remote API before falling back to window.ipfs and embedded js-ipfs, I should be able to specify providers via ordered list:

const { ipfs, provider } = await getIpfs({
  fallbackOrder: ['api','window.ipfs', 'js-ipfs']  // strings? import enums?
  apiAddress:    '/ip4/10.1.1.1/tcp/5002'
  jsIpfsOpts:    {}
})

Additional notes:

• Providing ordered list of providers should take precedence over individual flags such as tryApi: false
• cc @parkan for thoughts and suggestions for use cases at Internet Archive

below is just a quick idea, let me know your thoughts on this

Context

Right now one needs to explicitly pass ipfs instance for js-ipfs to work:

const { ipfs, provider } = await getIpfs({
  tryJsIpfs: true,
  getJsIpfs: () => import('ipfs'),
  jsIpfsOpts: { /* advanced config */ }
})

This is great, but some folks just want "batteries-included" experience where ipfs-provider takes care of loading and initializing existing browserified js-ipfs (think pocs, demos, prototyping, quickly switching between different versions/bundles etc).

Load js-ipfs from custom URL

A solution is to allow user to pass jsIpfsBundleUrl

const { ipfs, provider } = await getIpfs({
  tryJsIpfs: true,
  jsIpfsBundleUrl: 'https://cdn.jsdelivr.net/npm/[email protected]/dist/index.js'
  jsIpfsOpts: { /* advanced config */ }
})

The above should take care of adding <script> to the pagecontext before init with jsIpfsOpts is executed.

Ultimate fallback to latest js-ipfs

To make it even easier for beginners, ipfs-provider should default jsIpfsBundleUrl to https://unpkg.com/ipfs/dist/index.min.js when getJsIpfs and jsIpfsBundleUrl are absent.

TL;DR it should be possible to run:

const { ipfs, provider } = await getIpfs({ tryJsIpfs: true })

..and get the latest js-ipfs from NPM.

It would be rad cool if it would check if the Service Worker Gateway is around. I believe you can do that by creating an iframe that loads js.ipfs.io and does a double bridge. (this page to iframe, iframe to service worker in js.ipfs.io)

Hi, I don't really understand why with default configuration, the ipfs-provider doesn't work. I'm currently working on a browser-only environment without anykind of advance usage with webpack, browserify or anything.

That's how I'm getting ipfs object getter:

<script src="https://cdn.jsdelivr.net/npm/[email protected]/dist/orbitdb.js" integrity="sha256-hyVW35Y+JfcPUDLNCNcl8ELtT0p8XQQkk8TG0qU/Cxo=" crossorigin="anonymous"></script>
<script src="https://cdn.jsdelivr.net/npm/[email protected]/dist/index.min.js" integrity="sha256-EjtfQnFY9TWI8ZHFqKjHcqgHHnrE2uQrzQgaYgKro7I=" crossorigin="anonymous"></script>
<script src="https://cdn.jsdelivr.net/npm/[email protected]/dist/index.min.js" integrity="sha256-0gpmoxZ7DiHqTnHEQM575Y8HWk1dxrlzwRejOm6yIIw=" crossorigin="anonymous"></script>
<script src="index.js"></script>
<script>
  console.log(window)
  const ipfsGetter = window.IpfsProvider.getIpfs();
  ipfs_browser(ipfsGetter, window.OrbitDB);
</script>

And that's how I'm accessing to it (index.js):

const ipfs_browser = async (ipfsGetter, OrbitDB) => {
    const ipfs = await ipfsGetter;
    console.log(ipfs)
    console.log(OrbitDB);
}

However ipfs object getter always return undefined even if window.IpfsHttpClient exists.
Could you help me with that small issue ?

It would be great to know whether and how (shared) service workers Gatway would be supported.

https://github.com/ipfs-shipyard/service-worker-gateway

Related to #26

Add examples/ with code that run in web browser and demonstrates use of ipfs-provider.

This is important and should be done before releasing the new major version with #3 and #10. Without this we may miss shortcomings of the new API.

Context

Synchronous API at window.ipfs (v1) is being deprecated in favor of async window.ipfs.enable (v2) that supports asking for multiple permissions in bulk (details: ipfs/ipfs-companion#589)

TODO

• support for asynchronous window.ipfs.enable
• support passing commands and experiments to window.ipfs.enable
  • Other providers may want to add support for those in the future, so those could be top-level config options.

Prior Art

window.ipfs-fallback: code+tests

[enhancement]

The http-client.js instantiate ipfsClient in the maybeApi method with a single parameter.
This parameter could be according to the documentation in the following form:
https://github.com/ipfs/js-ipfs-http-client#importing-the-module-and-usage

// connect to ipfs daemon API server
const ipfs = ipfsClient('http://localhost:5001') // (the default in Node.js)
// or connect with multiaddr
const ipfs = ipfsClient('/ip4/127.0.0.1/tcp/5001')

However if ipfs-provider users want to tune a global timeout to all request the options mode should be used, https://github.com/ipfs/js-ipfs-http-client#global-timeouts.

// or using options
const ipfs = ipfsClient({ host: 'localhost', port: '5001', protocol: 'http, timeout: '2m'' })
// or specifying a specific API path
const ipfs = ipfsClient({ host: '1.1.1.1', port: '80', apiPath: '/ipfs/api/v0', timeout: '2m' })

I'm particularly interrested with the global timeout option.

Thanks

It would be great to know whether and how (shared) service workers would be supported.

Shared service workers: https://github.com/ipfs/js-ipfs/tree/master/examples/browser-sharing-node-across-tabs

I just upgraded my local ipfs dependency to 0.48.1 and now I get these 2 errors:

Code:

    const { ipfs } = await getIpfs({
      providers: [
        providers.jsIpfs({
          loadJsIpfsModule: () => import('ipfs'),
          options: defaultNodeOptions,
        }),
      ],
    });

Console errors:

[ipfs-provider] NotInitializedRepoError: Repo in path ipfs is not initialized!
    at Object.getVersion (webpack-internal:///./node_modules/ipfs/node_modules/ipfs-repo-migrations/src/repo/version.js:24:11)
    at async Object.migrate (webpack-internal:///./node_modules/ipfs/node_modules/ipfs-repo-migrations/src/index.js:64:26)
    at async IpfsRepo.open (webpack-internal:///./node_modules/ipfs/node_modules/ipfs-repo/src/index.js:128:11)
    at async Proxy.init (webpack-internal:///./node_modules/ipfs/src/core/components/init.js:62:9)
    at async Object.create (webpack-internal:///./node_modules/ipfs/src/core/index.js:55:3)
    at async tryJsIpfs (webpack-internal:///./node_modules/ipfs-provider/src/providers/js-ipfs.js:13:16)
    at async getIpfs (webpack-internal:///./node_modules/ipfs-provider/src/index.js:52:19)

App.vue?ec60:101 TypeError: Cannot read property 'ipfs' of undefined
    at _callee3$ (ipfs.hook.ts?cf80:37)
    at tryCatch (runtime.js?96cf:45)
    at Generator.invoke [as _invoke] (runtime.js?96cf:274)
    at Generator.prototype.<computed> [as next] (runtime.js?96cf:97)
    at asyncGeneratorStep (asyncToGenerator.js?1da1:3)
    at _next (asyncToGenerator.js?1da1:25)

Also, when following your documentation and use this:

    const result = await getIpfs({
      providers: [
        jsIpfs({
          // eslint-disable-next-line global-require
          loadJsIpfsModule: () => require('ipfs'),
          options: defaultNodeOptions,
        }),
      ],
    });

I get this pointing to L2 (providers: [)

TypeError: Object(...) is not a function
    at _callee3$ (ipfs.hook.ts?cf80:38)
    at tryCatch (runtime.js?96cf:45)
    at Generator.invoke [as _invoke] (runtime.js?96cf:274)
    at Generator.prototype.<computed> [as next] (runtime.js?96cf:97)
    at asyncGeneratorStep (asyncToGenerator.js?1da1:3)
    at _next (asyncToGenerator.js?1da1:25)

I ran into this same issue recently when developing an extension with IPFS in the backend. CORS will not allow the http api to talk to the desktop daemon. I fixed this in my extension by changing the source of the request, but this involved capturing the request before it was sent. Anyone found a workaround?

it's a smaller package.

Dear Friends,
I'm working on a wiki dapp and needed to lighten its overall size.
I load ipfs-http-client only when users need to update their wiki.
I fork ipfs-provider and made the necessary updates:.
https://github.com/xmaysonnave/tiddlywiki-ipfs
is built against
https://github.com/xmaysonnave/ipfs-provider

• travis runs correctly.
• I added a .nvmrc as I use nvm.
• I didn't mock the loader
  Thanks

Can you please add typescript typing to your project? thank you.