"contributionDescription" type is too small to fit an IPFS hash

[jellegerbrandy]

At the moment, the "IPFS Hash" defined here: https://github.com/daostack/arc/blob/master/contracts/universalSchemes/ContributionReward.sol#L22 as bytes32

This is too small to contain the default IPFS hash. This stackoverflow answer explains it in detail https://ethereum.stackexchange.com/questions/17094/how-to-store-ipfs-hash-using-bytes (we need 34 bytes).

Note that this is only the defaut scheme for IPFS. In theory, ipfs supports different hashing schemes and variable hash lengths.

This is not just in theory. The current IPFS hashing scheme will be replaced: https://github.com/ipfs/ipfs/issues/337

So: bytes32 is no good. Two possible laternatives:

• if we want to use a fixed-length schema, we can use the trick from the stackoverflow question (but note that this is not completely future proof either)
• alternative, just make it a string and get it over with. We are not storing it in permanent storage anyway, so the costs argument is not so strong.

[jellegerbrandy]

I vote for the string option

[dkent600]

Not saying it is necessarily a good idea, but I suppose one could generate a bytes32 hash from the ipfs hash.

[orenyodfat]

Thanks @jellegerbrandy .
I will add this :https://github.com/saurfang/ipfs-multihash-on-solidity to the reading list..
Even though I tend to agree with the string solution as we would like to be future proof (even use other decentralised storage e.g swarm) ...even in the cost of passing a string to the propose function ...(it is not save on storage).

[bohendo]

I like what @dkent600 is suggesting. Storing an IPFS hash in a bytes32 slot is a common problem and a more elegant solution is something the wider ecosystem would find valuable. It would be satisfying if we could solve this problem well.

I don't really understand the implications.. but how hard would it be to use a 30 byte hash so that the prefix+hash does fit cleanly into 32 bytes? I suspect the IPFS node would need to be updated to understand this new prefix so it might be more trouble than it's worth..?

[jellegerbrandy]

@dkent600 's idea would basically obfuscate the ipfs link, which defeats the purpose. Running a custom ipfs schema is also not an option: the document would only be available on nodes that understand that schema, i.e. basically on our own private network. @orenyodfat 's PR solves the problem in a straightforward way, and it is not too expensive as we are not saving the hash anyway (just showing it in the event)