NFT Token Discovery — Metadata
The defining characteristic of Ethereum ERC-721 NFT’s is the “metadata” string in their definition. This metadata field is used primarily to define what the token ‘is’ and is available via a standardized JSON format. The JSON is not stored inside the Ethereum contract (as that would be too expensive) but rather as a URI (Universal Resource Identifier) string which points to where a user can find the JSON description about the token.
{
"title": "Asset Metadata",
"type": "object",
"properties": {
"name": {
"type": "string",
"description": "Identifies the asset to which this NFT represents",
},
"description": {
"type": "string",
"description": "Describes the asset to which this NFT represents",
},
"image": {
"type": "string",
"description": "A URI pointing to a resource with mime type image/* representing the asset to which this NFT represents. Consider making any images at a width between 320 and 1080 pixels and aspect ratio between 1.91:1 and 4:5 inclusive.",
}
}
}The JSON metadata standard at the moment is designed generally only to solve the issues of identifying the asset, and it doesn’t really tell us very in-depth information beyond the bare minimum required. Also, this information isn’t exactly “searchable” or readable by other smart contracts. This is a somewhat natural network-limitation of Ethereum, but it quickly becomes a bit of a problem. It also is created by the token minters- the owner of the NFT contract, but it’s not user-updatable.
A quick trip to https://opensea.io/assets/cryptokitties reveals more CryptoKitties for sale than you could shake a stick at. Nearly 800,000k if Opeansea’s stats are accurate. (EDIT: there are about 800,000K cats in existence, Opeansea’s for-sale count for the moment seems a bit inaccurate but will reach out to them).
The only method for searching your next Kitty purchase on Opensea is by Gene type, which also gives an overwhelmingly long list. It’s only once you start to narrow down the the list of characteristics by eight points do you get a selection of cats for sale that your browser can reasonably manage to display.
While the CryptoKitty “dna” is rather simple and much of the heavy lifting for the service is done via a centralized API, one can imagine that if you were building a tool to discover cool new NFT tokens, the task of token discovery via Metadata quickly becomes impossible. The current Kitty database assumes that users are searching for Kitties on rather vague “Cattributes” rather than with any definite idea of what strikes their fancy. Put another way- it’s easy-ish to search for EXACTLY what you’re looking for, but it’s near impossible for what you’re looking to buy, to find you.
A good example of this is #Hashtags on social media. Hashtags as applied to cryptoKitties might look something like “#cute #ugly #lovestoparty”. This would give users the ability to explore the market and an opportunity to find what they didn’t know they were looking for in the first place. While CryptoKitties might not be the best example of this (Cattributes are a fairly straight forward process if you know what you want), it’s really hard to find cats that a) don’t appear high up in searches b) have attributes that you’re not sure about. In our NFT future where there are thousands or maybe millions of different types of NFT’s for sale, this quickly becomes a problem. What sort of discovery mechanism will exist for those markets? Will markets need to custom build a search interface for every NFT token?
Composable Hashtags
One idea might be to use Matt Lockyer’s “Composable” NFT tokens to track hashtags and other user generated descriptive metadata. They could be minted, assigned and destroyed at will. They also could provide a useful interface for searching across the entire eco-system of NFT’s. The downside being that they could be rather expensive hashtags in terms of gas cost if not implemented carefully.
ERC-20 Hashtags
A similar idea could be the use of ERC-20 tokens to represent hashtags- where users can freely “mint” new hashtags and a token represents one term or value. A “lookup” process would be to then check the token balances of the NFT contract address to see what hashtag-tokens were owned by that address. An obvious initial drawback however is again discovery: users will need to know the contract address of the ERC-20 token in advance. Unknown hashtags are unknown contracts. So in a sense we potentially just repeat our discovery problem if we don’t somehow also keep a database of existing hashtags. Perhaps as a process of creating a hashtag-token, the contract address is also registered in a global mapping.
Global Mappings
Another idea could be to host somewhere a global database of Hashtag metadata and a global mapping of Tokens -> Hashtags and vice-versa. There is a simplicity to simply keeping one ginormous database of all mappings. If the database were a standard could go a long way to helping NFT discovery problems.
In general, discovery tools are going to become more and more important as the NFT space expands. Indeed there might end up being Oracle services that provide industry specific discovery tools as a service. It doesn’t seem unreasonable to think that it might be far more reasonable to do NFT discovery via external blockchain analysis and then piping that data back to the blockchain in smart-contract readable format. Indeed CryptoKitties itself provides an API to retrieve kitty information in a simple-for-web-app way.
Stay tuned…..
If your not yet familiar with the Crypto Composable idea:
