Adding an author / minter to the NFT MetadataViews

[bymi15]

Instructions

Issue To Be Solved

Currently in the MetadataViews there isn't a clear way of representing the Author or Original Minter of the NFT. However, this is an essential attribute for all NFTs and can commonly be seen in most marketplaces.

Suggest A Solution

Discussion was raised in: https://discord.com/channels/613813861610684416/1007006779135250433/1013671709041233950 where @bjartek suggested two potential solutions:

1. Adding a new displayType in Traits view that could be called User or Author or Creator
2. Creating a new semantic view called Author or Creator which could have an address field to specify the user's wallet address (and maybe some other optional fields such as name)

[bjartek]

I tend to prefer semantics views myself. Could this be a "person/user" style view that you can give a role to?

[bymi15]

@bjartek I agree with you. There could also be multiple options here depending on how much flexibility we want. a) a more generic Person / User style view with a role (e.g. artist, creator, etc) as you suggested b) a Users view that would be an array of the above, allowing an NFT to have multiple user/stakeholder types and values c) a simple Creator view that would have name, wallet address, type, etc

I think option c) would be easiest for immediate usage and integration whereas option a) and b) may require some more planning/guidance on what the common use cases would be and what user types would be needed.

[joshuahannan]

I don't really have much preference here. Feel free to post a proposal for what you want the view to look like and we can discuss it!

[bymi15]

I think we could go for a generic Users view but having a UserType enum to specify the type of a user. Enumerations seem good to me as we can always add more user types to the end of an enum and be able to update the contract according to: https://developers.flow.com/cadence/language/contract-updatability#enums

Currently I can think of two user types:

    pub enum UserType: UInt8 {
        pub case MINTER
        pub case AUTHOR
    }

MINTER would be the user who minted the NFT AUTHOR would be the user who 'created' the NFT artwork / media

and we could also have a Users view which would be similar to Medias view but have a list of User structs.

A User struct could look like:

pub struct User {

        pub let name: String?
        pub let email: String?
        pub let type: UserType
        pub let walletAddress: Address
        

        init(name: String?, email: String?, type: UserType, walletAddress: Address) {
          self.name=name
          self.email=email
          self.type=type
          self.walletAddress=walletAddress
        }
}

Any suggestions / feedback would be highly appreciated.

[joshuahannan]

This is starting to get awfully close to an identity specification, which a lot of people have a lot of very strong feelings about, so it makes me a little nervous trying to include all this information about someone on-chain right now before we've done a lot of research about it. I'll try to share this around to see if some other people can give feedback

[bymi15]

Perhaps we could remove the PII (Personal Identifiable Information) and just include the bare minimum: type and walletAddress. Because that information should already technically be available on chain, but I guess having this view would make it easier / more accessible.

[ph0ph0]

I prefer the idea of having the PII removed as @bymi15 suggested. Would it be worth also having an optional description?

pub struct User {

        pub let type: UserType
        pub let walletAddress: Address
        pub let description: String?
        

        init(type: UserType, walletAddress: Address, description: String?) {
          self.type = type
          self.walletAddress = walletAddress
          self.description = description
        }
}

An NFT may have multiple authors. Adding a description could add some clarity on their roles. For example, our NFTs at The Fabricant would have a single minter, but an author to represent the garment designer, and another author to represent the material designer.

[bymi15]

@ph0ph0 That sounds like a good idea to have an optional description. The example usecase you explained makes sense, so the UserType struct may not be a specific enough representation and having the description field would allow you to specify the role description.

[bjartek]

Personally i would prefer type to be a string. Why restrict it to something that we think of now?

[bymi15]

@bjartek I was thinking that a string might be too generic and we might want to have a more clearly defined set of types, which is why I suggested UserType to be an enum so that it's not too restricted, as new types can be added to enums without breaking the contract updatability rules. I guess it would also make it easier for the nft contracts implementing this view as they don't need to think of what value to insert as the user type and they can simply choose the most appropriate one from the enum or they can request for a new user type to be added.

[bjartek]

Why does the UserType matter that much? For me this is just a description of what the user is, and me not allowing to use a description string here will just make this view loose its purpose. If i need to enter a discussion and change a cadence contract if I want a Curator type or Co-Author role or whatever kind of role that we do not think about now beforehand.

[bymi15]

I see your point - we can just have an optional description field as previously discussed and remove the UserType field. So that would make it a simple view:

pub struct User {

        pub let walletAddress: Address
        pub let description: String?

        init(walletAddress: Address, description: String?) {
          self.walletAddress = walletAddress
          self.description = description
        }
}

How does this look?