Introduction
m-NFT is an active NFT draft standard adopted by serveral community driven products and teams on Nervos CKB. NFT as a social token, it shouldn’t be static and single direction. Imagine a dynamic NFT that allows holder interact with the issuer and other holders together to form a much wider conception and boarder of NFT.
Lots of dynamic interaction NFT products have been observed, such as PixEOS, Open Satoshi, async.art, and so on. However, there is little progress on the standard of the dynamic interaction interfaces and parameters. Without the specific standard, the third-party wallets and explorers cannot access and render the NFTs correctly, and thus cannot provide the same user experience as the native applications.
Here we propose a dynamic interaction standard to greatly extend the capabilities of m-NFT to build game based NFT, multiplayer cooperation art, generative art, social experiments and other community involved works. With this standard, wallets and other applications could easily access the m-NFTs to provide various user actions and expressions.
Dynamic Part
It’s still a controversial question that whether the multimedia information of an NFT should be mutable or changed under some conditions. Since the Blockchain world is so unpredictable, and new technology new thoughts are jumping out day by day, we’ve decided not to dig too much on this question. But instead, we choose to empower m-NFTs the capability of more expressive force to make them more powerful.
Every m-NFT has a renderer field to set an image, video, sound or other media to show. It could be any type of URI including centralized URL, decentralized ipfs address, and so on. The dynamic part idea is simple, that the display layer provides various context parameters to the URI to indicate it return mutable content respectively. The context parameters could include the token’s issuing index, holder’s address, holding time, epoch number, distribution uniformity, turnover count, and so on.
| var | format | description |
|---|---|---|
| tid | integer | token index under same NFT class |
| holdsec | integer | holding time (UTXO live length in seconds) |
| char | hex | NFT characteristic bytes |
| state | hex | NFT state byte |
| configure | hex | NFT configure byte |
| subset | string | subset description defined in extinfo_data, optional |
With these context parameters, we could create a changing outlook to every NFT that has already been distributed. And this will release great possibilities, such as a living pet image chaging according to the holding period.
Interaction Part
Since one of the key features of NFT is the social property, it’s very important to take the NFT holders’ interaction into consideration when we design the protocols. There is a 8-bytes characteristic attribute in m-NFT protocol for user feedback or interaction to the issuer or other holders. By default, holders could change this parameter into any bytes as their will. So users could set different characteristic data to communicate their ideas with each other.
For example, if we explain the first two bytes of characteristic as the ISO Alpha-2 country code, and the third byte as the light status. Every holder could set their favorite country and ignite a light for her. With all such data collected on-chain, we could generate a dynamic global light map flowing with NFT holder’s changing choices.
Sometimes, the 8-byte characteristic is not enough for some action description, like avatar shaping. And sometimes the issuer wanna restrict the holder’s action in a small scope. So we introduce extinfo_data to make the interaction part even more powerful. First of all, we set the first extinfo_data field into json string as convention, and it contains the following variables.
| var | present | value | description |
|---|---|---|---|
"id" |
must | "ce" |
identity bytes for characteristic extension |
"vs" |
optional | string |
subset description for characteristic, such as “face”, “location”, … |
"va" |
optional | hex for 8byte shield | set characteristic = characteristic & va
|
"vo" |
optional | hex for 8byte shield | set characteristic = characteristic | vo
|
The id attribute is used to tell how it should be interpreted by applications. The vs attribute means what exactly the characteristic is describing. For example, if we mint 10k “crypto avatar” NFTs, and 1k of them are set "vs" = "face", 1k of them are set "vs" = "body", …, the rest of them are set "vs" = "ornament". The NFTs are now have much more expressive force than before, because we have separately characteristic field to describe different details for one NFT. The va and vo bytes are set to constrain the users interaction bits. We could mint an avatar NFT with face shaping capability, but the holder could only modify the eyebrow, while other traits are pre-defined and fixed.
// valid extinfo_data examples
{
"id" : "ce",
"vs" : "nose",
"va" : "ffff00000000000000",
"vo" : "000018000000000000"
}
{
"id" : "ce",
"va" : "ffff00000000000000"
}
{
// empty is also valid
}
Finally, the application will parse the extinfo_data field, calculate c = (c & va) | vo, where c means characteristic, then pass characteristic and subset (set to vs) to the renderer URI.
Conclusion
With the dynamic interaction extension, we could make NFTs more social, playable, and unpredictable. Looking forward to the numerous possibilities emerging in the near future.