Should we consider adding the Lockup NFT on IPFS?

[andreivladbrg]

Note

This is just an idea, and I have not made research on IPFS. First, I want to see your opinions.

Recently, Max asked me about the NFTDescriptor contract. This made me realize that our current design requires a unique implementation of the contract for each new chain (in case we plan to extend the contract to multiple chains). This means higher development and maintenance costs.

Instead, we should consider adding the NFT to IPFS and using it across all chains to make it more flexible.

I know that the SVG is dynamically built, which is more problematic. I am not very familiar with IPFS, but there may be a way to pass parameters when obtaining the SVG from it. In the worst case, we could have a template NFT SVG on IPFS and then make some replacements (unique collor and progress) in the tokenURI function.

Another benefit would be that we would have one less contract to deploy each time - thus, less costs

@sablier-labs/solidity

[PaulRBerg]

Interesting creative idea!

Unfortunately, it is not possible to do this for our current NFTs because the SVG is dynamically built. Even if it's possible to pass parameters, that's barely scratching the surface in terms of the logic required to replicate our existing design.

For other chains (e.g. Solana), I suggest starting simple — displaying the Sablier logo for all NFTs, or a basic replica of our EVM design that is identical across NFTs.

[PaulRBerg]

cc @maxdesalle for our Starknet deployment, we could do the same, i.e. use a a simple Sablier logo for the NFT. Unless you have already developed the implementation?

[maxdesalle]

cc @maxdesalle for our Starknet deployment, we could do the same, i.e. use a a simple Sablier logo for the NFT. Unless you have already developed the implementation?

I just finished the NFTDescriptor contract, but I still have to build the actual SVG generator library. So yeah, let's just go with a simple IPFS-hosted image. IMO the right strategy for multichain deployments like Starknet is to start with something minimal (sort of a high quality MVP), see if it gets traction, and then iterate on it if it does. For future releases, we can consider ditching the NFTDescriptor entirely and just store everything in IPFS. Only problem, though, is that IPFS isn't permanent AFAIK, so it's not as lindy as the dynamic onchain SVG structure we currently use.

The timing is perfect here as I was planning to start working on the SVG generator library today! This will allow me to already start to focus on testing.

[PaulRBerg]

Sounds good.

simple IPFS-hosted image

Better than that: hard-code the Sablier logo as an SVG constant.

[maxdesalle]

Better than that: hard-code the Sablier logo as an SVG constant.

Excellent idea! Implementing now.

[smol-ninja]

there may be a way to pass parameters when obtaining the SVG from it. In the worst case, we could have a template NFT SVG on IPFS and then make some replacements (unique collor and progress) in the tokenURI function.

Even if we manage to do this on the Sablier UI, the NFT visualisation may break on other platforms such as mobile wallets, DeFi platforms etc, until they also replace placeholders in the SVG with stream specific data.

For other chains (e.g. Solana), I suggest starting simple — displaying the Sablier logo for all NFTs, or a basic replica of our EVM design that is identical across NFTs.

Sounds like a good idea to me. And if we gain enough traction, we can pay the cost of developing NFTDescriptor contract.

[maxdesalle]

Sounds like a good idea to me. And if we gain enough traction, we can pay the cost of developing NFTDescriptor contract.

Yeah, this is the right strategy IMO. Start lightweight, see if you get traction, and iterate in case you have.