Giters

onflow / freshmint

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Use more unique names for contracts and paths

joshuahannan opened this issue · comments

commented

Many of the contract and path names use very generic names such as NFTAirDrop or /storage/NFTAirDrop. They should probably include Freshmint in the name so they can be unique and not conflict with other potential contracts and paths.

There are other examples that aren't mentioned here, so the code should just be audited to look for all relevant places to make these changes.

commented

Thanks for the feedback!

For NFTAirDrop, I'm going to remove the storage path variables altogether. As mentioned on #81, it makes more sense to just require the caller to define their own path.

I'm thinking that pattern might also make sense for NFTClaimSale. No default paths, instead the caller chooses a path that's unique to their project.

Lastly, for the NFT templates, the path will be unique based on the contract name chosen by the user. Does that seem unique enough, or do you think there should be some other differentiator in the path names?

commented

Maybe we should add some sort of thing to the contract names created by each user to make them and their paths more unique, like appending the date to whatever they choose or something like that. I just worry that since this will make deploying a contract way easier, lots of users are going to not think critically about their contract names and that will create tons of conflicts.

commented

I'm hesitant to add an auto-generated values to the contract name -- I feel like that's something the user should have full control over. Getting an NFT project onto mainnet requires them to integrate with the catalog and wallets, at which point they'd hopefully become aware of any conflicts. And contracts always have their fully-qualified type ID, which includes the contract address.

But I could see conflicting storage paths causing real problems. Maybe we could hash the metadata field types and append the last few bytes (i.e. f56ac4) on each storage path -- sort of as a deterministic version identifier.

commented

Thats a good point about the contract names, but yeah we should do something like that for the paths