ipfs: Support other IPFS hash styles instead of hard-coding a prefix

[musoke]

Problem

Currently the plugin just checks that hashes it tries to import start with Qm and are 46 characters. This is not a problem yet, but will be in the future when IPFS hashes have more than one possible format.

I don't see this being at all urgent.

[sampsyo]

Interesting—for my own understanding, what could go wrong if a non-hash string was provided (for example)?

[musoke]

That's a good question.

Not much would go wrong as far as I can see: the request to the IPFS node should just return an error (if the string is not a valid multihash) or timeout (if the string is a correctly formatted but unresolvable). This shouldn't be so bad.

My concern is the opposite: as currently written it may refuse to retrieve valid IPFS objects in the future. This frustrates the user.

There are a couple python implementations of multihash, but I haven't checked how correct/up to date they are.

• https://pypi.python.org/pypi/pymultihash
• https://github.com/tehmaze/python-multihash

[sampsyo]

Ah, I see! I had actually heard of multihash, but I didn't know IPFS used it (which is surprising, I guess, because it seems to have come out of IPFS development?).

So it seems like the solution is either to use a real multihash library to check whether something's a hash, or to find another way to avoid doing the check at all—we'd just pass the opaque string to the IPFS tool uninterpreted.

[musoke]

Yeah, it's one of the tools used in IPFS which they've separated out for more general consumption

Yes, either should work. Would you prefer to avoid additional dependencies? If so the latter may be better.
I might do some testing of each option and ask the IPFS team if there are any subtleties I'm missing

[sampsyo]

Independent of the dependency thing, it seems like the check-free route would just simpler all around… but no big deal if it turns out to be easier to import multihash to get the job done.