Rework current pinning & storage strategy #3334
Description
Hence there were unknown changes or at least on Basilisk we've noticed that after fresh minting things are not working.
Thus time to revisit the initial implementation of cf workers and how we have it in the current state.
Currently, the user pins stuff on Estuary, which we've found acting suboptimal as it's being stored on Filecoin (archive nodes(?) and retrieving through pinata gateway takes a long time (peering issues?). (Something has changed outside of our control, we are investigating, it till we are looking to mitigate it and make a more resilient and antifragile scenario)
Future proposed changes are
- NFT Storage is here #3358 temp hotfix
- Pinning metadata on Pinata (as we are blazingly fast here for end-user experience) and rest pinning could be kept on Estuary -> We are pinning rn on NFT.storage and seems temporary hotfix is okay
- At minting, we should push media to CF images (might not happen during BSX mints?)
- At the new implementation, we would doesn't need durable objects at all and fetch images by IPFS hash from CF images to accelerate end-user experience while they browsing collections/explorer
- Explore other fast IPFS gateways #3745
- Implement Pinata as the service provider. #3296
Long-term goal
Currently, we are fairly doing close to 1TB on Pinata Gateway monthly as transfers for users and this would be an interesting way to offload as public goods for storage providers, like those around the Filecoin provider's circle
Suggested would be to recycle code from
- https://github.com/kodadot/nft-gallery/blob/main/src-functions/pinJson.js
- https://github.com/kodadot/workers/blob/master/pinning/src/lib.rs#L84
To make it work with Pinata directly from workers to pin JSON metadata there
Check the links below for more context
Let's comment below if you want to thrill on this issue
Ref
Metadata
Metadata
Assignees
Type
Projects
Status