-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Why aren't catalog keys generated using the contract name and address? #121
Comments
We have refrained from pursuing this approach due to the unfortunate circumstance that certain "NFT Contracts" may house multiple "NFT Collections", making a one-to-one correspondence unfeasible. Although this approach is not ideal for NFT design, we have intentionally avoided restricting users to a single implementation approach. It is possible to create multiple distinct "collection" catalog entries that share the same NFT Contract. In fact, we leverage the metadata field labeled "Collection Display Name" to discern which "collection" a given NFT pertains to in cases where multiple collections exist within a single contract. |
Multiple NFT collections implemented in the same contract would have a different resource names, the
This appears to be a very bad design decision, unless the scope of the NFT catalog is to display all NFTs in a user's account, regardless of how many paths for the same collection that user created. |
I'm talking about the occurence where they use the same resource/NFT. I agree it is a poor design design and not how I would design it personally but we have to support it as it's used |
Currently, the catalog keys appear to be generated by the user.
It is difficult to obtain information about a contract without the key.
The only way to get the key for a contract in the current implementation appears to be to loop through the entire catalog at once or in batches and compare contract name and address.
A simpler approach would have been to generate the key from the contract name.
Example for TopShot:
So the key would be
The text was updated successfully, but these errors were encountered: