From 05f7c3479de568d83d8db4582b2cb3ae3c55067b Mon Sep 17 00:00:00 2001 From: Jack Date: Thu, 21 Apr 2022 20:10:59 +0100 Subject: [PATCH 01/35] Introducing CIP-0048? Extended 721 metadata --- CIP-0048/CIP-0048.md | 81 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 81 insertions(+) create mode 100644 CIP-0048/CIP-0048.md diff --git a/CIP-0048/CIP-0048.md b/CIP-0048/CIP-0048.md new file mode 100644 index 000000000..18f3c4f38 --- /dev/null +++ b/CIP-0048/CIP-0048.md @@ -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":{ + "":{ + "":{ + "project":"", + "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 +2. Check the version tag +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 + +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 From 01bce73cc7bb0ece78a71c01f819b7686b20bf46 Mon Sep 17 00:00:00 2001 From: Jack Date: Thu, 21 Apr 2022 20:11:55 +0100 Subject: [PATCH 02/35] added forum post --- CIP-0048/CIP-0048.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CIP-0048/CIP-0048.md b/CIP-0048/CIP-0048.md index 18f3c4f38..2e0717fbf 100644 --- a/CIP-0048/CIP-0048.md +++ b/CIP-0048/CIP-0048.md @@ -2,7 +2,7 @@ CIP: 48? Title: Extended 721 metadata Authors: Jack (Pixel pool, https://forum.cardano.org/u/jack7e/, @pixel_pool twitter) -Comments-URI: +Comments-URI: https://forum.cardano.org/t/cip-extended-721/ Status: Draft Type: Informational Created: 2022-04-21 From a2fe0d44f8616f620602b199b0347b37812a99f4 Mon Sep 17 00:00:00 2001 From: Jack Date: Thu, 21 Apr 2022 20:32:46 +0100 Subject: [PATCH 03/35] amendments to specification reserved keywords --- CIP-0048/CIP-0048.md | 33 +++++++++++++++++++++++++-------- 1 file changed, 25 insertions(+), 8 deletions(-) diff --git a/CIP-0048/CIP-0048.md b/CIP-0048/CIP-0048.md index 2e0717fbf..fd1f53029 100644 --- a/CIP-0048/CIP-0048.md +++ b/CIP-0048/CIP-0048.md @@ -27,11 +27,17 @@ Specifically, this proposal aims to solve for the following: * Provide a mechanism to reference on chain data in a set order # Specification -|reserved 721 metadata tag |description| notes | +|reserved 721 metadata tag |description | example |---|---| --- | -|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' | +|references, refs, r | contains data tag and src tag | ```'r':{"data:"text/plain","src":[0,1]}```| +|payload, p | contains raw data | ```'p':{ "0":["h","e","l","l","o"], "1":"world" }``` | |version| this is described in 721 | not sure if it should be version 1.1? instead of 2| +|data| contains the data type MIME | for example if base 64, data:"text/plain;base64"| +|src|contains a list of poitners to payloads | ```"src":[0,1]``` or ``` "src":["payload0","payload1"]```| + + +*Please note I offer optional single char names to allow futher reduction in metadata size if desired* + ``` { "721":{ @@ -40,7 +46,7 @@ Specifically, this proposal aims to solve for the following: "project":"", "name":"", "references":{ - "mediaType":"text/plain", + "data":"text/plain" "src":[ 0, 1 @@ -48,10 +54,9 @@ Specifically, this proposal aims to solve for the following: } }, "payload":{ - "0":"Hello ", - "1":"World!" + "0":["Hello"],"1":["World!"] }, - "version":"2.0" + "version":"2" } } } @@ -65,7 +70,7 @@ Specifically, this proposal aims to solve for the following: In example ``` -nft 0 has the payload ["0":""Hello","1":"World"] and the references [0,1] +nft 0 has the payload "p":{"0":""Hello","1":"World" } and the references "r":[0,1] nft 0 == "HELLOWORLD" ``` ``` @@ -79,3 +84,15 @@ nft 2 == "WORLDHELLO" # backwards compatibility Used the version tag described + +# Further considerations +I believe this needs to be better defined +``` + "references":{ + "mediaType":"text/plain", + "src":[ + 0, + 1 + ] + } +``` From c476add238d779de15df1581ca0ec9c35603c381 Mon Sep 17 00:00:00 2001 From: Jack Date: Thu, 21 Apr 2022 20:48:02 +0100 Subject: [PATCH 04/35] added pseudo code usage example --- CIP-0048/CIP-0048.md | 24 +++++++++++++++++++++++- 1 file changed, 23 insertions(+), 1 deletion(-) diff --git a/CIP-0048/CIP-0048.md b/CIP-0048/CIP-0048.md index fd1f53029..07349e07f 100644 --- a/CIP-0048/CIP-0048.md +++ b/CIP-0048/CIP-0048.md @@ -68,7 +68,7 @@ Specifically, this proposal aims to solve for the following: 4. Given a nft find there references 5. Concatenate the data for all given references -In example +### In example ``` nft 0 has the payload "p":{"0":""Hello","1":"World" } and the references "r":[0,1] nft 0 == "HELLOWORLD" @@ -82,6 +82,28 @@ nft 2 has no payload and the references [1,0] (note the order) nft 2 == "WORLDHELLO" ``` +### pseudo code +for all txs in policy +``` +if metadatum tag is '721' + if 'payload' or 'p' in json['721][] + for payloads in ['721][]['p'] + for refrenceName, data in payload + add data with referencename to datastructure +``` + + +for a given nft +``` +refs = json['721'][][]['references']['src'] +dataType = json['721'][][]['references']['data'] + +for ref in refs + nft data += data from datastrucure indexed with ref +``` + +payload + # backwards compatibility Used the version tag described From 3d1b4f42db4cbebbee9cf1c6bf0d19753bd16b7b Mon Sep 17 00:00:00 2001 From: Jack Date: Thu, 21 Apr 2022 20:55:28 +0100 Subject: [PATCH 05/35] added external keyword --- CIP-0048/CIP-0048.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/CIP-0048/CIP-0048.md b/CIP-0048/CIP-0048.md index 07349e07f..c18104136 100644 --- a/CIP-0048/CIP-0048.md +++ b/CIP-0048/CIP-0048.md @@ -25,15 +25,17 @@ 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 +* Provide a mechanism to reference on chain data stored in a different policy # Specification |reserved 721 metadata tag |description | example |---|---| --- | -|references, refs, r | contains data tag and src tag | ```'r':{"data:"text/plain","src":[0,1]}```| +|references, refs, r | contains data tag and src tag | ```'r':{ "data:"text/plain","src":[0,1] }```| |payload, p | contains raw data | ```'p':{ "0":["h","e","l","l","o"], "1":"world" }``` | |version| this is described in 721 | not sure if it should be version 1.1? instead of 2| |data| contains the data type MIME | for example if base 64, data:"text/plain;base64"| |src|contains a list of poitners to payloads | ```"src":[0,1]``` or ``` "src":["payload0","payload1"]```| +|external | used withing references to references another policy | ```'r':{"data:"text/plain","src":{[0,1]},"external":"}"```| *Please note I offer optional single char names to allow futher reduction in metadata size if desired* From c41d5457a80364fe7e5b62688542de9b9f47fd77 Mon Sep 17 00:00:00 2001 From: Jack Date: Thu, 21 Apr 2022 20:56:02 +0100 Subject: [PATCH 06/35] added external char shortcut --- CIP-0048/CIP-0048.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CIP-0048/CIP-0048.md b/CIP-0048/CIP-0048.md index c18104136..7d57ed912 100644 --- a/CIP-0048/CIP-0048.md +++ b/CIP-0048/CIP-0048.md @@ -35,7 +35,7 @@ Specifically, this proposal aims to solve for the following: |version| this is described in 721 | not sure if it should be version 1.1? instead of 2| |data| contains the data type MIME | for example if base 64, data:"text/plain;base64"| |src|contains a list of poitners to payloads | ```"src":[0,1]``` or ``` "src":["payload0","payload1"]```| -|external | used withing references to references another policy | ```'r':{"data:"text/plain","src":{[0,1]},"external":"}"```| +|external, e | used withing references to references another policy | ```'r':{"data:"text/plain","src":{[0,1]},"external":"}"```| *Please note I offer optional single char names to allow futher reduction in metadata size if desired* From 56bcda64f216e4168041ddab0983ba4670ee2cf0 Mon Sep 17 00:00:00 2001 From: Jack Date: Thu, 21 Apr 2022 21:05:15 +0100 Subject: [PATCH 07/35] added comment on references --- CIP-0048/CIP-0048.md | 15 +++++---------- 1 file changed, 5 insertions(+), 10 deletions(-) diff --git a/CIP-0048/CIP-0048.md b/CIP-0048/CIP-0048.md index 7d57ed912..a34177b15 100644 --- a/CIP-0048/CIP-0048.md +++ b/CIP-0048/CIP-0048.md @@ -110,13 +110,8 @@ payload Used the version tag described # Further considerations -I believe this needs to be better defined -``` - "references":{ - "mediaType":"text/plain", - "src":[ - 0, - 1 - ] - } -``` +If we wanted to add more powerful referencing we could allow for references to references + +```"payload":{"r":{"src":{[98,99]},"external":"}"}}``` + +*Like a block of pointers in the ext2 filesystem* From 07d87d12a1af3cf0d5416f91764a3aeefb0bfd27 Mon Sep 17 00:00:00 2001 From: Jack Date: Thu, 21 Apr 2022 21:08:37 +0100 Subject: [PATCH 08/35] proof read changes --- CIP-0048/CIP-0048.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/CIP-0048/CIP-0048.md b/CIP-0048/CIP-0048.md index a34177b15..912e41979 100644 --- a/CIP-0048/CIP-0048.md +++ b/CIP-0048/CIP-0048.md @@ -85,17 +85,19 @@ nft 2 == "WORLDHELLO" ``` ### pseudo code -for all txs in policy + +to get the metadata from payloads ``` -if metadatum tag is '721' - if 'payload' or 'p' in json['721][] - for payloads in ['721][]['p'] - for refrenceName, data in payload - add data with referencename to datastructure +for each transaction within the policy + if metadatum tag is '721' + if 'payload' or 'p' in json['721][] + for payloads in ['721][]['p'] + for refrenceName, data in payload + add data with referencename to datastructure ``` -for a given nft +to build the metadata for each nft ``` refs = json['721'][][]['references']['src'] dataType = json['721'][][]['references']['data'] @@ -104,8 +106,6 @@ for ref in refs nft data += data from datastrucure indexed with ref ``` -payload - # backwards compatibility Used the version tag described From c1988c30b487303776c1da56ac6ca63e9221ccac Mon Sep 17 00:00:00 2001 From: Jack Date: Sat, 23 Apr 2022 12:55:06 +0100 Subject: [PATCH 09/35] updated CIP-0048.md made the specification section more concise --- CIP-0048/CIP-0048.md | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/CIP-0048/CIP-0048.md b/CIP-0048/CIP-0048.md index 912e41979..b1e299dd5 100644 --- a/CIP-0048/CIP-0048.md +++ b/CIP-0048/CIP-0048.md @@ -28,14 +28,31 @@ Specifically, this proposal aims to solve for the following: * Provide a mechanism to reference on chain data stored in a different policy # Specification +*Inside the 721 metadata tag* |reserved 721 metadata tag |description | example |---|---| --- | |references, refs, r | contains data tag and src tag | ```'r':{ "data:"text/plain","src":[0,1] }```| |payload, p | contains raw data | ```'p':{ "0":["h","e","l","l","o"], "1":"world" }``` | |version| this is described in 721 | not sure if it should be version 1.1? instead of 2| + +*inside the refences tag* +|tags that are reseved inside references |description | example +|---|---| --- | |data| contains the data type MIME | for example if base 64, data:"text/plain;base64"| |src|contains a list of poitners to payloads | ```"src":[0,1]``` or ``` "src":["payload0","payload1"]```| |external, e | used withing references to references another policy | ```'r':{"data:"text/plain","src":{[0,1]},"external":"}"```| +|type | the format/type of the data inside the payload | 'r':{"data:"image/jpeg","src":{[0,1]},"type":"ipfs"| + +*defintion of the different reference types* +| type | desciption | +|---| ---| +|ipfs|data is stored at ipfs| +|url|data is found a url| +|api|data is found at api get request| +|utf-8| data is directly in payload as utf-8 | +|b64 | data is in base 64 encoded in payload | +|reference? | advance feature, points to a reference | +|none| assume data is raw and using the defined media type | *Please note I offer optional single char names to allow futher reduction in metadata size if desired* @@ -48,6 +65,7 @@ Specifically, this proposal aims to solve for the following: "project":"", "name":"", "references":{ + "type":"raw" "data":"text/plain" "src":[ 0, From 91ce437966355e7f02b3283ae3cdd64aa3bbc290 Mon Sep 17 00:00:00 2001 From: Jack Date: Sat, 23 Apr 2022 13:11:22 +0100 Subject: [PATCH 10/35] updated CIP-0048.md to include fallback option --- CIP-0048/CIP-0048.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/CIP-0048/CIP-0048.md b/CIP-0048/CIP-0048.md index b1e299dd5..f3127d60d 100644 --- a/CIP-0048/CIP-0048.md +++ b/CIP-0048/CIP-0048.md @@ -41,7 +41,8 @@ Specifically, this proposal aims to solve for the following: |data| contains the data type MIME | for example if base 64, data:"text/plain;base64"| |src|contains a list of poitners to payloads | ```"src":[0,1]``` or ``` "src":["payload0","payload1"]```| |external, e | used withing references to references another policy | ```'r':{"data:"text/plain","src":{[0,1]},"external":"}"```| -|type | the format/type of the data inside the payload | 'r':{"data:"image/jpeg","src":{[0,1]},"type":"ipfs"| +|type | the format/type of the data inside the payload |```'r':{"data:"image/jpeg","src":{[0,1]},"type":"ipfs"```| +|b, back, backup | fallback, if a link to the data is used in the 'src' tag and is broken revert to a fallback link. | ```'r':{"src":{[0,1]},"b":{[2,3]}} ``` or for multiple fallbacks use ```'r':{"src":{[0,1]},"b":"{'0':{[2,3]}, '1'{[4,5]} }"``` | *defintion of the different reference types* | type | desciption | From 2706144e982fcf74842b5dcd278947af022928f8 Mon Sep 17 00:00:00 2001 From: Jack Date: Sat, 23 Apr 2022 17:04:43 +0100 Subject: [PATCH 11/35] updated CIP-0048.md to include note on duplication --- CIP-0048/CIP-0048.md | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/CIP-0048/CIP-0048.md b/CIP-0048/CIP-0048.md index f3127d60d..7544b0eed 100644 --- a/CIP-0048/CIP-0048.md +++ b/CIP-0048/CIP-0048.md @@ -82,7 +82,7 @@ Specifically, this proposal aims to solve for the following: } } ``` -# retrieve payload information using references +# Retrieve payload information using references 1. Find all transactions with the 721 label 2. Check the version tag 3. If a payload is found append that to an map or some data structure @@ -103,7 +103,7 @@ nft 2 has no payload and the references [1,0] (note the order) nft 2 == "WORLDHELLO" ``` -### pseudo code +### Pseudo code to get the metadata from payloads ``` @@ -125,12 +125,14 @@ for ref in refs nft data += data from datastrucure indexed with ref ``` -# backwards compatibility -Used the version tag described +# Backwards compatibility +Used the version tag described in CIP 25. # Further considerations +### References If we wanted to add more powerful referencing we could allow for references to references - ```"payload":{"r":{"src":{[98,99]},"external":"}"}}``` - *Like a block of pointers in the ext2 filesystem* +### Duplicate data +There could be issues with duplicate payloads. The solution I propose is just to use +the latest version of that payload. From 921e8eb6bf8df1df6445c8f32bdf2f270afc5c9f Mon Sep 17 00:00:00 2001 From: Jack Date: Sat, 23 Apr 2022 21:27:51 +0100 Subject: [PATCH 12/35] added a comment on references --- CIP-0048/CIP-0048.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/CIP-0048/CIP-0048.md b/CIP-0048/CIP-0048.md index 7544b0eed..969292b4b 100644 --- a/CIP-0048/CIP-0048.md +++ b/CIP-0048/CIP-0048.md @@ -28,6 +28,8 @@ Specifically, this proposal aims to solve for the following: * Provide a mechanism to reference on chain data stored in a different policy # Specification +Please note I offer optional single char names to allow futher reduction in metadata size if desired + *Inside the 721 metadata tag* |reserved 721 metadata tag |description | example |---|---| --- | @@ -55,8 +57,8 @@ Specifically, this proposal aims to solve for the following: |reference? | advance feature, points to a reference | |none| assume data is raw and using the defined media type | +*?references in payloads could cause issues with circular dependencies, maybe this should be more like inode in ext2 or the depth defined* -*Please note I offer optional single char names to allow futher reduction in metadata size if desired* ``` { From fe506e1e083b75fda73a9e97ebd326459e0a016e Mon Sep 17 00:00:00 2001 From: Jack Date: Sun, 8 May 2022 11:46:42 +0100 Subject: [PATCH 13/35] updated CIP-0048.md to use policy and txhash policy and txhash replace external --- CIP-0048/CIP-0048.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/CIP-0048/CIP-0048.md b/CIP-0048/CIP-0048.md index 969292b4b..da7debce9 100644 --- a/CIP-0048/CIP-0048.md +++ b/CIP-0048/CIP-0048.md @@ -42,7 +42,8 @@ Please note I offer optional single char names to allow futher reduction in meta |---|---| --- | |data| contains the data type MIME | for example if base 64, data:"text/plain;base64"| |src|contains a list of poitners to payloads | ```"src":[0,1]``` or ``` "src":["payload0","payload1"]```| -|external, e | used withing references to references another policy | ```'r':{"data:"text/plain","src":{[0,1]},"external":"}"```| +|policy, p | used withing references to references another policy | ```'r':{"data:"text/plain","src":{[0,1]},"p":"}"```| +|txhash, tx | used withing references a specific tx hash | ```'r':{"data:"text/plain","src":{[0,1]},"tx":"}"```| |type | the format/type of the data inside the payload |```'r':{"data:"image/jpeg","src":{[0,1]},"type":"ipfs"```| |b, back, backup | fallback, if a link to the data is used in the 'src' tag and is broken revert to a fallback link. | ```'r':{"src":{[0,1]},"b":{[2,3]}} ``` or for multiple fallbacks use ```'r':{"src":{[0,1]},"b":"{'0':{[2,3]}, '1'{[4,5]} }"``` | @@ -133,7 +134,7 @@ Used the version tag described in CIP 25. # Further considerations ### References If we wanted to add more powerful referencing we could allow for references to references -```"payload":{"r":{"src":{[98,99]},"external":"}"}}``` +```"payload":{"r":{"src":{[98,99]},"policy":"}"}}``` *Like a block of pointers in the ext2 filesystem* ### Duplicate data There could be issues with duplicate payloads. The solution I propose is just to use From d8d5a307fa8e01f3dc8cc7f346dbc1f99313b5a5 Mon Sep 17 00:00:00 2001 From: Jack Date: Sun, 8 May 2022 11:49:40 +0100 Subject: [PATCH 14/35] updated CIP-0048.md grammar --- CIP-0048/CIP-0048.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/CIP-0048/CIP-0048.md b/CIP-0048/CIP-0048.md index da7debce9..32019e8c3 100644 --- a/CIP-0048/CIP-0048.md +++ b/CIP-0048/CIP-0048.md @@ -42,8 +42,8 @@ Please note I offer optional single char names to allow futher reduction in meta |---|---| --- | |data| contains the data type MIME | for example if base 64, data:"text/plain;base64"| |src|contains a list of poitners to payloads | ```"src":[0,1]``` or ``` "src":["payload0","payload1"]```| -|policy, p | used withing references to references another policy | ```'r':{"data:"text/plain","src":{[0,1]},"p":"}"```| -|txhash, tx | used withing references a specific tx hash | ```'r':{"data:"text/plain","src":{[0,1]},"tx":"}"```| +|policy, p | references another policy. If none, assume current policy | ```'r':{"data:"text/plain","src":{[0,1]},"p":"}"```| +|txhash, tx | references a specific tx hash (optional) | ```'r':{"data:"text/plain","src":{[0,1]},"tx":"}"```| |type | the format/type of the data inside the payload |```'r':{"data:"image/jpeg","src":{[0,1]},"type":"ipfs"```| |b, back, backup | fallback, if a link to the data is used in the 'src' tag and is broken revert to a fallback link. | ```'r':{"src":{[0,1]},"b":{[2,3]}} ``` or for multiple fallbacks use ```'r':{"src":{[0,1]},"b":"{'0':{[2,3]}, '1'{[4,5]} }"``` | From 827ca7b3e9743fee1ad31bb22504eaed51a4e2a5 Mon Sep 17 00:00:00 2001 From: jack Date: Wed, 28 Sep 2022 20:48:49 +0100 Subject: [PATCH 15/35] refactored CIP48 into two CIPs --- CIP-0048/CIP-0048.md | 148 +++++++++----------------------------- CIP-0049/CIP-0049.md | 166 +++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 199 insertions(+), 115 deletions(-) create mode 100644 CIP-0049/CIP-0049.md diff --git a/CIP-0048/CIP-0048.md b/CIP-0048/CIP-0048.md index 32019e8c3..af477e712 100644 --- a/CIP-0048/CIP-0048.md +++ b/CIP-0048/CIP-0048.md @@ -1,141 +1,59 @@ --- CIP: 48? -Title: Extended 721 metadata -Authors: Jack (Pixel pool, https://forum.cardano.org/u/jack7e/, @pixel_pool twitter) +Title: 721 Metatdatum extenstion tag +Authors: Jack ([9000] pool, https://forum.cardano.org/u/jack7e/, @ada9000_ twitter) Comments-URI: https://forum.cardano.org/t/cip-extended-721/ Status: Draft Type: Informational -Created: 2022-04-21 +Created: 2022-09-28 --- # 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 +This standard proposes a method to extend the 721 metadatum standard bypassing the restrictions created by the version tag. -Specifically, this proposal aims to solve for the following: +# Motivation -* 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 -* Provide a mechanism to reference on chain data stored in a different policy +- NFT's on Cardano are static and rely on a version tag change to implement new features. +- The version tag is not very modular and restricts innovation. # Specification -Please note I offer optional single char names to allow futher reduction in metadata size if desired - -*Inside the 721 metadata tag* -|reserved 721 metadata tag |description | example -|---|---| --- | -|references, refs, r | contains data tag and src tag | ```'r':{ "data:"text/plain","src":[0,1] }```| -|payload, p | contains raw data | ```'p':{ "0":["h","e","l","l","o"], "1":"world" }``` | -|version| this is described in 721 | not sure if it should be version 1.1? instead of 2| - -*inside the refences tag* -|tags that are reseved inside references |description | example -|---|---| --- | -|data| contains the data type MIME | for example if base 64, data:"text/plain;base64"| -|src|contains a list of poitners to payloads | ```"src":[0,1]``` or ``` "src":["payload0","payload1"]```| -|policy, p | references another policy. If none, assume current policy | ```'r':{"data:"text/plain","src":{[0,1]},"p":"}"```| -|txhash, tx | references a specific tx hash (optional) | ```'r':{"data:"text/plain","src":{[0,1]},"tx":"}"```| -|type | the format/type of the data inside the payload |```'r':{"data:"image/jpeg","src":{[0,1]},"type":"ipfs"```| -|b, back, backup | fallback, if a link to the data is used in the 'src' tag and is broken revert to a fallback link. | ```'r':{"src":{[0,1]},"b":{[2,3]}} ``` or for multiple fallbacks use ```'r':{"src":{[0,1]},"b":"{'0':{[2,3]}, '1'{[4,5]} }"``` | - -*defintion of the different reference types* -| type | desciption | -|---| ---| -|ipfs|data is stored at ipfs| -|url|data is found a url| -|api|data is found at api get request| -|utf-8| data is directly in payload as utf-8 | -|b64 | data is in base 64 encoded in payload | -|reference? | advance feature, points to a reference | -|none| assume data is raw and using the defined media type | - -*?references in payloads could cause issues with circular dependencies, maybe this should be more like inode in ext2 or the depth defined* +- The standard 721 metadatum tag is used. +- The version tag is deprecated +- The `"ext"` tag is added within the `"721"` metadatum tag -``` +```json { "721":{ - "":{ - "":{ - "project":"", - "name":"", - "references":{ - "type":"raw" - "data":"text/plain" - "src":[ - 0, - 1 - ] - } - }, - "payload":{ - "0":["Hello"],"1":["World!"] - }, - "version":"2" + "ext": + "":{ + "": { + "name": , + "image": + } } } } ``` -# Retrieve payload information using references -1. Find all transactions with the 721 label -2. Check the version tag -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 -### In example -``` -nft 0 has the payload "p":{"0":""Hello","1":"World" } and the references "r":[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" - ``` +# Example usage -### Pseudo code +The theoretical CIPX in this example defines a script tag that must be present. To implement this CIP in our 721 metadatum JSON we simply add CIPX to the `"ext"` array. -to get the metadata from payloads -``` -for each transaction within the policy - if metadatum tag is '721' - if 'payload' or 'p' in json['721][] - for payloads in ['721][]['p'] - for refrenceName, data in payload - add data with referencename to datastructure -``` - - -to build the metadata for each nft -``` -refs = json['721'][][]['references']['src'] -dataType = json['721'][][]['references']['data'] - -for ref in refs - nft data += data from datastrucure indexed with ref +```json +{ + "721":{ + "ext": ["cipX"] + "":{ + "script":"fda1b6b487bee2e7f64ecf24d24b1224342484c0195ee1b7b943db5" + "": { + "name": , + "image": + } + } + } +} ``` -# Backwards compatibility -Used the version tag described in CIP 25. - -# Further considerations -### References -If we wanted to add more powerful referencing we could allow for references to references -```"payload":{"r":{"src":{[98,99]},"policy":"}"}}``` -*Like a block of pointers in the ext2 filesystem* -### Duplicate data -There could be issues with duplicate payloads. The solution I propose is just to use -the latest version of that payload. +Where cipX defines some property for the **JSON**. In this particular example it requires the nft to contain a script tag within the `""` tag. diff --git a/CIP-0049/CIP-0049.md b/CIP-0049/CIP-0049.md new file mode 100644 index 000000000..fd3a2d03c --- /dev/null +++ b/CIP-0049/CIP-0049.md @@ -0,0 +1,166 @@ +--- +CIP: 49? +Title: Extended 721 metadata +Authors: Jack (Pixel pool, https://forum.cardano.org/u/jack7e/, @pixel_pool twitter) +Comments-URI: https://forum.cardano.org/t/cip-extended-721/ +Status: Draft +Type: Informational +Created: 2022-04-22 (updated 2022-09-22) +--- + +## Important note + +This CIP depends on CIP48 + +# Abstract + +This standard proposes a fully on chain method to store and access metadata. +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. + +- 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 +- Provide a mechanism to reference on chain data stored in a different policy + +# Specification + +**Inside the 721 metadata JSON** +|reserved |description | scope | +|---|---|---| +|r | references tag, defines where to find the onchain data | Inside `` tag | +|p | contains raw data, defines on chain data | Inside `` tag | + +**Optional policy tag** + +By defualt CIP-48 will assume all payloads can be found within all the mint transcations made by the parent `""`. A `policy` tag can be defined withing the references tag if the onchain data payload is stored within an external policy. + +## General structure + +```json +{ + "721":{ + "":{ + "ext":["cip49"] // required + "":{ + "project":"", + "name":"", + // references + "r":[{ + "name":"", + "mediaType":"text/plain", + "src":"" // array of required payload ids + }] + }, + // payload + "p":{ + "":"", // payload 0 + "":"", // payload 1... etc + }, + } + } +} +``` + +# Example + +Mint transaction 1 + +```json +{ + "721":{ + "0000000000000000000000000000000000000000000000000000000A":{ + "ext":["cip49"] // required + "NFT0":{ + "project":"CIP49 Example", + "name":"NFT0", + // references + "r":[{ + "name":"", + "mediaType":"text/plain", + "src":[ + "0", + "2" + ] + }] + }, + // payload + "p":{ + "0":["Hello"],"1":["Goodbye"] + }, + } + } +} +``` + +Mint transaction 2 + +```json +{ + "721":{ + "0000000000000000000000000000000000000000000000000000000A":{ + "ext":["cip49"] // required + "NFT1":{ + "project":"CIP49 Example", + "name":"NFT1", + // references + "r":[{ + "name":"", + "mediaType":"text/plain", + "src":[ + "0", + "3" + ] + }] + }, + // payload + "p":{ + "2":["World"],"3":["Moon"] + }, + } + } +} + +``` + +## Example pseudo code walk through + +1. Find all transactions with the 721 label + +`found 2 mint transcations` + +2. Check the **ext** tag for **cip49** + +`found cip49` + +3. If a payload is found append that to an map or some data structure + +```js +payloads = { 0: "Hello", 1: "Goodbye", 2: "World", 3: "Moon" }; +``` + +4. Find all refrences for NFT0 + +```js +nft0_refs = ["0", "2"]; +nft0_data = "HelloWorld"; +``` + +# Backwards compatibility + +Handled via the use of the `"ext"` tag defined in CIP-48. + +# Further considerations + +### Duplicate data + +There could be issues with duplicate payloads. To solve the payload defined in the most recently minted tx takes priority. From 450812ca2c087b9e76051c6d4e1fb09386fe1e29 Mon Sep 17 00:00:00 2001 From: jack Date: Wed, 28 Sep 2022 20:59:47 +0100 Subject: [PATCH 16/35] updated example --- CIP-0049/CIP-0049.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CIP-0049/CIP-0049.md b/CIP-0049/CIP-0049.md index fd3a2d03c..e9207392d 100644 --- a/CIP-0049/CIP-0049.md +++ b/CIP-0049/CIP-0049.md @@ -134,7 +134,7 @@ Mint transaction 2 ## Example pseudo code walk through -1. Find all transactions with the 721 label +1. Find all transactions for the given policy `found 2 mint transcations` From fc0605848a79ed482ce57134e82993424b80013a Mon Sep 17 00:00:00 2001 From: jack Date: Sun, 2 Oct 2022 11:13:35 +0100 Subject: [PATCH 17/35] CIP48 and CIP49 are seperate CIPs --- CIP-0048/CIP-0048.md | 2 +- CIP-0049/CIP-0049.md | 166 ------------------------------------------- 2 files changed, 1 insertion(+), 167 deletions(-) delete mode 100644 CIP-0049/CIP-0049.md diff --git a/CIP-0048/CIP-0048.md b/CIP-0048/CIP-0048.md index af477e712..dcd11f22e 100644 --- a/CIP-0048/CIP-0048.md +++ b/CIP-0048/CIP-0048.md @@ -1,6 +1,6 @@ --- CIP: 48? -Title: 721 Metatdatum extenstion tag +Title: 721 Metadata payloads and references Authors: Jack ([9000] pool, https://forum.cardano.org/u/jack7e/, @ada9000_ twitter) Comments-URI: https://forum.cardano.org/t/cip-extended-721/ Status: Draft diff --git a/CIP-0049/CIP-0049.md b/CIP-0049/CIP-0049.md deleted file mode 100644 index e9207392d..000000000 --- a/CIP-0049/CIP-0049.md +++ /dev/null @@ -1,166 +0,0 @@ ---- -CIP: 49? -Title: Extended 721 metadata -Authors: Jack (Pixel pool, https://forum.cardano.org/u/jack7e/, @pixel_pool twitter) -Comments-URI: https://forum.cardano.org/t/cip-extended-721/ -Status: Draft -Type: Informational -Created: 2022-04-22 (updated 2022-09-22) ---- - -## Important note - -This CIP depends on CIP48 - -# Abstract - -This standard proposes a fully on chain method to store and access metadata. -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. - -- 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 -- Provide a mechanism to reference on chain data stored in a different policy - -# Specification - -**Inside the 721 metadata JSON** -|reserved |description | scope | -|---|---|---| -|r | references tag, defines where to find the onchain data | Inside `` tag | -|p | contains raw data, defines on chain data | Inside `` tag | - -**Optional policy tag** - -By defualt CIP-48 will assume all payloads can be found within all the mint transcations made by the parent `""`. A `policy` tag can be defined withing the references tag if the onchain data payload is stored within an external policy. - -## General structure - -```json -{ - "721":{ - "":{ - "ext":["cip49"] // required - "":{ - "project":"", - "name":"", - // references - "r":[{ - "name":"", - "mediaType":"text/plain", - "src":"" // array of required payload ids - }] - }, - // payload - "p":{ - "":"", // payload 0 - "":"", // payload 1... etc - }, - } - } -} -``` - -# Example - -Mint transaction 1 - -```json -{ - "721":{ - "0000000000000000000000000000000000000000000000000000000A":{ - "ext":["cip49"] // required - "NFT0":{ - "project":"CIP49 Example", - "name":"NFT0", - // references - "r":[{ - "name":"", - "mediaType":"text/plain", - "src":[ - "0", - "2" - ] - }] - }, - // payload - "p":{ - "0":["Hello"],"1":["Goodbye"] - }, - } - } -} -``` - -Mint transaction 2 - -```json -{ - "721":{ - "0000000000000000000000000000000000000000000000000000000A":{ - "ext":["cip49"] // required - "NFT1":{ - "project":"CIP49 Example", - "name":"NFT1", - // references - "r":[{ - "name":"", - "mediaType":"text/plain", - "src":[ - "0", - "3" - ] - }] - }, - // payload - "p":{ - "2":["World"],"3":["Moon"] - }, - } - } -} - -``` - -## Example pseudo code walk through - -1. Find all transactions for the given policy - -`found 2 mint transcations` - -2. Check the **ext** tag for **cip49** - -`found cip49` - -3. If a payload is found append that to an map or some data structure - -```js -payloads = { 0: "Hello", 1: "Goodbye", 2: "World", 3: "Moon" }; -``` - -4. Find all refrences for NFT0 - -```js -nft0_refs = ["0", "2"]; -nft0_data = "HelloWorld"; -``` - -# Backwards compatibility - -Handled via the use of the `"ext"` tag defined in CIP-48. - -# Further considerations - -### Duplicate data - -There could be issues with duplicate payloads. To solve the payload defined in the most recently minted tx takes priority. From 6c9bada28ebd7d53014ccacc2f3982fe262b72a3 Mon Sep 17 00:00:00 2001 From: jack Date: Sun, 2 Oct 2022 11:45:17 +0100 Subject: [PATCH 18/35] reimplemented CIP48 -_- --- CIP-0048/CIP-0048.md | 155 ++++++++++++++++++++++++++++++++++++------- 1 file changed, 131 insertions(+), 24 deletions(-) diff --git a/CIP-0048/CIP-0048.md b/CIP-0048/CIP-0048.md index dcd11f22e..281295908 100644 --- a/CIP-0048/CIP-0048.md +++ b/CIP-0048/CIP-0048.md @@ -1,59 +1,166 @@ --- CIP: 48? -Title: 721 Metadata payloads and references -Authors: Jack ([9000] pool, https://forum.cardano.org/u/jack7e/, @ada9000_ twitter) +Title: Extended 721 metadata +Authors: Jack (Pixel pool, https://forum.cardano.org/u/jack7e/, @pixel_pool twitter) Comments-URI: https://forum.cardano.org/t/cip-extended-721/ Status: Draft Type: Informational -Created: 2022-09-28 +Created: 2022-04-22 (updated 2022-09-22) --- +## Important note + +This CIP depends on CIP48 + # Abstract -This standard proposes a method to extend the 721 metadatum standard bypassing the restrictions created by the version tag. +This standard proposes a fully on chain method to store and access metadata. +This would allow users of 721 to increase or reduce the amount of data stored on chain. # Motivation -- NFT's on Cardano are static and rely on a version tag change to implement new features. -- The version tag is not very modular and restricts innovation. +- 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. + +- 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 +- Provide a mechanism to reference on chain data stored in a different policy # Specification -- The standard 721 metadatum tag is used. -- The version tag is deprecated -- The `"ext"` tag is added within the `"721"` metadatum tag +**Inside the 721 metadata JSON** +|reserved |description | scope | +|---|---|---| +|r | references tag, defines where to find the onchain data | Inside `` tag | +|p | contains raw data, defines on chain data | Inside `` tag | + +**Optional policy tag** + +By defualt CIP-48 will assume all payloads can be found within all the mint transcations made by the parent `""`. A `policy` tag can be defined withing the references tag if the onchain data payload is stored within an external policy. + +## General structure ```json { "721":{ - "ext": "":{ - "": { - "name": , - "image": - } + "ext":["cip48"] // required + "":{ + "project":"", + "name":"", + // references + "r":[{ + "name":"", + "mediaType":"text/plain", + "src":"" // array of required payload ids + }] + }, + // payload + "p":{ + "":"", // payload 0 + "":"", // payload 1... etc + }, } } } ``` -# Example usage +# Example -The theoretical CIPX in this example defines a script tag that must be present. To implement this CIP in our 721 metadatum JSON we simply add CIPX to the `"ext"` array. +Mint transaction 1 ```json { "721":{ - "ext": ["cipX"] - "":{ - "script":"fda1b6b487bee2e7f64ecf24d24b1224342484c0195ee1b7b943db5" - "": { - "name": , - "image": - } + "0000000000000000000000000000000000000000000000000000000A":{ + "ext":["cip48"] // required + "NFT0":{ + "project":"CIP48 Example", + "name":"NFT0", + // references + "r":[{ + "name":"", + "mediaType":"text/plain", + "src":[ + "0", + "2" + ] + }] + }, + // payload + "p":{ + "0":["Hello"],"1":["Goodbye"] + }, } } } ``` -Where cipX defines some property for the **JSON**. In this particular example it requires the nft to contain a script tag within the `""` tag. +Mint transaction 2 + +```json +{ + "721":{ + "0000000000000000000000000000000000000000000000000000000A":{ + "ext":["cip48"] // required + "NFT1":{ + "project":"CIP48 Example", + "name":"NFT1", + // references + "r":[{ + "name":"", + "mediaType":"text/plain", + "src":[ + "0", + "3" + ] + }] + }, + // payload + "p":{ + "2":["World"],"3":["Moon"] + }, + } + } +} + +``` + +## Example pseudo code walk through + +1. Find all transactions for the given policy + +`found 2 mint transcations` + +2. Check the **ext** tag for **cip48** + +`found cip48` + +3. If a payload is found append that to an map or some data structure + +```js +payloads = { 0: "Hello", 1: "Goodbye", 2: "World", 3: "Moon" }; +``` + +4. Find all refrences for NFT0 + +```js +nft0_refs = ["0", "2"]; +nft0_data = "HelloWorld"; +``` + +# Backwards compatibility + +Handled via the use of the `"ext"` tag defined in CIP-48. + +# Further considerations + +### Duplicate data + +There could be issues with duplicate payloads. To solve the payload defined in the most recently minted tx takes priority. From 2465815f195967ab78dcd2531b1017cd3544edd1 Mon Sep 17 00:00:00 2001 From: jack Date: Sun, 2 Oct 2022 12:39:05 +0100 Subject: [PATCH 19/35] updated CIP48 --- CIP-0048/CIP-0048.md | 63 +++++++++++++++++++++++++++++++++++--------- 1 file changed, 51 insertions(+), 12 deletions(-) diff --git a/CIP-0048/CIP-0048.md b/CIP-0048/CIP-0048.md index 281295908..a6eb46025 100644 --- a/CIP-0048/CIP-0048.md +++ b/CIP-0048/CIP-0048.md @@ -10,7 +10,7 @@ Created: 2022-04-22 (updated 2022-09-22) ## Important note -This CIP depends on CIP48 +This CIP depends on [CIP49](https://github.com/cardano-foundation/CIPs/pull/343/files) # Abstract @@ -37,12 +37,47 @@ Specifically, this proposal aims to solve for the following: **Inside the 721 metadata JSON** |reserved |description | scope | |---|---|---| -|r | references tag, defines where to find the onchain data | Inside `` tag | -|p | contains raw data, defines on chain data | Inside `` tag | - -**Optional policy tag** - -By defualt CIP-48 will assume all payloads can be found within all the mint transcations made by the parent `""`. A `policy` tag can be defined withing the references tag if the onchain data payload is stored within an external policy. +|refs | references tag, defines where to find the onchain data | Inside `` tag | +|p | contains raw data (on chain data). | Inside `` tag | + +**Optional rtype tag** + +The default CIP-48 behavior will assume all payloads can be found within all the mint transactions made by the parent ``. + +However optional behavior maybe desired. Insider the `refs` tag we therefore use the `type` tag. + +In CIP49 we shall define two types. + +- `policy` + - Defines an external policy (instead of the default behavior of using the parent policy) + - example + ```json + "refs": [ + { + "name": "...", + "mediaType": "...", + "type": { + "policy": "" + } + } + ] + ``` +- `txhash` + - Defines a specific transaction hash (instead of the default behavior of using the parent policy) + - example + ```json + "refs": [ + { + "name": "...", + "mediaType": "...", + "type": { + "txhash": "" + } + } + ] + ``` + - `txhash` is faster than parsing all transactions in a given policy. + - `txhash` can dramatically reduce onchain data usage if duplicated data is referenced here _(however, the bytes required to define the reference would have to be less than the reference data itself)_ ## General structure @@ -55,7 +90,7 @@ By defualt CIP-48 will assume all payloads can be found within all the mint tran "project":"", "name":"", // references - "r":[{ + "refs":[{ "name":"", "mediaType":"text/plain", "src":"" // array of required payload ids @@ -84,7 +119,7 @@ Mint transaction 1 "project":"CIP48 Example", "name":"NFT0", // references - "r":[{ + "refs":[{ "name":"", "mediaType":"text/plain", "src":[ @@ -113,7 +148,7 @@ Mint transaction 2 "project":"CIP48 Example", "name":"NFT1", // references - "r":[{ + "refs":[{ "name":"", "mediaType":"text/plain", "src":[ @@ -132,7 +167,7 @@ Mint transaction 2 ``` -## Example pseudo code walk through +## Example pseudo code walk through (using default behavior) 1. Find all transactions for the given policy @@ -148,7 +183,7 @@ Mint transaction 2 payloads = { 0: "Hello", 1: "Goodbye", 2: "World", 3: "Moon" }; ``` -4. Find all refrences for NFT0 +4. Find all `refs` references for NFT0 ```js nft0_refs = ["0", "2"]; @@ -161,6 +196,10 @@ Handled via the use of the `"ext"` tag defined in CIP-48. # Further considerations +- Later we may want to use different reference types, maybe even plutus contract references. Due to this I have defined the `type` tag inside the `refs` (references) tag. +- `p` is used instead of **payload** to reduce bytes. Specifically `p` is not used within the `` tag therefore readability is less of a priority than data size. Unlike `refs` which is defined in the `` tag +- JSON is kept over CBOR or alternatives as this CIP is encapsulated in the 721 metadatum tag and JSON is easier for developers to adopt + ### Duplicate data There could be issues with duplicate payloads. To solve the payload defined in the most recently minted tx takes priority. From 594400b80df0d5fe498dc52840fb671038a808d2 Mon Sep 17 00:00:00 2001 From: jack Date: Sun, 2 Oct 2022 12:39:52 +0100 Subject: [PATCH 20/35] renamed CIP-0048/CIP-0048.md -> CIP-0048/README.md --- CIP-0048/{CIP-0048.md => README.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename CIP-0048/{CIP-0048.md => README.md} (100%) diff --git a/CIP-0048/CIP-0048.md b/CIP-0048/README.md similarity index 100% rename from CIP-0048/CIP-0048.md rename to CIP-0048/README.md From aec50fc5c4c8bcbda6368d25c7c5b29036dfb4bb Mon Sep 17 00:00:00 2001 From: jack Date: Sun, 2 Oct 2022 12:56:58 +0100 Subject: [PATCH 21/35] updated README.md header --- CIP-0048/README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/CIP-0048/README.md b/CIP-0048/README.md index a6eb46025..560f4bdb0 100644 --- a/CIP-0048/README.md +++ b/CIP-0048/README.md @@ -1,7 +1,7 @@ --- CIP: 48? -Title: Extended 721 metadata -Authors: Jack (Pixel pool, https://forum.cardano.org/u/jack7e/, @pixel_pool twitter) +Title: 721 References and Payloads +Authors: Jack (ada9000, https://forum.cardano.org/u/jack7e/, @ada9000_ twitter) Comments-URI: https://forum.cardano.org/t/cip-extended-721/ Status: Draft Type: Informational From 09b3b10ba866ba574bef686935dbbfd6bf06848d Mon Sep 17 00:00:00 2001 From: jack Date: Sun, 2 Oct 2022 13:30:10 +0100 Subject: [PATCH 22/35] ammendments --- CIP-0048/README.md | 56 ++++++++++++++++++++++++++++++---------------- 1 file changed, 37 insertions(+), 19 deletions(-) diff --git a/CIP-0048/README.md b/CIP-0048/README.md index 560f4bdb0..f691f7286 100644 --- a/CIP-0048/README.md +++ b/CIP-0048/README.md @@ -10,37 +10,41 @@ Created: 2022-04-22 (updated 2022-09-22) ## Important note -This CIP depends on [CIP49](https://github.com/cardano-foundation/CIPs/pull/343/files) +This CIP mentions the `ext` json key defined by [CIP49](https://github.com/cardano-foundation/CIPs/pull/343/files) which is an outcome of work on CIP48. # Abstract -This standard proposes a fully on chain method to store and access metadata. -This would allow users of 721 to increase or reduce the amount of data stored on chain. +- This standard proposes a method to allow NFT assets to reference other onchain data. +- This would allow users of 721 metadata to increase or reduce the amount of data an NFT asset uses. # 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. +- There is no current mechanism to reduce duplicated metadata +- NFT assets are restricted by there own scope, optional references would prevent this restriction +- There is currently no way to reference on chain data stored in a different policy -- 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 +# Specification -Specifically, this proposal aims to solve for the following: +### **Inside the 721 metadata JSON** -- 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 -- Provide a mechanism to reference on chain data stored in a different policy +| reserved | description | scope | +| -------- | ------------------------------------------------------ | ------------------------- | +| refs | references tag, defines where to find the onchain data | Inside `` tag | +| p | contains raw data (on chain data). | Inside `` tag | -# Specification +### **The `refs` tag** -**Inside the 721 metadata JSON** -|reserved |description | scope | -|---|---|---| -|refs | references tag, defines where to find the onchain data | Inside `` tag | -|p | contains raw data (on chain data). | Inside `` tag | +Contains the `name`, `mediaType`, `src` tags (and the optional `type` tag) -**Optional rtype tag** +- `name` (string) is the references name (similar usage to the current `files` tag) +- `mediaType` (string) defines the mime type for the data referenced in `src` + - is a string +- `src` (string array) is an **ordered** array of references. + - The order is that of which the data will be parsed. For example `["1","3","2"]` will result in payload `"1"` being the start of the data, followed by payload `"3"` and ending with payload `"2"`. + +### **Optional rtype tag** The default CIP-48 behavior will assume all payloads can be found within all the mint transactions made by the parent ``. @@ -79,6 +83,20 @@ In CIP49 we shall define two types. - `txhash` is faster than parsing all transactions in a given policy. - `txhash` can dramatically reduce onchain data usage if duplicated data is referenced here _(however, the bytes required to define the reference would have to be less than the reference data itself)_ +### **The `p` tag** + +- Defined within the `` scope +- contains payload reference names followed by a string array of payload data +- example + ```json + "p": + { + "1": ["1 is a valid payload"], + "payloadA": ["a...64","b...64"], //a string has a max length of 64 characters + "payloadB": ["I'm found by referencing payloadB"], + } + ``` + ## General structure ```json @@ -98,8 +116,8 @@ In CIP49 we shall define two types. }, // payload "p":{ - "":"", // payload 0 - "":"", // payload 1... etc + "":["", "..."], // payload 0 + "":[""], // payload 1... etc }, } } From 54b0c631bdfb871284d437edfc6a1eb44728c4cc Mon Sep 17 00:00:00 2001 From: jack Date: Sun, 2 Oct 2022 13:45:53 +0100 Subject: [PATCH 23/35] ammendments --- CIP-0048/README.md | 133 ++++++++++++++++++++++----------------------- 1 file changed, 66 insertions(+), 67 deletions(-) diff --git a/CIP-0048/README.md b/CIP-0048/README.md index f691f7286..578a5a88a 100644 --- a/CIP-0048/README.md +++ b/CIP-0048/README.md @@ -38,7 +38,7 @@ This CIP mentions the `ext` json key defined by [CIP49](https://github.com/carda Contains the `name`, `mediaType`, `src` tags (and the optional `type` tag) -- `name` (string) is the references name (similar usage to the current `files` tag) +- `name` (string) is the references name (similar usage to name in the current `files` tag) - `mediaType` (string) defines the mime type for the data referenced in `src` - is a string - `src` (string array) is an **ordered** array of references. @@ -46,11 +46,9 @@ Contains the `name`, `mediaType`, `src` tags (and the optional `type` tag) ### **Optional rtype tag** -The default CIP-48 behavior will assume all payloads can be found within all the mint transactions made by the parent ``. +The default CIP-48 behavior is to assume the assets parent `` contains all the payloads. -However optional behavior maybe desired. Insider the `refs` tag we therefore use the `type` tag. - -In CIP49 we shall define two types. +Optionally we define `type` and two options `policy` and `txhash`. To allow for non-default behavior - `policy` - Defines an external policy (instead of the default behavior of using the parent policy) @@ -101,26 +99,28 @@ In CIP49 we shall define two types. ```json { - "721":{ - "":{ - "ext":["cip48"] // required - "":{ - "project":"", - "name":"", - // references - "refs":[{ - "name":"", - "mediaType":"text/plain", - "src":"" // array of required payload ids - }] - }, - // payload - "p":{ - "":["", "..."], // payload 0 - "":[""], // payload 1... etc - }, + "721": { + "ext": ["cip48"], // tells 'user' cip48 is in use within the metadata + "": { + "": { + "project": "", + "name": "", + // references + "refs": [ + { + "name": "", + "mediaType": "text/plain", + "src": "" // array of required payload ids + } + ] + }, + // payload + "p": { + "": ["", "..."], // payload 0 + "": [""] // payload 1... etc } - } + } + } } ``` @@ -130,28 +130,28 @@ Mint transaction 1 ```json { - "721":{ - "0000000000000000000000000000000000000000000000000000000A":{ - "ext":["cip48"] // required - "NFT0":{ - "project":"CIP48 Example", - "name":"NFT0", - // references - "refs":[{ - "name":"", - "mediaType":"text/plain", - "src":[ - "0", - "2" - ] - }] - }, - // payload - "p":{ - "0":["Hello"],"1":["Goodbye"] - }, + "721": { + "ext": ["cip48"], + "0000000000000000000000000000000000000000000000000000000A": { + "NFT0": { + "project": "CIP48 Example", + "name": "NFT0", + // references + "refs": [ + { + "name": "", + "mediaType": "text/plain", + "src": ["0", "2"] + } + ] + }, + // payload + "p": { + "0": ["Hello"], + "1": ["Goodbye"] } - } + } + } } ``` @@ -159,30 +159,29 @@ Mint transaction 2 ```json { - "721":{ - "0000000000000000000000000000000000000000000000000000000A":{ - "ext":["cip48"] // required - "NFT1":{ - "project":"CIP48 Example", - "name":"NFT1", - // references - "refs":[{ - "name":"", - "mediaType":"text/plain", - "src":[ - "0", - "3" - ] - }] - }, - // payload - "p":{ - "2":["World"],"3":["Moon"] - }, + "721": { + "ext": ["cip48"], + "0000000000000000000000000000000000000000000000000000000A": { + "NFT1": { + "project": "CIP48 Example", + "name": "NFT1", + // references + "refs": [ + { + "name": "", + "mediaType": "text/plain", + "src": ["0", "3"] + } + ] + }, + // payload + "p": { + "2": ["World"], + "3": ["Moon"] } - } + } + } } - ``` ## Example pseudo code walk through (using default behavior) From bc0906a972a2b6a64729a84c0cb7239f67ec3792 Mon Sep 17 00:00:00 2001 From: jack Date: Sun, 2 Oct 2022 13:50:21 +0100 Subject: [PATCH 24/35] amendments --- CIP-0048/README.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/CIP-0048/README.md b/CIP-0048/README.md index 578a5a88a..5bc724bb8 100644 --- a/CIP-0048/README.md +++ b/CIP-0048/README.md @@ -110,14 +110,14 @@ Optionally we define `type` and two options `policy` and `txhash`. To allow for { "name": "", "mediaType": "text/plain", - "src": "" // array of required payload ids + "src": ["", ""] // array of required payload ids (ordered) } ] }, // payload "p": { - "": ["", "..."], // payload 0 - "": [""] // payload 1... etc + "": ["", ""], // payload0 + "": [""] // payload1 } } } From dc16d71b96da50044259ac1c47f74db6cc5181c5 Mon Sep 17 00:00:00 2001 From: jack Date: Sun, 2 Oct 2022 13:50:21 +0100 Subject: [PATCH 25/35] amendments to example --- CIP-0048/README.md | 29 ++++++++++++++++------------- 1 file changed, 16 insertions(+), 13 deletions(-) diff --git a/CIP-0048/README.md b/CIP-0048/README.md index 578a5a88a..241012739 100644 --- a/CIP-0048/README.md +++ b/CIP-0048/README.md @@ -110,14 +110,14 @@ Optionally we define `type` and two options `policy` and `txhash`. To allow for { "name": "", "mediaType": "text/plain", - "src": "" // array of required payload ids + "src": ["", ""] // array of required payload ids (ordered) } ] }, // payload "p": { - "": ["", "..."], // payload 0 - "": [""] // payload 1... etc + "": ["", ""], // payload0 + "": [""] // payload1 } } } @@ -188,23 +188,25 @@ Mint transaction 2 1. Find all transactions for the given policy -`found 2 mint transcations` + - `found 2 mint transcations` 2. Check the **ext** tag for **cip48** -`found cip48` + - `found cip48` we now know the metadata contains references and payloads -3. If a payload is found append that to an map or some data structure +3. Iterate over each transaction. If a payload is found append that to an map or some data structure -```js -payloads = { 0: "Hello", 1: "Goodbye", 2: "World", 3: "Moon" }; -``` + - ```js + payloads = { 0: "Hello", 1: "Goodbye", 2: "World", 3: "Moon" }; + ``` + +4. Find all `refs` (references) for the `` NFT0. Then build the data in the order defined by the `src` array. -4. Find all `refs` references for NFT0 + - ```js + nft0_refs = ["0", "2"]; + nft0_data = "HelloWorld"; + ``` -```js -nft0_refs = ["0", "2"]; -nft0_data = "HelloWorld"; ``` # Backwards compatibility @@ -220,3 +222,4 @@ Handled via the use of the `"ext"` tag defined in CIP-48. ### Duplicate data There could be issues with duplicate payloads. To solve the payload defined in the most recently minted tx takes priority. +``` From e4a65090d44f32cc5d1d89ef0d1ae0fd11b33312 Mon Sep 17 00:00:00 2001 From: jack Date: Sun, 2 Oct 2022 13:58:35 +0100 Subject: [PATCH 26/35] amendments --- CIP-0048/README.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/CIP-0048/README.md b/CIP-0048/README.md index 241012739..376ada346 100644 --- a/CIP-0048/README.md +++ b/CIP-0048/README.md @@ -207,8 +207,6 @@ Mint transaction 2 nft0_data = "HelloWorld"; ``` -``` - # Backwards compatibility Handled via the use of the `"ext"` tag defined in CIP-48. @@ -222,4 +220,7 @@ Handled via the use of the `"ext"` tag defined in CIP-48. ### Duplicate data There could be issues with duplicate payloads. To solve the payload defined in the most recently minted tx takes priority. + +``` + ``` From 2364e8abaaf0931fbb724faa12fce7b33168a335 Mon Sep 17 00:00:00 2001 From: jack Date: Sun, 2 Oct 2022 13:58:59 +0100 Subject: [PATCH 27/35] amendments --- CIP-0048/README.md | 4 ---- 1 file changed, 4 deletions(-) diff --git a/CIP-0048/README.md b/CIP-0048/README.md index 376ada346..0ddf33d0a 100644 --- a/CIP-0048/README.md +++ b/CIP-0048/README.md @@ -220,7 +220,3 @@ Handled via the use of the `"ext"` tag defined in CIP-48. ### Duplicate data There could be issues with duplicate payloads. To solve the payload defined in the most recently minted tx takes priority. - -``` - -``` From edf147b906b9c3ca4ec23bb5503aca2fc7c34649 Mon Sep 17 00:00:00 2001 From: jack Date: Sun, 2 Oct 2022 14:03:02 +0100 Subject: [PATCH 28/35] amendments --- CIP-0048/README.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/CIP-0048/README.md b/CIP-0048/README.md index 0ddf33d0a..b406e9cff 100644 --- a/CIP-0048/README.md +++ b/CIP-0048/README.md @@ -22,7 +22,7 @@ This CIP mentions the `ext` json key defined by [CIP49](https://github.com/carda - 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. - There is no current mechanism to reduce duplicated metadata -- NFT assets are restricted by there own scope, optional references would prevent this restriction +- NFT assets are restricted by there own scope metadata scope, optional references would prevent this restriction - There is currently no way to reference on chain data stored in a different policy # Specification @@ -44,7 +44,7 @@ Contains the `name`, `mediaType`, `src` tags (and the optional `type` tag) - `src` (string array) is an **ordered** array of references. - The order is that of which the data will be parsed. For example `["1","3","2"]` will result in payload `"1"` being the start of the data, followed by payload `"3"` and ending with payload `"2"`. -### **Optional rtype tag** +### **Optional `type` tag for `refs`** The default CIP-48 behavior is to assume the assets parent `` contains all the payloads. @@ -81,7 +81,7 @@ Optionally we define `type` and two options `policy` and `txhash`. To allow for - `txhash` is faster than parsing all transactions in a given policy. - `txhash` can dramatically reduce onchain data usage if duplicated data is referenced here _(however, the bytes required to define the reference would have to be less than the reference data itself)_ -### **The `p` tag** +### **The payload `p` tag** - Defined within the `` scope - contains payload reference names followed by a string array of payload data From 4911949963c992b4eb7a0c0d623032859164e57e Mon Sep 17 00:00:00 2001 From: jack Date: Sun, 2 Oct 2022 14:03:40 +0100 Subject: [PATCH 29/35] amendments --- CIP-0048/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CIP-0048/README.md b/CIP-0048/README.md index b406e9cff..1d7eb1b66 100644 --- a/CIP-0048/README.md +++ b/CIP-0048/README.md @@ -22,7 +22,7 @@ This CIP mentions the `ext` json key defined by [CIP49](https://github.com/carda - 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. - There is no current mechanism to reduce duplicated metadata -- NFT assets are restricted by there own scope metadata scope, optional references would prevent this restriction +- NFT assets are restricted by there own metadata scope, optional references would prevent this restriction - There is currently no way to reference on chain data stored in a different policy # Specification From b99a0aa76b9072e02096e67c5401cab848f7d7fa Mon Sep 17 00:00:00 2001 From: jack Date: Sun, 2 Oct 2022 14:10:31 +0100 Subject: [PATCH 30/35] example update --- CIP-0048/README.md | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-) diff --git a/CIP-0048/README.md b/CIP-0048/README.md index 1d7eb1b66..dc1624abb 100644 --- a/CIP-0048/README.md +++ b/CIP-0048/README.md @@ -139,7 +139,7 @@ Mint transaction 1 // references "refs": [ { - "name": "", + "name": "NFT0", "mediaType": "text/plain", "src": ["0", "2"] } @@ -168,7 +168,7 @@ Mint transaction 2 // references "refs": [ { - "name": "", + "name": "NFT1", "mediaType": "text/plain", "src": ["0", "3"] } @@ -184,9 +184,9 @@ Mint transaction 2 } ``` -## Example pseudo code walk through (using default behavior) +### Pseudo code walk through using the above example (using default behavior) -1. Find all transactions for the given policy +1. Find all transactions for the given `` - `found 2 mint transcations` @@ -196,17 +196,23 @@ Mint transaction 2 3. Iterate over each transaction. If a payload is found append that to an map or some data structure + - found 4 payloads - ```js payloads = { 0: "Hello", 1: "Goodbye", 2: "World", 3: "Moon" }; ``` -4. Find all `refs` (references) for the `` NFT0. Then build the data in the order defined by the `src` array. +4. Find all `refs` (references) for the `` we use NFT0. Then build the data in the order defined by the `src` array. + - found 2 references - ```js nft0_refs = ["0", "2"]; nft0_data = "HelloWorld"; ``` +5. use the mediaType (mimetype) to determine the data. + - mediaType = "test/plain" + - NFT0 contains text "HelloWorld" + # Backwards compatibility Handled via the use of the `"ext"` tag defined in CIP-48. From c0d2aee5b506265bac36fa2ea91a3ee0e41ddd7b Mon Sep 17 00:00:00 2001 From: jack Date: Sun, 2 Oct 2022 19:12:03 +0100 Subject: [PATCH 31/35] updates to handle image tag usage in CIP25 --- CIP-0048/README.md | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/CIP-0048/README.md b/CIP-0048/README.md index dc1624abb..21291b563 100644 --- a/CIP-0048/README.md +++ b/CIP-0048/README.md @@ -105,10 +105,11 @@ Optionally we define `type` and two options `policy` and `txhash`. To allow for "": { "project": "", "name": "", + "image": "" // image is defined by refs or a uri // references "refs": [ { - "name": "", + "name": "", "mediaType": "text/plain", "src": ["", ""] // array of required payload ids (ordered) } @@ -124,6 +125,26 @@ Optionally we define `type` and two options `policy` and `txhash`. To allow for } ``` +## Notes + +- CIP25 currently defines a 'required' image tag. + - Not all NFT's require an image. + - CIP48 alters the use of image. Requiring the 'user' to first check if the image string matches any reference names. Then to fallback on the default behavior. + - example, in which the image is found by referring to payloads. + ```json + { + "image":"myImageNFT" + "refs":[ + { + "name": "myImageNFT" + "mediaType":"image/svg+xml;utf8" + "src": ["refToPayloadA", "refToPayloadB"] + } + ] + } + ``` + - The image tag can still be used as a thumbnail if required. + # Example Mint transaction 1 From 7bf0859c117493a588e8d5857aa6bf836f78f57f Mon Sep 17 00:00:00 2001 From: jack Date: Sun, 2 Oct 2022 19:45:23 +0100 Subject: [PATCH 32/35] updates to handle files tag usage in CIP25 --- CIP-0048/README.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/CIP-0048/README.md b/CIP-0048/README.md index 21291b563..e2abd48c6 100644 --- a/CIP-0048/README.md +++ b/CIP-0048/README.md @@ -128,7 +128,6 @@ Optionally we define `type` and two options `policy` and `txhash`. To allow for ## Notes - CIP25 currently defines a 'required' image tag. - - Not all NFT's require an image. - CIP48 alters the use of image. Requiring the 'user' to first check if the image string matches any reference names. Then to fallback on the default behavior. - example, in which the image is found by referring to payloads. ```json @@ -143,7 +142,9 @@ Optionally we define `type` and two options `policy` and `txhash`. To allow for ] } ``` - - The image tag can still be used as a thumbnail if required. + - The `files` tag can still be used to describe higher resolution files images, though it should also adopt the same usage of `` described for `image` tag in the aforementioned note + - The `image` tag can still be used as a thumbnail if required. + - Not all NFT's require an image (CIP 25 is confusing called the `NFT metadata standard?`) TODO: review # Example From 11eedf350e6b92fb87bab961dc420e4ff512ee13 Mon Sep 17 00:00:00 2001 From: jack Date: Sun, 2 Oct 2022 19:47:53 +0100 Subject: [PATCH 33/35] removed files in CIP48 --- CIP-0048/README.md | 1 - 1 file changed, 1 deletion(-) diff --git a/CIP-0048/README.md b/CIP-0048/README.md index e2abd48c6..1b48453c7 100644 --- a/CIP-0048/README.md +++ b/CIP-0048/README.md @@ -142,7 +142,6 @@ Optionally we define `type` and two options `policy` and `txhash`. To allow for ] } ``` - - The `files` tag can still be used to describe higher resolution files images, though it should also adopt the same usage of `` described for `image` tag in the aforementioned note - The `image` tag can still be used as a thumbnail if required. - Not all NFT's require an image (CIP 25 is confusing called the `NFT metadata standard?`) TODO: review From 404279aeb0f9bac048d2cbec2e7d41cb920801b4 Mon Sep 17 00:00:00 2001 From: jack Date: Sun, 2 Oct 2022 19:54:30 +0100 Subject: [PATCH 34/35] behavior duplicated files in CIP25 if multiple refs are defined --- CIP-0048/README.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/CIP-0048/README.md b/CIP-0048/README.md index 1b48453c7..a95ad45c6 100644 --- a/CIP-0048/README.md +++ b/CIP-0048/README.md @@ -143,7 +143,8 @@ Optionally we define `type` and two options `policy` and `txhash`. To allow for } ``` - The `image` tag can still be used as a thumbnail if required. - - Not all NFT's require an image (CIP 25 is confusing called the `NFT metadata standard?`) TODO: review +- Not all NFT's require an image (CIP 25 is confusing called the `NFT metadata standard?`) TODO: review +- If there are multiple `refs` defined the references that are _NOT_ defined in the `image` tag have the same behavior as the `files` tag currently defined in CIP25 # Example From 7480cce529bda002bd3eac6c80c3c506e134624a Mon Sep 17 00:00:00 2001 From: jack Date: Tue, 4 Oct 2022 00:14:15 +0100 Subject: [PATCH 35/35] noticed txhashes should be an array --- CIP-0048/README.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/CIP-0048/README.md b/CIP-0048/README.md index a95ad45c6..2fc7f75f5 100644 --- a/CIP-0048/README.md +++ b/CIP-0048/README.md @@ -65,7 +65,7 @@ Optionally we define `type` and two options `policy` and `txhash`. To allow for ] ``` - `txhash` - - Defines a specific transaction hash (instead of the default behavior of using the parent policy) + - Defines an array of transaction hashes (instead of the default behavior of using the parent policy) - example ```json "refs": [ @@ -73,7 +73,7 @@ Optionally we define `type` and two options `policy` and `txhash`. To allow for "name": "...", "mediaType": "...", "type": { - "txhash": "" + "txhash": ["", ""] } } ] @@ -143,7 +143,6 @@ Optionally we define `type` and two options `policy` and `txhash`. To allow for } ``` - The `image` tag can still be used as a thumbnail if required. -- Not all NFT's require an image (CIP 25 is confusing called the `NFT metadata standard?`) TODO: review - If there are multiple `refs` defined the references that are _NOT_ defined in the `image` tag have the same behavior as the `files` tag currently defined in CIP25 # Example