#NFT And Storage

33 messages · Page 1 of 1 (latest)

heavy isle
#

I am working on project where I want to mint some NFTs on Stellar using Soroban.
I am using @harsh owl millionlumens project to get the erc721 base implementation. Thank you for that 🙂

I have these questions regarding the storage since I want to make sure data is always available.
Do we need to bump the storage and why wee need to do it?
Is it a problem to store all NFT metadata on the ledger?

glacial spear
# heavy isle I am working on project where I want to mint some NFTs on Stellar using Soroban....

Hey there!

My first instinct would be to store the NFT metadata as 'Instance' type storage, sharing the lifetime of the contract instance. This would require regular bumps to remain active and could be restored after expiration.

I'm not very knowledgeable on NFT use cases but this document should provide you with a good understanding on how state expiration is handled on Soroban.

I would love to hear from someone with more experience with NFTs

harsh owl
#

the problem with instance is that it does not scale. In my example I use instance for the metadata (name and symbol) but persistent for others when possible (i.e. data linked to owners and token ids) and temporary for the authorization. This way, the function call fees should remain constant over time.

glacial spear
cosmic pike
#

The more you store the more expensive itll be basically what vinamo said above

heavy isle
harsh owl
#

everything need to be bumped, even the contract itself

#

and its code

heavy isle
cosmic pike
#

Ipfs

glacial spear
#

This content might provide some insights on how to use IPFS in this context:

  • How To Build an NFT App Using IPFS: Code Along
    It is from a great series done by Chainlink with dapp use cases being implemented from scratch. Although, this being a solidity example, it still doesn't cover Soroban specifics like the state expiration and the need to bump the contract and storage.
YouTube
Chainlink
How To Build an NFT App Using IPFS: Code Along

Learn how to build an NFT application where the images are hosted on IPFS. You'll develop skills to help you create an NFT project and store your data in a d...

▶ Play video
cosmic pike
#

If you don't wanna run your own IPFS node for pinning your content i recommend a site called "pinata" https://www.pinata.cloud/ for $5 usd per month you can pin your files and make sure they stick around.

Pinata | IPFS API & IPFS Gateway

Pinata makes it simple to upload content to IPFS with developer tools and fetch it at blazing speeds with Dedicated Gateways.

cosmic pike
eager cloud
cosmic pike
#

Oh awesome i've never tried that, I actually run a server at my house for ipfs so i don't have to pay, I'll have to check that one out

#

Pinata does allow doing locked content to nft's also which is quite awesome, though in theory that could be done anywhere also

ivory goblet
#

I think the basic question is should bump fees be paid for by the creator or the owner? I'm thinking creator pays for the contract and contract data (name, symbol, count, etc) while the owner/minter pays for the metadata associated with the nft number they own. You can store the image on IPFS etc but the url to IPFS still needs to be on chain and is different for each user. Owner/minter probably pays for the metadata.

Then the question is who pays for storage when its resold on a secondary marketplace like Litemint And the contract has to be active/live for the sale to go through, right?

ebon ginkgo
#

I would say it can also depend on the purpose, and on agreement between issuer/minter and holder.

If the NFT is a collectible (with or without monetary value) that I like to hold and display (say some artwork), it makes sense for me as holder to pay any fees related to it.

If the NFT is more utilitarian (say, seat tokens for a Taylor Swift concert), it seems more reasonable for the concert organiser to ensure the NFT's remain functional. At least for as long as they have utility the organiser wants to use.
If later that token becomes a collectible, the onus might shift to the holder.

I see that it's not very rigid or codified, but it's my 'common sense' interpretation

cosmic pike
#

you could check if the storagekey needs bumped then require the person listing it for sale to bump it

chrome shore
#

think the basic question is should bump fees be paid for by the creator or the owner?
this is an implementation detail and thus is not worth to spend time discussing

#

(unless you're talking about specific implementation - even then, I'd imagine this to be a setting at contract instance level)

heavy isle
#

following on what Silence said, could we implement something like ?

let value = storage.get(key);
if value is null {
bump storage.key
value = storage.get(key)
}

cosmic pike
#

It'd be nice to have a method to check if it's expired

chrome shore
#

FWIW this can only happen off-chain, I hope that's what you're discussing

cosmic pike
#

Yeah i know... i mean though itd be nice if there was a host method to check.. because in theory itd be possible. Maybe in p21

cosmic pike
chrome shore
#

recovery can only happen via a special operation, at least in the protocol 20

cosmic pike
#

Where is that interface defined and specs of what youd need to build to providr the service... i wonder if it is gonna act sort of like a request retrieve oracle or will recovery happen strictly off chain

chrome shore
#

https://soroban.stellar.org/docs/fundamentals-and-concepts/state-expiration#restorefootprintop - that's the core-level interface. in protocol 20 it can be just executed whenever the entry is expired archived. so you can build with this expectation in mind initially. going forward, when entries are actually moved to the archive, there will be some separate archive interaction interface which is still TBD and will be TBD for a while (we'll of course keep everyone up to date on the design)

cosmic pike
chrome shore
cosmic pike
#

Yea sure no problem i thought there was a new one i saw but this will get me caught up. Thanks

heavy isle