I am exploring ways to use the Ceramic stack for dynamic NFTs (dNFTs), and I am wondering about the best approach to assign the Ceramic Stream as the metadata source for the NFT.
The most obvious answer would be to assign it to the
tokenURI like with IPFS
ceramic://<StreamId>. However, I have not found any platform like OpenSea that currently supports Ceramic.
I have seen that you have already created a project with the old stack for dNFTs, where you store the metadata.json with IPFS and only contain the Ceramic stream on the variable
So, my question is whether there is any protocol or CAIP, for instance, that plans to have broad support for Ceramic Streams for NFTs, or if it is advised to keep a separate variable in the metadata for that. I am also interested in how Soulbound NFT is using Ceramic (https://blog.ceramic.network/soulbonds-launch-dynamic-nfts-on-ceramic/) since there is no documentation available.
I am sure that I am not the only one interested in this topic, as the potential for dNFTs is huge, especially with the full CACAO standard implementation and the Identity (DID) layer.
I think for now it is safer to use a proxy server to return a ceramic streams as json.
I don’t believe that would be the case
If your server goes down, the metadata hosted on the tokenURI would be even weaker than if you were using a regular AWS S3 URL. This would defeat the purpose of using Ceramic, which is a decentralized protocol.
My question is whether there are any plans to expand the integration of Ceramic, similar to what has been done with IPFS, Filecoin, Arweave, and other technologies?
From what I’ve seen the Ceramic team approach is to use a IPFS CID for the tokenURI to store the metadata + ceramicURI which is of course suboptimal because changes made on the Ceramic Stream are not taken into account in major NFT marketplaces.
I think this is really a question of NFT marketplaces like OpenSea adding support to view Ceramic streams into their UIs. The approach you mentioned of having the NFT data contain a ceramic url like
ceramic://<StreamId> makes sense to me and seems like the right long term approach to maximize decentralization and minimize single points of failure, but viewing the data within those streams through an NFT marketplace UI would require them to add that support.
I’d definitely encourage you to contact the teams behind your favorite NFT marketplaces and ask them to add support for Ceramic streams!
As per @spencer’s answer, the fact that ipfs://xjalksj get rendered, is only because of wide opensea & wallets & nft indexer & apis support. So yes you could definitely use ceramic://skadj but all the wallets & nft market place won’t be able to render the dynamic content unless they add support on their side. It is much easier to just use a ceramic proxy that return the json.
Indeed this is “centralized” like aws s3 link. But to use ceramic to support dynamic, this is the best we could possibly do for now. How this helps ser.