Replies: 5 comments 5 replies
-
To further clarify the proposal and this point specifically. I think we need to remove a majority of the current TokenMetadata fields that are mentioned by the standard, even if they are optional. Because right now if we want to use TokenMetadata from https://github.com/near/near-sdk-rs/tree/master/near-contract-standards we simply have to provide None (a lot). I think it's in our best interest to implement a standard that's minimal in nature e.g. only requiring To the point about what Anyone can add extra fields or structs to their token, and return an "output" struct that satisfies a much more minimum set of standard metadata, with custom fields. Summary: I believe the standard and any "standard implementations" reduce TokenMetadata to it's absolute minimum the community agrees on from this discussion. |
Beta Was this translation helpful? Give feedback.
-
Thanks for @mattlockyer and @BenKurrek for starting this discussion. What you propose @BenKurrek, I've been told, closely resembles how Ethereum stores theirs onchain. I've read through the history of how this Before I read through the history, hearing how your proposal closely resembles ERC721 made me question why NEAR So even though apps may not use most I wasn't in any discussion where similar solutions were proposed or privy to primary disagreements of this standard. However, I'm aware different NFT marketplace dApps created their Hence it appears to be an offchain compliance issue not onchain. Whatever is taken out of the chain, is in another jurisdiction so compliance can't be enforced. However, storing offchain metadata is a common practice so what I propose is a new field called type TokenMetadata = {
metadata_type: string|null // new. "arweave" | "ipfs" | null
title: string|null, // ex. "Arch Nemesis: Mail Carrier" or "Parcel #5055"
description: string | null, // free-form description
media: string | null, // URL to associated media, preferably to decentralized, content-addressed storage
media_hash: string | null, // Base64-encoded sha256 hash of content referenced by the `media` field. Required if `media` is included.
copies: number | null, // number of copies of this set of metadata in existence when token was minted.
issued_at: string | null, // When token was issued or minted, Unix epoch in milliseconds
expires_at: string | null, // When token expires, Unix epoch in milliseconds
starts_at: string | null, // When token starts being valid, Unix epoch in milliseconds
updated_at: string | null, // When token was last updated, Unix epoch in milliseconds
extra: string | null, // anything extra the NFT wants to store on-chain. Can be stringified JSON.
reference: string | null, // URL to an off-chain JSON file with more info.
reference_hash: string | null // Base64-encoded sha256 hash of JSON from reference field. Required if `reference` is included.
} This way we are not removing the possibilities to enrich NFTs with onchain metadata vs. keeping everything useful offchain. I also propose that for a consistent consumer experience, offchain metadata should at least agree on few required fields - the rest can be dApp specific. Let's keep the standard flexible, as NEAR is itself more flexible than others, so dApps that take advantage of this are not left out. I was due to make a pr for this but didn't finish, I'll mention this for reference. |
Beta Was this translation helpful? Give feedback.
-
@evergreen-trading-systems comment sums up our internal discussions over the past weeks. My question is: should we standardize what @mattlockyer mentioned CAIPs on one of the recent meetings. Is anyone aware of something similar to this for decentralized filestorage systems? |
Beta Was this translation helpful? Give feedback.
-
Thanks @mattlockyer and @BenKurrek for sharing your concerns about costs for transacting large amount of tokens. It is a valid point and I was curious to further understand these implications in detail. To that end, I simulated the scenario of storing 1 million tokens using optional and non-optional metadata. The results can be found here - https://github.com/evergreen-trading-systems/mint-million-tokens In a nutshell, there are significant savings to be had. I agree that large scale dApps that want to utilise these advantages shouldn't be forced to store data in an unnecessary format. @chadoh proposed the current metadata standard, would be good to hear an opinion. Regardless, I think it's clear to everyone the benefits to be had. Based on this, if the current standard were made optional for dApps who want to utilise onchain metadata, it applies the rest would be queried offchain. This is where the I'm not an expert on offchain storage but I understand given a To sum it up // Offchain only token - storage efficient
Token {
metadata:None,
reference_hash: Some("123"),
..Default::default()
}
// Onchain only token - less efficient
Token {
metadata:Some(TokenMetadata::default()),
reference_hash:None,
..Default::default()
}
// Off and on chain token - least efficient
Token {
metadata:Some(TokenMetadata::default()),
reference_hash:Some("123"),
..Default::default()
} Other metadata fields like Token {
TokenMetadata {
name:"",
copies:1,
reference_hash:Some("123"),
extra:None,
}
..Default::default()
} |
Beta Was this translation helpful? Give feedback.
-
I agree we should come to a consensus on what's reasonable to cut from the TokenMetadata. I'm finding myself thinking how strange it is to fit this into "versions." I don't want to complicate things too much, but I think a lot of discussion is around art.
Speaking to that last bullet point, I think there are useful reasons for folks to have on-chain metadata that hasn't been mentioned yet, and perhaps this is because we're sharing an assumption that a marketplace frontend somewhere will have no problem fetching info from decentralized storage since the end user is already in a browser. That doesn't cover a fully, on-chain workflow, however, so let's just keep that in mind. But more to the point, perhaps what we're looking for aren't "versions" of the NFT Token Metadata but variants. Like:
|
Beta Was this translation helpful? Give feedback.
-
After discussions with @mattlockyer, we wanted to bring to the table potential updates to the NFT TokenMetadata.
Currently, the TokenMetadata might have too many unused fields and could be reduced. Most projects are going to use some decentralized storage to link to an off-chain JSON file that describes the metadata for their tokens.
It seems like we just need a few small things so we can have NFTs that basically state: "I'm not using TokenMetadata and my data is off-chain"
Approximately:
NFT ContractMetadata
NFT Standard / Implementation
Then you can have NFTs that follow the existing patterns AND lightweight NFTs that don't use TokenMetdata but instead have:
NFT ContractMetadata
- base_uri
Token
- reference
Where base_uri + reference = full URI to off-chain metadata. This would be a simple bump to the Metadata to include platforms that have stored JSON off-chain and allow for projects to avoid using the TokenMetadata (because it's cumbersome and no one seems to use it anyway).
To outline the proposal more directly --> currently we've got TokenMetadata which has:
The problem with this model is that not a lot of people are using all the fields. We propose lighter weight metadata which includes:
Where reference is combined with the base_uri (from NFT contract metadata) that points to information off-chain. This off-chain metadata would need to conform to a standard so that it shows up in the wallet correctly and isn't in a disorderly format.
When you query for token information, it would send back information from TokenMetadata, LightTokenMetadata, or if the token implements both, it would send back TokenMetadata and LightTokenMetadata.
The user has the option to pick either the TokenMetadata or the LightTokenMetadata (which includes the possibility for both).
Beta Was this translation helpful? Give feedback.
All reactions