ipfs-webui

ipfs-webui copied to clipboard

• OS: Windows
• Version of IPFS Desktop: 0.20.5

Describe the bug Not all codecs supported by the IPFS command-line are supported by IPFS desktop. See screenshot. It only shows dag-json but also json and some other codecs show the same error.

When making a CID using ipfs dag put someData.json --store-codec=dag-json, I get a CIDv1. Strange enough, dag-json is not in the list of ipfs cid codecs, but supported by ipfs dag put. When copying the received CID to IPFS Desktop, I get error from the screenshot that there is no resolver found for the codec.

To Reproduce Steps to reproduce the behavior:

1. ipfs cid codecs
2. notepad someData.json and add some JSON data
3. ipfs dag put someData.json --store-codec=dag-json
4. Copy the received CID to IPFS Desktop and inspect it.
5. See error

Expected behavior IPFS Desktop recognises that the CID is dag-json, so it should also view information about the content.

Screenshots

Additional context None.

Thank you for filling this.

• ipfs dag CLI is being fixed in https://github.com/ipfs/go-ipfs/issues/8471
  • tl;dr the source of truth is https://github.com/multiformats/multicodec/blob/master/table.csv
• The error from screenshot comes from ipfs-webui/ipld-explorer.
  • I'm moving it to ipfs-webui.

@hacdias mind taking a look if we can add support for dag-json (and dag-cbor) CIDs?

• Supporting them will become critical when https://github.com/ipfs/go-ipfs/issues/8823 lands in go-ipfs 0.14.
• We won't be able to open them as filesystem, so "Browse" should be inactive for them, or open the same view as "Inspect" (ipld-explorer)

@lidel just before I tackle this, isn't the fact that IPLD Explorer still uses the old microformats packages a blocker? And updating that is, in turn, blocked by migrating Web UI to the newer IPFS JS HTTP API version? Because the @ipld/js-dag-json should be incompatible with the old versions.

Refs:

• https://github.com/ipfs/ipfs-webui/pull/1840
• https://github.com/ipfs/ipfs-webui/issues/1798#issuecomment-910930951
• https://github.com/ipfs/ipld-explorer-components/issues/311#issuecomment-1094370144

If so, I have to plan how to proceed forward because of my limited time weekly.

@hacdias

• IPLD Explorer does everything in userland – it will fetch block via ipfs.block.get and then parse it locally using own libs
  • due to this, I believe it is not blocked by js-ipfs-http-client upgrade – I made it compatible with modern block.get in https://github.com/ipfs/ipld-explorer-components/commit/a9e86f491d0f377c88c6e3f4fa6ff99d15df0852
• https://github.com/ipfs/ipld-explorer-components/pull/313 added modern multiformats as a dependency
  • I believe @alvin-reyes added CAR support to https://github.com/ipld/explore.ipld.io without rewriting any legacy code
  • You could try doing a similar thing here – detect dag-json and dag-cbor codec in CIDv1, and special-case its parsing using the new libraries.

@lidel here's a PR to add support for dag-json: https://github.com/ipfs/ipld-explorer-components/pull/319

dag-cbor is supposed to be working already. As you can see, I used this converter to make the new package be compatible with the old ipld. If there are other formats to be supported, or even if you want the old formats updated to the new packages, I can take care of that using the converter.

@hacdias that is a really nice way, was not expecting us to be this lucky :+1: :rocket:

Changes from your PR got released as – mind opening a PR against ipfs-webui that:

1. bumps ipld-explorer-components to v2.3.0
2. adds tests to test/e2e/explore.test.js that protect us against codec-related regressions
   • I think a simple test that
     • imports block with fixture data for tested codec (see list below + repo with potential fixtures to reuse)
     • opens Explore screen
     • enters CIDv1 with specific codec
     • confirms "CID INFO" section contains expected human-readable string or something similar?
       • e.g. for "apollo archives" dag-pb QmSnuWmxptJZdLJpKRarxBMS2Ju2oANVrgbr2xWbie9b2D we should expect base58btc - cidv0 - dag-pb - sha2-256~256~422896A1CE82A7B1CC0BA27C7D8DE2886C7DF95588473D5E88A28A9FCFA0E43E to be present on the screen – iiuc this is enough, because if codec is not supported, the screen will not have this section, but will show the red error as seen in the top comment here.

Some ideas how to make your work easier:

• If you have any good test data, export it as block or CAR and import before running tests (so we don't require any networking, and tests work in offline mode)
• Alternatively, use fixtures from https://github.com/ipld/codec-fixtures
  • These are raw blocks created by IPLD team for test purposes like this one, iiuc you should be able to ipfs.block.put them and and then read data using CIDv1
  • We only need one CID per codec:
    • dag-pb
    • dag-pb hamt-sharded
    • dag-cbor
    • dag-json
    • raw

@lidel so I've been trying to tackle that and I've been running into this two issues:

1. We cannot use ipfs.dag.import on the tests because we don't have an enough updated version of the HTTP API (cc #1838)
2. ipfs.dag.put is failing with HTTPError: Invalid byte while expecting start of value: 0xa2 which may be caused by mistach of go ipfs version and the HTTP client (see https://github.com/ipfs/js-ipfs/issues/3914).

I have been trying to find a workaround, without success. Any suggestions?

This was fixed upstream, and works in the latest webui that shipped with Kubo 0.17

JSON / CBOR saga continues in: https://github.com/ipfs/kubo/pull/9335 (Kubo 0.18 will have JSON/CBOR support on Gateways too)