IPFS URI for tokenId

[benjaminbollen]

• check if we should store the multihash prefix, or predetermine it: conclusion, store CIDv0 digest as bytes32 separate from {ERC1155-uri}
• store CIDv0 digest as bytes32 for tokenID
• return ERC1155 uri(tokenId) as valid ipfs:// URI if CID stored; or return empty bytes if not stored (see below)
• charge 1 CRC for setting URI CIDv0 digest
• add 1155 required event add custom event for CIDv0 update

[benjaminbollen]

for reference:

• https://docs.ipfs.tech/concepts/content-addressing/#cid-versions
• https://github.com/multiformats/cid
• https://docs.ipfs.tech/how-to/best-practices-for-nft-data/#types-of-ipfs-links-and-when-to-use-them

[benjaminbollen]

IPFS has CIDv0 which has less flexibility but will keep being supported. It is easily stored on-chain as the 32byte digest fits in one word. If later a need for support of CIDv1 is desired we can make a separate registration contract that supports the variable length prefix and variable digest length.

Because

• ERC1155 (not strictly, but mostly) expects an https:// identifier, and where the tokenId should be replaced in a string like "https://fallback.aboutcircles.com/v1/circles/{id}.json"; and because
• converting a bytes32 to base58 is complicated in solidity (what's expected for CIDv0, "ipfs://Qm-digest-base58", eg. see an implementation here: https://github.com/storyicon/base58-solidity/blob/master/contracts/Base58.sol)

I propose it is better to keep the uri of ERC1155 to return the "https://fallback.aboutcircles.com/v1/circles/{id}.json" as a (trusted) helper converting the IPFS CIDv0 into a simple HTTP request; and complementary introduce a setIpfsCidV0Digest, and returning the bytes32 of the digest only; leaving it the SDK to convert it to a CIDv0. In exchange there is no need for a setUri function. (It is clear that there is no guarantee about who the owner of the set DNS name aboutcircles.com will be in the future, but the community can always resolve to no-longer call on that URL if it is deemed untrust-worthy.)

Only supporting CIDv0 keeps the contract code trivial, by paying in CRC for storing the bytes32 digest; if later a CIDv1 auxiliary contract is deployed, than the fallback URI of 1155 can take this into account and resolve both CIDv0 and CIDv1 registry under the {ERC1155-URI} fallback.aboutcircles.com/v1/circles/{id}.json URL

[benjaminbollen]

fixed by #84