We have ./examples/browser-service-worker which runs in-memory js-ipfs.
That is fine setup, but comes with limitations, like WebRTC not working in Service Worker, which introduces the need for running js-ipfs outside of Service Worker, and introduces overhead of postMessage serialization.
We should add alternative example at ./examples/browser-service-worker-gateways-with-car which:
handles /ipfs/* and /ipns/*
does not run js-ipfs in-memory
has a list of gateways and uses them (at random or as fallback list) for fetching requested files as CAR, verifies CARs, and returns re-assembled data from Service Worker, without the need of any cross-process postMessage present in ./examples/browser-service-worker
After we have this example, we could chat creating real SDK/lib that does both – CAR from gateway pool, and if all gateways are down, fallback to spawning in-memory js-ipfs.
For poc use /api/v0/dag/export endpoint, but before we merge we would switch to proper CAR support on /ipfs/ after https://github.com/ipfs/go-ipfs/pull/8758 ships with go-ipfs 0.13
We have
./examples/browser-service-worker
which runs in-memory js-ipfs.That is fine setup, but comes with limitations, like WebRTC not working in Service Worker, which introduces the need for running js-ipfs outside of Service Worker, and introduces overhead of postMessage serialization.
We should add alternative example at
./examples/browser-service-worker-gateways-with-car
which:/ipfs/*
and/ipns/*
./examples/browser-service-worker