Please use valid ipfs:// URLs (which use non-case sensitive CID encoding)

[Gozala]

Describe the bug

nft.storage users are running into 53 char limit with HEN as per https://github.com/ipfs-shipyard/nft.storage/issues/571. Looking into this issue we also identified that HEN uses ipfs://Qm...hash style URLs are invalid as described here https://github.com/ipfs-shipyard/nft.storage/issues/571#issuecomment-941225557

Problem is that URL spec defined hostname section as case insensitive and many programs (including browsers) would normalize hostname segment to lower case resulting in an incorrect CIDs. This was primary reason why IPFS transitioned to base32 encoded CIDv1 representation which is bit longer (59 chars) but is less problematic.

Please consider switching to the same representation in HEN so that:

1. So that tools looking at NFT tokenURIs aren't encountering wrong CID due to URL parse normalization.
2. Users can provide non dag-pb encoded content (which can only be represented by CIDv1 which is would not fit 53 char limit)

Expected behavior

• HEN minting smart contract accepts valid IPFS urls which are (CIDv1 in base32 encoding).
• HEN minting smart contract uses valid IPFS urls in tokenURIs. That is ipfs://Qm..hash URLs are either rejected or transcoded to ipfs://bafy...hash style URLs to appear correct on chain.

Additional context Please see related issues https://github.com/ipfs-shipyard/nft.storage/issues/571 https://github.com/ipfs-shipyard/nft.storage/issues/387

Please note while nft.storage could support CIDv0 it would still be bad if that lead to bad ipfs:// urls on chain.

[crzypatchwork]

appreciate the support we can use other CID versions still for media though.

[Gozala]

@crzypatchwork thank you for getting back to us. Can you please help me understand what the plan is ? We really want to figure out a way to fix this so users like @NoRulesJustFeels aren’t left without workable solution.

If this is something that will get fixed on HEN side we can refer users to this issue. If there is no plan to address this by allowing proper ipfs URL maybe we can have conversation what a solution might look like so we can enable our users to use both our products.