When storing the DDO on IPFS how to encode the corresponding hash in the OP_RETURN
kimdhamilton opened this issue · comments
From @PositronicBrain on July 13, 2017 10:49
IPFS uses a base58 encoding for the hashes which points to documents, example: QmeNm7hRTtLsYtQA1w8Tu9wHzu8ZfBFc4w59UMuAK3b2ar, which has length 46 bytes. In order to save space in the OP_RETURN one would like to store the raw decoded bytestring.
The above address has decoded representation: 12 20 ee 45 65 85 70 89 4a 2f fe f3 fe 11 de b3 0a ac 08 c4 39 8b e1 bd 25 0d 85 dd bc ca 67 1f 99 bf with length 34. The first byte 12 determines the encoding, sha256 (the standard one in IPFS). The second byte 20 is the length of the hash following it.
Should we keep these two bytes or drop them in the op_return?
Arguments in favour: without them the hash is a random number and censorship resistance improves. We also save space.
Argument against: knowing the hash used improves future compatibility.
Copied from original issue: WebOfTrustInfo/btcr-hackathon-2017#35
From @ChristopherA on July 14, 2017 22:16
I'm in favor of it being that our rule is that if it is a binary 256 bit value, presume that it is an IPFS hash and contruct it. It is the most decentralized and censorship resistance appraoch. If someone wants to refer to the other form, just make it a full URL. Both should work.
this will be assigned to PositronicBrain when he joins org