CIP-0048? | NFT metadata references and payloads

CIP-0048/CIP-0048.md

@@ -0,0 +1,141 @@
+---
+CIP: 48?
+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-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
+* 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
+|---|---| --- |
+|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":"<POLICY_ID>}"```|
+|txhash, tx | references a specific tx hash (optional) | ```'r':{"data:"text/plain","src":{[0,1]},"tx":"<TX_HASH>}"```|
+|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*
+
+
+```
+{
+ "721":{
+ "<POLICY_ID>":{
+ "<NFT_NAME_B16>":{
+ "project":"<PROJECT>",
+ "name":"<NFT_NAME>",
+ "references":{
+ "type":"raw"
+ "data":"text/plain"
+ "src":[
+ 0,
+ 1
+ ]
+ }
+ },
+ "payload":{
+ "0":["Hello"],"1":["World!"]
+ },
+ "version":"2"
+ }
+ }
+}
+```
+# 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"
+ ```
+
+### Pseudo code
+
+to get the metadata from payloads
+```
+for each transaction within the policy
+ if metadatum tag is '721'
+ if 'payload' or 'p' in json['721][<POLICY_ID>]
+ for payloads in ['721][<POLICY_ID>]['p']
+ for refrenceName, data in payload
+ add data with referencename to datastructure 
+```
+
+
+to build the metadata for each nft
+```
+refs = json['721'][<POLICY_ID>][<NFT_NAME>]['references']['src']
+dataType = json['721'][<POLICY_ID>][<NFT_NAME>]['references']['data']
+
+for ref in refs
+ nft data += data from datastrucure indexed with ref
+```
+
+# 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":"<POLICY_ID>}"}}```
+*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.