Update website to latest js-ipfs and ipld-explorer-components

[lidel]

• update ipld-explorer-componentshttps://github.com/ipfs/ipld-explorer-components) to the latest JS APIs
  • caveat: it has to work with both js-ipfs embeddded on explore.ipld.io AND go-ipfs via js-ipfs-http-client in ipfs-webui
• update this repo to the latest js-ipfs
  • ensure we use 4 preload nodes instead of only 2 (fix: new preloads and bootstrappers #72)
  • enabling best-effort webrtc like we did in feat: small bundle + enable webrtc-star in no-failure mode ipfs-shipyard/ipfs-share-files#121 could improve link sharing between browsers

[achingbrain]

update to latest js-ipfs

The latest js-ipfs supports the new multiformats stack, but some formats haven't been ported yet (e.g. ipld-bitcoin, ipld-ethereum, ipld-git and ipld-zcash at least) - these will need to be wrapped in the ipld-format-to-blockcodec module if we wish to continue supporting them in the explorer.

[lidel]

fwiw this should not be a blocker – I suggested removing those fringe formats from example list – those are not supported out of the box in js-ipfs anymore, and adding dag-cbor / dag-json ones instead is way more valuable for ecosystem: #62 (comment)

Added to the maintenance board.

[achingbrain]

those are not supported out of the box in js-ipfs anymore

It's possible to configure them fairly easily, see examples/traverse-ipld-graphs/eth.js and examples/traverse-ipld-graphs/git.js for how.

[BigLep]

Next steps per 2021-07-30 discussion:

1. When this does get touched, we need to make sure we're able to stay up-to-date with latest ipld used in js-ipfs. We should have CI running that catches issues sooner while attempting to use the latest versions.
2. We don't know if a tribute will be able to take this during their tribute week.
3. It may make sense to build this application from scratch and hire it out. The first step here would be w3dt Stewards to write a Minimal Project Proposal describing the problem/candidate.

[BigLep]

Note that on 2021-09-21 we had another outage that was resolved with #72

[lidel]

Additional context about how IPLD Explorer consumes libraries and data (useful for onboarding when picking up the upgrade tasks):

There is a deeper problem and nuance around ownership and dogfooding in IPLD Explorer.
IIRC IPLD Explorer reads raw blocks via ipfs.block.get and processes them in the browser using js-ipld (thse days deprecated in favor of js-multiformats).

I believe the app uses IPLD libs directly because ipfs.dag.* was not enough at the time. Last time I checked ipfs.dag.* was still not ready (API exposed by js-ipfs and go-ipfs+js-ipfs-http-client had different behaviors).

While tempting to "do use IPLD end-to-end" here, switching IPLD Explorer to ipfs.dag.* is much bigger task because it requires cleanup and unification of ipfs.dag.* in go-ipfs and js-ipfs* and I am not sure if that should be in scope of this app (we have interop test suite for things like this).

Keeping the existing approach of fetching raw blocks and processing them via IPLD lib directly is probably the safest path forward, as it is immune to ipfs.dag.* discrepancies and makes it work the same no matter which backend is used.

In my mind, descoping ipfs.dag.* from IPLD explorer is a feature, not a bug: this way we could create and run E2E tests for explore.ipld.io in CI of js-multiformats library, providing IPLD team with instant feedback about breaking changes and painful refactors.

[lidel]

Interop around ipfs.block.get (ipfs/ipld-explorer-components@a9e86f4) was included with #73:

This wrapper ensures the new block service
from js-ipfs AND js-ipfs-http-client works with the legacy code
present in ipld-explorer-components

(ir)rationale: we have no bandwidth to rewrite entire IPLD Explorer
..but thanks to it using only ipfs.block.get, making it extra compatible
is not very expensive. This buys us some time, but this technical debt
needs to be paid eventually.