The browser will currently always download assets for Model Viewer from some configurable IPFS gateway. This is because Model Viewer needs to be given a src attribute with the location of the GLB file.
There are cases when loading an asset from a local IPFS node would be better. This may be a better route than using a public gateway if the asset is already stored locally. This could either be done:
js-ipfs node is running in browser and has the content. Can be fetched via a service worker running a gateway. See https://github.com/ipfs-examples/js-ipfs-browser-service-worker- Some other local IPFS node (Brave, IPFS Desktop, etc) has the content and is running a gateway. This is when
ipfs-provider is using an HTTP client
The browser also appears to cache assets using normal HTTP caching. So it is unclear how much benefit this approach would really have.
The browser will currently always download assets for Model Viewer from some configurable IPFS gateway. This is because Model Viewer needs to be given a
srcattribute with the location of the GLB file.There are cases when loading an asset from a local IPFS node would be better. This may be a better route than using a public gateway if the asset is already stored locally. This could either be done:
js-ipfsnode is running in browser and has the content. Can be fetched via a service worker running a gateway. See https://github.com/ipfs-examples/js-ipfs-browser-service-workeripfs-provideris using an HTTP clientThe browser also appears to cache assets using normal HTTP caching. So it is unclear how much benefit this approach would really have.