Closed ben221199 closed 1 year ago
Thank you for filling this.
ipfs dag
CLI is being fixed in https://github.com/ipfs/go-ipfs/issues/8471
@hacdias mind taking a look if we can add support for dag-json
(and dag-cbor) CIDs?
@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:
If so, I have to plan how to proceed forward because of my limited time weekly.
@hacdias
ipfs.block.get
and then parse it locally using own libs
block.get
in https://github.com/ipfs/ipld-explorer-components/commit/a9e86f491d0f377c88c6e3f4fa6ff99d15df0852 multiformats
as a dependency
@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:
test/e2e/explore.test.js
that protect us against codec-related regressions
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:
ipfs.block.put
them and and then read data using CIDv1 @lidel so I've been trying to tackle that and I've been running into this two issues:
ipfs.dag.import
on the tests because we don't have an enough updated version of the HTTP API (cc #1838)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)
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 alsojson
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 ofipfs cid codecs
, but supported byipfs 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:
ipfs cid codecs
notepad someData.json
and add some JSON dataipfs dag put someData.json --store-codec=dag-json
Expected behavior IPFS Desktop recognises that the CID is
dag-json
, so it should also view information about the content.Screenshots![image](https://user-images.githubusercontent.com/12856904/162975053-b7ccd9a6-5ae0-435e-9177-5ebdf3bf763e.png)
Additional context None.