MetadataViews over complexify previous design about flow-nft

[bluesign]

@cybercent ok but this is not per view type, it is MetadataViews.ResolverCollection for all view types.

But the reason for this is, MetadataViews standard came after NonFungibleToken. And as new NFT standard is on the way, updating old one didn't make sense. Otherwise we could do something like :

resource interface NonFungibleToken.Collection : MetadataViews.ResolverCollection

In the new standard it is roughly like below, it is even more embedded. [0]

 pub resource interface NFT {
        // We also don’t want to restrict how an NFT defines its ID
        // They can store it, compute it, or use the UUID
        pub fun getID(): UInt64

        // Two functions for the NFT Metadata Standard
        pub fun getViews() : [Type]
        pub fun resolveView(_ view:Type): AnyStruct?
    }

It is a bit transition period in my opinion.

For the second part, design decision there is making a custom view or implementing some other standard view is decision left to developer.

As such for example viv3 can request from dapps to implement a viv3Display view or can use standard display view in the standard. But slowly standard views are getting added everyday too, it is still very young,

[0] https://forum.onflow.org/t/streamlined-token-standards-proposal/3075/9

[bjartek]

Based on your experience @cybercent I see where you have doubts about this. But I would argue that the metadata standard has a lot of merrit.

Intention

The intention was never that each provider should defined their own views that should be used for interop against consumers. The intention was that there should be standardized views that the community agree upon that providers can then implement to expose their contracts to the functionality that consumers provide.

Another aspect that was always intended was that NFT.CP should have get getViewsand resolveView methods. And that they should be default implemented to return empty values. This way all existing links that link against NFT.CP should just work.

Status

The status so far is that the PR for default implementaion is done and awaiting review and merge thanks to @bluesign

• onflow/cadence#1076

There are many views that are already present in MetadataViews (https://github.com/onflow/flow-nft/blob/master/contracts/MetadataViews.cdc) such as

• Display
• Royalties/Royalty
• ExternalView
• File
• Media
• License
• NFTCollectionData

And there are many more that are beeing worked on like

• Edition
• NFTView (That will compose the above to generate what alchemy need for their API)
• Tags/Attributes
• Serials
• Rarity
• Listing (for signaling that something is listed at a marketplace, like viv3)

[bluesign]

When a Dapp, needs to setup a new account to be used with a specific contract, that Dapp needs to setup the new account with all the views that were defined in the contract otherwise the metadata exposed by those views will not be available

can you give an example to this? This feels like wrong conclusion

[cybercent]

Hi @bluesign

Here is a concrete example.

The Flovatar contract implements the previous NFT metadata standard:
https://flowscan.org/contract/A.921ea449dffec68a.Flovatar/overview

This CollectionPublic interface defined in the contract needs to be linked on a new account in order for that account to allow the reading of metadata.

pub resource interface CollectionPublic { .. }

A new user that acquires a Flovatar would have this link created by the marketplace or wallet that managed the purchase.
Once linked, metadata can be read by executing methods defined in the interface.

The BarterYardClub contract implements the new MetadataViews standard:
https://flowscan.org/contract/A.28abb9f291cadaf2.BarterYardClubWerewolf/overview

The contract does not have an interface but exposes data using Views.
So when setting up a new account the marketplace or wallet would need to link the NonFungibleToken.CollectionPublic and the MetadataViews.ResolverCollection:

signer.link<&BarterYardClubWerewolf.Collection{NonFungibleToken.CollectionPublic, MetadataViews.ResolverCollection}>
            (BarterYardClubWerewolf.CollectionPublicPath, target: BarterYardClubWerewolf.CollectionStoragePath)

to finally have access to the same data as the first example.

Given that the second contract uses a custom view CompleteDisplay one would still need to look over all the fields defined in the view and create a custom connector that would first get the view and then get the same data by calling the custom fields.

So IMO there is additional complexity both in creating the contract code to define views and the code needed on the connector to read from views while one could just read the public methods.