Additions: nft_holder to get the holder of token; nft_token_metadata and nft_token_uri to get token metadata

[thor314]

Justification for additions:

The present core and metadata standard are inflexible. They assume that nft_token, which gets all information about a token, will correctly obtain data that may require more complexity than a simple lookup.

Obtaining information about

1. Who holds the token
2. What metadata content is related to the token

are likely to be some of the most commonly used operations on NFT contracts, and should be formalized so that they may be built upon reliably in the NFT contract ecosystem.

[mattlockyer]

Can you elaborate where this will be used? Conceptually?

[thor314]

nft_holder creates room for complexity to be built around not only "owning" tokens, but also "loaning" or "composing" ownership. In essence, the whole value of an NFT is these exact kinds of games around "who owns this token".

the metadata methods are targets for getting information about the metadata of the token, and the location of the decentralized storage platform. Getting metadata info is also pretty central to what an NFT is/does, and inclusion of these methods makes life easier for front ends querying NFT contracts for data.

[chadoh]

Do I understand correctly that this would essentially return NFTContractMetadata.base_uri + TokenMetadata.reference?

If that's true, this is essentially a shortcut to get reference. Should we call it nft_token_reference instead of nft_token_uri?

[chadoh]

I think we should probably bump the spec to nft-1.1.0, since this is a new backwards-compatible feature

[chadoh]

See my feedback above. Feel free to contest my requests; I could be easily persuaded that this should be merged as-is.

[frol]

@thor314 We are bringing NEPs up to speed. Are you still up to getting this NEP discussed and potentially merging it?

[thor314]

I think I'm a bit far moved on to push this. If there are outstanding questions, I would be able to hop on a call, but I haven't been looking in this direction for some time now.

[frol]

In order to move forward, we should clearly define:

• Who will benefit from this NEP? (there are a bunch of NFT contracts, marketplaces, and connecting dApps, and I don't see them here asking for these methods to be standardized)
• What are the risks of introducing new methods? (will it actually improve things or only make it worse since some contracts will have this support while others won't)
• Who is up to implementing these methods in the tooling?
• Who is up to highlighting them in the tutorials/documentation?

If nobody is ready to champion it, we may put it in a box for now until someone needs it and is ready to contribute their time to finish the NEP and implement it in the SDKs.

@near/wg-contract-standards Given that NEP process has two outcomes: Approved or Rejected, I see this NEP going in the direction to be Rejected due to the lack of capacity/interest from the community. We can re-open / fork rejected NEPs once it is the right time. I want to nominate this NEP to be discussed in the upcoming working group call.

[thor314]

Who will benefit from this NEP? (there are a bunch of NFT contracts, marketplaces, and connecting dApps, and I don't see them here asking for these methods to be standardized)

At the time, I was working with mintbase. I was under the understanding that these methods would make for a minimal flexible standard in obtaining NFT metadata, which could be composed with other NFT applications.

What are the risks of introducing new methods? (will it actually improve things or only make it worse since some contracts will have this support while others won't)

The risk of introducing these methods this late in the NFT ecosystem, as opposed to when they were submitted likely outweighs the benefits, especially since it appears there has not been community demand for this use-case, as you mentioned.

If nobody is ready to champion it, we may put it in a box for now until someone needs it and is ready to contribute their time to finish the NEP and implement it in the SDKs.

That seems appropriate.

[ori-near]

As a moderator, I am closing this NEP given the concerns that @frol mentioned above and confirmation from the author. If anyone is interested in addressing the concerns above, please submit a new NEP.