feat: migrate to Helia from js-ipfs code (ipfs-core, ipfs-http-client)

[SgtPooki]

Replace js-ipfs code (ipfs-core, ipfs-http-client) with Helia. Helia can get blocks either via:

1. It's full-feature node mode (content routing, bitswap)
2. Fetch raw blocks from public gateways (i.e., instead of ipfs.block.get, use https://docs.ipfs.tech/reference/http/gateway/#trusted-vs-trustless)

We should hold to explore.ipld.io functioning as a static self-contained website that works without a local Kubo node.

[SgtPooki]

@rvagg @lidel any qualms against this issue? Does the deployed explore.ipld.io have a backing or remote kubo node to use if we remove js-ipfs?

It looks like it's only deploying to fleek as a static website at this time, so I'm not sure how feasible this is.

[lidel]

explore.ipld.io has always been a static self contained website that works without local Kubo node.

if you want to remove js-ipfs, i see two options:

1. rewrite it so it uses Helia,
2. and/or fetches raw blocks from public gateways (instead of ipfs.block.get, use https://docs.ipfs.tech/reference/http/gateway/#trusted-vs-trustless)

breaking existing users by forcing them to install additional software and set up special CORS headers is not an option, i am afraid.

think about it the other way around: local Kubo is optional, not the main backend :)

See also: ipfs/ipld-explorer-components#359 (comment)

[SgtPooki]

makes sense! I threw this ticket together a while ago without thinking it through, and when I looked again recently figured completely removing js-ipfs wasn't necessarily where this should go; at least for my purposes.

there's still a story here for replacing ipfs-http-client->kubo communication. thanks for the confirmation 👍

[BigLep]

I changed the title and issue description (see history). I think this is useful for showcasing Helia examples.