feat: remove dependency on js-ipfs

[SgtPooki]

Tasks

Beta Give feedback

1. investigate getting blocks/cars using gateway-api, (playground for work required to decouple data-transfer method in helia)
2. Talked with Alex, a simple dag-method wrapper method could be a simpler and more decentralized approach
3. Talked with Alex, a simple dag-method wrapper method could be a simpler and more decentralized approach
4. use kubo-rpc-client instead of ipfs-http-client

[BigLep]

@SgtPooki : a couple of thoughts:

1. Do we maybe want to start building out a "client library" for hitting the Trustless HTTP Gateway API for getting blocks and cars. My guess is dotStorage has likely already created this in some form? @lidel may also know of other cases of this being created in JS already.
2. What is Kubo specific about ipld-explorer-components? I'm basically wondering why we even need a dependency on kubo-rpc-client.

[lidel]

• There is nothing specific about Kubo or JS-IPFS here per se, we just happen to be tightly couple to legacy APIS.
• The smallest interface this type of app really needs is a function that takes a CID and returns bytes for a single block, all parsing happens in JS in the browser (self-contained).
• For this app specifically, (diagnostic tool that slowly fetches small chunk of DAG), i advise against CARs, and do block-by-block
• A single block can be fetched:
  • from a trustless gateway as application/vnd.ipld.raw
    • no need for a special library, fetch + retry logic is enough.
    • Prior art for this exists in Peers screen of ipfs-webui (https://www.npmjs.com/package/ipfs-geoip fetches raw blocks from HTTP gateway and does all parsing in JS – see code here)
  • or be fetched via Helia instance running on page
  • or (opportunistic/if we really need) be fetched from Kubo RPC via ipfs.block.get from js-kubo-rpc-client (if CORS headers are set, and RPC is at the default port)

[SgtPooki]

For this app specifically, (diagnostic tool that slowly fetches small chunk of DAG), i advise against CARs, and do block-by-block

There is already some CAR logic in there, so i assume you're talking about fetching blocks instead of fetching CARs

A single block can be fetched:

I've got this mostly done now, where I query with helia first, with a 5sec timeout, and then query with the trustless gateway.

Prior art for this exists in Peers screen of ipfs-webui (https://www.npmjs.com/package/ipfs-geoip fetches raw blocks from HTTP gateway and does all parsing in JS – see code here)

It looks like the geoip code is not validating the blocks after retrieving? There isn't any info at https://docs.ipfs.tech/reference/http/gateway/#example-fetching-a-single-raw-block-from-a-public-gateway on how to do that, but I think it's something like:

1. have CID instance (with codec type and whatnot)
2. fetch raw block
3. construct CID using raw block bytes, using multihash+codec+base+cidVersion from CID instance in step 1 above.
4. ensure step 1 CID.toString() matches step3 CID.toString() ?

[BigLep]

Thanks @SgtPooki . Looking forward to seeing the PR here.

For your last question, if you're getting blocked, I would post in #ip-js. I expect various folks can point to the JS way of doing block validation.

[SgtPooki]

FYI: the verify block functionality is handled by

ipld-explorer-components/src/lib/get-raw-block.ts

Line 51 in 09ab5e8

export async function verifyBytes (providedCid: HeliaCID, bytes: Uint8Array): Promise<void> {