KIP 0025 : Kadena FS: URLs and methods to retrieve

[CryptoPascal31]

This KIP propose a new mechanism to reference short data object stored on the blockchain via URLs,
and associated mechanisms to retrieve them:

This is an early draft and opinions / feedback / ideas are strongly desired.

---

As a proof of concept, I deployed several simple storage modules on testnet, and stored many objects:
https://balance.chainweb.com/modules.html?server=api.testnet.chainweb.com&module=free.kdafs-store-one&chain=1

Simplest:
kdafs://testnet04:1/free.kdafs-store-one/aGgztKIhm6y8M9iNjHd2txyvyg2ZrVGumP02RtZ-o2A
kdafs://testnet04:14/free.kdafs-store-two/m-l_64Xw86FzD73Nzs9PmxTSXugntZ6dZzTQkt1dgq8

More complex:
kdafs://testnet04:1/free.kdafs-store-one/WR1htqVpDlExP1pAcWxysGvODgu2bf5fFPaiWJjX4Sg

With embedded images:
kdafs://testnet04:1/free.kdafs-store-one/xZJsVE9hI3OBk1TNF5iSZaMKjxlVhKQ0-pJVSAeRof8
kdafs://testnet04:14/free.kdafs-store-two/LJGE9w87vDl--ShVnMX8mCVgpOWwWqh-TG-98tyYziU

---

I created a simple client dApp that does directly Pact calls, allowing everyone to retrieve above object's URLs.
https://kdafs-dapp.marmalade-ng.xyz/

---

I created and deployed a PoC gateway, that can be used according to the KIP:
https://gw.marmalade-ng.xyz/

For example:
https://gw.marmalade-ng.xyz/kdafs/testnet04:14/free.kdafs-store-two/m-l_64Xw86FzD73Nzs9PmxTSXugntZ6dZzTQkt1dgq8
https://gw.marmalade-ng.xyz/kdafs/testnet04:1/free.kdafs-store-one/WR1htqVpDlExP1pAcWxysGvODgu2bf5fFPaiWJjX4Sg

---

• To see the specific tasks where the Asana app for GitHub is being used, see below:
  • https://app.asana.com/0/0/1208668844268882

[daplcor]

So, theoretically, this could be applied to more of a general storage environment with lookup capabilities both on and off-chain. I have advocated for simplification and processes for URIs to move across chains/blockchains. But, storing the URI in this manner and pointing to an image off-chain is a great way for us to cement the NFT/data in a simple deployment process. So if a project wanted metadata on chain, they could store it anywhere, say chain 1, for instance, and create either an immutable or non-immutable record.

This could help enhance games that way, an easy way to upgrade attributes within the single NFT... The hash process would need to change, and ofc that's up to individual projects, but it's an excellent blueprint for achieving this without complex table storage/mapping.

Consider the gaming use case as I feel many projects would benefit from a more straightforward mechanism. I assume from reading, we can simply set immutable to false and achieve something similar? I am curious what would happen with our hash in that case, does the CID remain the same or need to change?

[CryptoPascal31]

This could help enhance games that way, an easy way to upgrade attributes within the single NFT... The hash process would need to change, and ofc that's up to individual projects, but it's an excellent blueprint for achieving this without complex table storage/mapping.

Consider the gaming use case as I feel many projects would benefit from a more straightforward mechanism. I assume from reading, we can simply set immutable to false and achieve something similar? I am curious what would happen with our hash in that case, does the CID remain the same or need to change?

Thank you for the feedback

The KIP itself doesn't require that the data is addressed by its hash.
It's up to the contract implementation to determine how the CIDs are generated.

The KIP only requires content to be addressed by a unique ID, and the storage module must provide only two functions:

• kdafs-get for retrieval
• kdafs-immutable to help the gateways/dApps to determine whether the content can be cached.

---

For my own tests, I created another storage module.. where data is mutable. And the CIDs are randomly generated instead of hashing data. (as you notice, it wouldn't make sense !)

https://balance.chainweb.com/modules.html?server=api.testnet.chainweb.com&module=free.kdafs-store-mut-one&chain=14

Example of a stored object:
kdafs://testnet04:14/free.kdafs-store-mut-one/d9wkUX2d_SsR-mzB2By27f4P

[trendzetter]

I like this idea. Just some thoughts that I had, maybe they aren't applicable or desirable. Would it be useful to have?

• a function to return the max size of an object to store as there is obviously a physical limit dictated by block-size and maybe other factors which may change over time
• a function or attribute to return the file-type and encoding of an object
• some standard for encoding/decoding files. eg base64 -but then it still needs more specification as to which variant-
• some standardization of the store -write access- function in another interface -to keep it optional- since you compare it to a filesystem

[CryptoPascal31]

* a function to return the max size of an object to store as there is obviously a physical limit dictated by block-size and maybe other factors which may change over time

* some standardization of the store -write access- function in another interface -to keep it optional- since you compare it to a filesystem

Thank you for your feedback, George.

IMHO, I prefer to restrict the standard to the minimum:

• A standard way to retrieve objects on chain from the outside.
• A standard protocol between a module and a gateway from on-chain to outside.

Nothing more.

The name may be misleading. I called it FS to highlight some similarities with ipfs:// (especially on the HTTP gateway part). But definitively, this is not a file system.

I prefer letting most freedom possible to the module owner to determine how the objects are stored (in database, in const, ....) with / without restrictions, static, generated .... The maximum size depends on the implementation as well, and how the objects are stored. IMHO this is out of the scope of this KIP proposal.

[CryptoPascal31]

* a function or attribute to return the file-type and encoding of an object

* some standard for encoding/decoding files. eg base64 -but then it still needs more specification as to which variant-

For several reasons, I propose to only standardize and restrict to "objects", and nothing more.

• It discourages people for doing easily abusing mis-use (like storing a full website on Kadena), by allowing them to store files like it was a new Google Drive.
• It allows the data to be used on chain too by another module, since they are standards Pact objects, not encoded files.
• It matches well with the main targeted use case, IMO, NFTs metadata which are always JSON.

As such, types are always "Pact objects" in the Pact world, and JSON in the HTTP world (gateway).

[trendzetter]

Just focusing on retrieving basic objects and leaving encoding or other attribute requirements and any implementation specifics to the application makes sense in a constrained environment like a blockchain.