[python] package generated collections into CAR files, and upload to nft.storage while storing returned CIDv0 vals

[sk33z3r]

Turns out, CIDv1 works with any Pinata gateway. The only issue with using CIDv1 on LRC right now is when it is used for Metadata (because they only convert the NFT ID hex back to CIDv0 in the API). However, putting CIDv1 in the metadata for any field will appear fine in the explorer. As long as the metadata is a CIDv0 that's all that matters.

I'm doing a little research into it, but it's possible that even files uploaded to nft.storage can be accessed by their CIDv0, so we might be able to implement some auto upload feature using nft.storage, as long as we populate the metadata CIDs with v0.

[sk33z3r]

This isn't going to be straightforward at all it seems, unfortunately. Some odd notes:

• Our Node CID binary and the inspector at https://cid.ipfs.io/ seem to give me identical CIDv0/1 pairs.
• nft.storage gives me a completely different CIDv1 after upload, but the image appears to be unchanged. When I download the image from nft.storage then precalc the CIDv1, it gives me what I got locally which is diff than what nft.storage outputs...

The image I'm calculating was saved from nft.storage. The filename is the CIDv1 from nft.storage:

$ ./docker.sh cid --cid-version=0 bafkreicgzakagjvqmryokf5r7btomn2mq7i7hfqdncrixhjqbpnjzlkave.png
QmZ7c36VW3rzeSnN3gMGuGKZQYKCcMVCMfB6x4kRYS5PKn
$ ./docker.sh cid --cid-version=1 bafkreicgzakagjvqmryokf5r7btomn2mq7i7hfqdncrixhjqbpnjzlkave.png
bafybeifadd55nu2s5yv3ap5uztklzcsl34pfc4xs2qfif2robsyccazjne

This is what https://cid.ipfs.io/ shows for the CIDv0 from above:

I'm trying to find a way to convert the CIDv1 I get from nft.storage to CIDv0 just to see if any IPFS gateways will pull the file from its CIDv0. This post has some IPFS commands, but they don't seem to work for me and possibly others.

---

For nft.storage, though, we could upload using their API, which would return a CIDv1 to then use in the metadata. Then we generate CIDs as normal from the metadatas. If my test with the CIDv1 > CIDv0 is successful, then we could always upload everything to nft.storage, then convert the metadata CIDv1s to CIDv0s for minting on Loopring.

[sk33z3r]

Unfortunately the test failed. I don't really know what the deal is with nft.storage giving me a diff CIDv1 than the other tools yet.

[sk33z3r]

Interestingly, if I use the IPFS CAR maker, my CIDv1s match

CAR as generated from IPFS:

CAR after upload to nft.storage:

Perhaps we need to look into generating the Content Addressable Archives for the user in general.

[sk33z3r]

Hmmmmm. So I generated a CIDv0 from the CAR file I downloaded, and when I pasted that CIDv0 into my browser at Loopring's gateway, it actually started downloading the CAR file that I had uploaded to nft.storage.

I need to do some more testing from scratch with images that are not already on IPFS and see what happens.

[sk33z3r]

Got the answer, looks like we'd have to go the CAR file route if we decided to try and do something with this ticket:

https://discord.com/channels/806902334369824788/831502708082081822/972604965778505788

[sk33z3r]

Started working on some parts of this so we're ready for the future:

Forked the ipfs repo, we will likely need to add some custom options to this in the future for some of the ideas I had. Initial though was to fix the rawLeaves option so that my output for CIDv1 is now identical to nft.storage.

sk33z3r/ipfs-only-hash@6c08495

Then I added to the dev/react-ui PR just because this is about to release and these are fairly minor changes so far.

7666902

New output from cid --cid-version=1 for the same file I was having issues with before:

$ ./docker.sh cid --cid-version=0 bafkreicgzakagjvqmryokf5r7btomn2mq7i7hfqdncrixhjqbpnjzlkave.png
QmZ7c36VW3rzeSnN3gMGuGKZQYKCcMVCMfB6x4kRYS5PKn
$ ./docker.sh cid --cid-version=1 bafkreicgzakagjvqmryokf5r7btomn2mq7i7hfqdncrixhjqbpnjzlkave.png
bafkreicgzakagjvqmryokf5r7btomn2mq7i7hfqdncrixhjqbpnjzlkave

[sk33z3r]

Just to document the idea I had. Once a user's images and metadata are generated, we could:

1. Ask for the user's nft.storage API key, upload images and thumbnails there
2. Ask for the user's Pinata API key, upload metadata there

We'd put the CIDv1 for the images/thumbnails into the meta, and keep meta in Pinata and CIDv0. This way users could upload a ton of metadata using the free plan on Pinata, and never have to pay for nft.storage while enjoying the benefits of 32GB per file max size and filecoin replication.

[sk33z3r]

One last detail for the day on this: looks CAR files will ultimately be the way for cross-compatibility no matter the CID version used in a smart contract.

The screenshot is from this page: https://nft.storage/docs/how-to/mint-custom-metadata/

The PR link from the screenshot: nftstorage/nft.storage#991

The rawLeaves option is the thing that is causing murkiness.

I think I will pursue this path instead, because with this we can actually archive all of the user's collection into a CAR, upload that, and then mint with the proper CIDv0 while still using CIDv1 in the metadata.

[sk33z3r]

Package generated collections into CAR files and upload to nft.storage