Gozala
commented
3 years ago I've put together this observable that attempts to clarify what is currently possible and what is not.
To execute you'd need to fork and add
NFT_STORAGE_TOKENsecret to your profile or just substitute line that accesses it with your access token.
Here is the screenshot
Here is the summary
- It is possible to upload
metadata.jsonto nft.storage and encode returned CID string into more compact representation. - Gateways should be able to serve content regardless of CID encoding in the URL.
- To get
Qm...hashCID needs to V0 - CID V0 implies DAG-PB encoding of content, but small files (< 1mb) will end up in Raw encoding instead.
- CIDs of small files (<1mb) will not convert to CID v0 (ones that start with
Qm...), because they aren't DAG-PB. - It is still possible to represent such CIDs in more compact encoding via base58btc strings that will be 49chars long.
If 49 chars will satisfy contract character limit constraint, than solution is simply to take cid from nft.storage and encode it as base58btc string. Otherwise things are bit more complicated, if files aren't small (<1mb) CIDs can be encoded as v0 base58btc ( Qm...hash style). It is still possible to do it with storeCar API but that is going to involve a lot more code and maybe at that point it would be worth exposing an option to force dag-pb instead.
The HEN team mentioned that for minting metadata they need to use a separate IPFS node to generate Qm hashes for their metadata.json because of constraints in the number of characters on the contract side.
It'd be useful potentially to enable users to specify on upload whether they'd like to generate Qm or bafy hashes.