-
Notifications
You must be signed in to change notification settings - Fork 319
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CIP-0048? | NFT metadata references and payloads #249
Changes from 1 commit
05f7c34
01bce73
a2fe0d4
c476add
3d1b4f4
c41d545
56bcda6
07d87d1
c1988c3
91ce437
2706144
921e8eb
fe506e1
d8d5a30
2e7420a
827ca7b
450812c
fc06058
6c9bada
2465815
594400b
aec50fc
09b3b10
54b0c63
bc0906a
dc16d71
b7c36ac
e4a6509
2364e8a
edf147b
4911949
b99a0aa
c0d2aee
7bf0859
11eedf3
404279a
7480cce
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
- Loading branch information
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,81 @@ | ||
--- | ||
CIP: 48? | ||
Title: Extended 721 metadata | ||
Authors: Jack (Pixel pool, https://forum.cardano.org/u/jack7e/, @pixel_pool twitter) | ||
Comments-URI: | ||
Status: Draft | ||
Type: Informational | ||
Created: 2022-04-21 | ||
--- | ||
|
||
# Abstract | ||
This standard proposes a fully on chain method to store and access metadata via the use of references or pointers to data. | ||
This would allow users of 721 to increase or reduce the amount of data stored on chain. | ||
|
||
# Motivation | ||
- Large token mints that duplicated data could be dramatically reduced in size by pointing to one transaction payload that contains a ‘boilerplate’ structure. | ||
- 16kB is the upper limit of data in each transaction but If a user wanted more there is no alternative than to store that data off-chain using an external service such as ipfs. | ||
- The use of pointers to data is an extremely powerful tool. For example If a pointer, pointed to pointers you could soon minic something like the ext2 filesystem fully on chain. | ||
- The aforementioned is all currently possible but there is no informational standard. | ||
This CIP aims to describe is a standard so that if a user does want to reduce or increase there metadata size it can be queried by 3rd parties that look for the version 2 tag attached within the 721 metadatum transaction label | ||
|
||
|
||
Specifically, this proposal aims to solve for the following: | ||
|
||
* Provide a mechanism to reduce duplicated metadata into one or multiple transactions that can be referenced | ||
* Provide a mechanism that allows on chain data to be referenced | ||
* Provide a mechanism to reference on chain data in a set order | ||
|
||
# Specification | ||
|reserved 721 metadata tag |description| notes | | ||
|---|---| --- | | ||
|references | contains pointers to data |The could be called 'r' or 'refs' reduced size | | ||
|payload? or data? | contains raw data | This could be called 'data' or 'd' | | ||
|version| this is described in 721 | not sure if it should be version 1.1? instead of 2| | ||
``` | ||
{ | ||
"721":{ | ||
"<POLICY_ID>":{ | ||
"<NFT_NAME_B16>":{ | ||
"project":"<PROJECT>", | ||
"name":"<NFT_NAME>", | ||
"references":{ | ||
"mediaType":"text/plain", | ||
"src":[ | ||
0, | ||
1 | ||
] | ||
} | ||
}, | ||
"payload":{ | ||
"0":"Hello ", | ||
"1":"World!" | ||
}, | ||
"version":"2.0" | ||
} | ||
} | ||
} | ||
``` | ||
# retrieve payload information using references | ||
1. Find all transactions with the 721 label | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What is the scope of research here? A block? The whole chain? Should only payload under the same policy be considered? |
||
2. Check the version tag | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What should the version tag be? |
||
3. If a payload is found append that to an map or some data structure | ||
4. Given a nft find there references | ||
5. Concatenate the data for all given references | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. How is "concatenate" defined here? What if the data isn't text or bytes? |
||
|
||
In example | ||
``` | ||
nft 0 has the payload ["0":""Hello","1":"World"] and the references [0,1] | ||
nft 0 == "HELLOWORLD" | ||
``` | ||
``` | ||
nft 1 has no payload and the references [0] | ||
nft 1 == "HELLO" | ||
``` | ||
``` | ||
nft 2 has no payload and the references [1,0] (note the order) | ||
nft 2 == "WORLDHELLO" | ||
``` | ||
|
||
# backwards compatibility | ||
Used the version tag described |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since this is an optional extension of the standard, it wouldn't make sense to use the same versioning scheme as CIP-0025 because there might be other proposed extensions which either conflict or are simply used in total separation from this one. Say we have two mutually exclusive extensions for CIP-0025 with versions
2.1
and2.2
. Now, shouldn't2.2
implies that2.1
is also used? What if, no, people just want to use2.1
?I think CIP-0025 lacks extensibility mechanisms; something that can let new extensions be specified in an additive manner (e.g. an extra field
extensions: ['CIP-0048']
).