Data migration from clay-testnet to mainnet

I am trying to make an application where user can make some claims about themselves. So, I want the user to be able to sign these claims that they make about themselves. Since, data in ceramic is already signed, composedb makes a perfect fit for my application.

However, I understand that composedb is experimental yet, therefore it is not supported in mainnet. But, when it gets released, will there be a way to migrate these data that we are writing in clay-testnet to the mainnet?

Hi @Sami,

Apologies for the late reply. Quite a few people from our team were either traveling or OOO.

If you run your own Ceramic and IPFS nodes, your data will be stored on your own infrastructure. Once ComposeDB is available on mainnet, theoretically you should be able to upgrade your software and switch networks while retaining all your data.

However, since ComposeDB is still experimental, it would be difficult for us to guarantee that there won’t be any breaking changes in the software that might make it difficult to keep using that data.

cc @spencer, in case I misspoke.

unfortunately no, it’s not that simple. The data you create on clay will be anchored on the Goerli ethereum testnet, while Ceramic mainnet only supports anchors on Ethereum mainnet. Since Ceramic mainnet nodes won’t be able to validate the anchors for the testnet data, it won’t be able to confirm that data was created during a time when the capability authorizing the data creation was still valid, and so the Streams will fail to load.

So in short, no, there is no easy or automatic way to port data from clay to mainnet. You could build a manual system where whenever the user logs into your app it queries a testnet node to see if that user’s DID had any data on testnet, and than manually re-publish that data to mainnet (using a new capability and getting the data re-anchored on eth mainnet). You’ll lose the history of any old versions or updates that were made to the streams on testnet, but if you only care about the current versions for the documents, then this could be a viable option, albeit one that requires a bit of extra engineering effort to build.