Why aren't catalog keys generated using the contract name and address?

[cybercent]

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:

Address: 0x0b2a3299cc857e29
Contract: TopShot
Resource: NFT

So the key would be

Key:  0b2a3299cc857e29_TopShot_NFT

[bshahid331]

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.

[cybercent]

Multiple NFT collections implemented in the same contract would have a different resource names, the NFT in my example.

It is possible to create multiple distinct "collection" catalog entries that share the same NFT Contract.

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.

[bshahid331]

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