-
Notifications
You must be signed in to change notification settings - Fork 167
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support CIDv0 #571
Comments
In general we want folks to move to v1 CIDs so we currently don't offer this as an option in our file upload API. If there's a need for a shorter string then v1 CIDs can be re-encoded using a different multibase. e.g. $ ipfs cid format bafkreiem4twkqzsq2aj4shbycd4yvoj2cx72vezicletlhi7dijjciqpui -b base58btc
zb2rhg8GjTeiGgWe6HVCgps3wMMV8CX6BrBZxebQKZwA4wEzd There's also a JS library that can help with this: https://www.npmjs.com/package/cid-tool Would it be possible to PR the HEN minting contract? |
Unfortunately, the contact is hardcoded to only accept an IPFS URI of 53 chars. HEN would have to deploy a new contract to change this requirement. Infura and Pinata both support CIDv0 so it looks like HEN would have to keep using either of those for storing their metadata. |
Also, I tried the cids library but it seems the NFT.Storage CIDs can't be converted to CIDv0 since I get this error when calling cid.toV0(): |
@NoRulesJustFeels that depends on the CID, I'm guessing you are using We had relevant issue #387 with some more details.
Given that base58btc encoding is 49 chars would not that be enough ? Or does 53 chars expect |
53 chars includes the ipfs:// prefix. |
I do get it but I presume that ERC721 tokenURI would come out as You could workaround the char limit problem by:
Unfortunately that would not fully address the problem however because if metadata is <1 mb in size it would end up encoded as a You could alternatively use I think best solution would be to get HEN smart contract address the char amount limitation and invaild URLs which they seem to be putting on chain. In the meantime it's probably best to fork the client to retrofit it's
|
Thanks for the detailed explanation. I don't believe HEN is following ERC-1155 (especially since this is the Tezos blockchain), so it wouldn't call client.store({}), but rather client.store(blob) or client.storeDirectory(form) Here is a typical metadata URI: ipfs://QmWuyrBArCUvzCQjcSctbyajMaNvmg5J2pxTLkFSVeTqU1 I'm not a HEN developer so I don't know what the implications are for having to change the minting contract. |
@Gozala will link to this issue in a new issue in HEN's repos! |
With the update to ipfs-car supporting raw leaves, can we close this @alanshaw ? |
#991 will add to the docs how to use CIDv0. Closing this issue, let us know if any questions! |
I'm trying to use Nft.Storage for uploading the metadata for the Hic Et Nunc NFTs. It seems that the HEN v1 minting smart contract is checking that the metadata URI is exactly 53 chars long which means it only supports CIDv0.
It's not clear if Nft.Storage supports CIDv0; I don't see anything in the docs for the Nft.Storage JS client library. By default, I'm always getting CIDv1 with Nft.Storage.
The text was updated successfully, but these errors were encountered: