Metadata about IPFS CID

[YurkoWasHere]

TODO
Decide if we need to store more metadata about generate IPFS hashes so they can be re-created at a future date in the same way from the original file.

Best solution is to keep the original CAR file, but this may not be practical.

ISSUE Described
Although IPFS CID => 1 File the inverse is not true
1 File => Many IPFS CID not just one. This is dependent on how the file is parsed.

The main IPFS options are that change the CID are

--raw-leaves
--trickle
--wrap-with-directory
--chunker

Note from the help file

Almost all the flags provided by this command will change the final CID, and
new flags may be added in the future. It is not guaranteed for the implicit
defaults of 'ipfs add' to remain the same in future Kubo releases, or for other
IPFS software to use the same import parameters as Kubo.

If you need to back up or transport content-addressed data using a non-IPFS
medium, CID can be preserved with CAR files.
See 'dag export' and 'dag import' for more information.

This means if we ever need to put a file back into an IPFS swarm, we have to make sure we use the right parameters to create the CAR file that will eventually go into IPFS otherwise the IPFS CID will be different.

We may need to store some additional metadata on how we arrived at a CID

Currently we use

ipfs add hello --cid-version=1

--cid-version=1 also triggers

--cid-base base32
and
--raw-leaves=true

[benhylau]

See https://hyphahq.slack.com/archives/C02LDUFLSR2/p1671557371355179 for details