NFT.storage bridge - protocol design

[irenegia]

The spec can be found here
https://hackmd.io/lh3isDK7Sq6Jgfg9hIPPDQ

[irenegia]

We have 3 pieces:

1. smart contract (see spec), written by @turinglabsorg
2. watcher (listen to sc events on ethereum) --> check with NFT.storage if they already have something for this
3. fliecoin "oracle" (info that from filecoin to the sc, @riba will help with this)

Mechanics:

contract is developed and deployed by cryptonet team onto each chain of interest, allowing trustless fully-on-chain interaction, with the authentication being the user holding (or having minted) the nft in question

a sidecar developed by cryptonet team (running either directly within daghaus or somewhere by the cryptonet team), periodically checks for "changes" in the above contract(s), and whenever new DAG CIDs appear submits them to the nft.storage pinning API, circumventing space/rate limits ( the rate of calls is moderated by the gas expenditure needed to record stuff into the contract queue )

everything proceeds using the already-existing daghaus storage flow from this point on, lands into the dagcargo queue, eventually gets downloaded, gets onto filecoin

when there are changes to state of deals containing data from the particular "nft.storage-official contract" user, dagcargo submits necessary notifications/metadata to the cryptonet team, who in turn update the contract state with the right statuses etc

cc @lucaniz

[turinglabsorg]

A small update on point 2 (watcher (listen to sc events on ethereum) --> check with NFT.storage if they already have something for this), i've already developed a draft (https://github.com/protocol/onchain-storage/tree/main/protocols/nftstorage-bridge/node) which works with public NFT.storage APIs.