SKALE Improvement Proposal 3
The Problem
When a file is uploaded to a SKALE chain, the owner is the individual who uploads the file. If that file is then used to support metadata or NFT data, what happens if the NFT is listed and sold or if the NFT is send or gifted to someone else? The answer is that the File still technically belongs to the original owner.
A Solution (Theoretically Simple)
The simplest solution theoretically, is to have a transfer ownership function within the storage contract that moves the chunks and locations to the new owner address. This would result in the highest level of mutable, yet irreversible file storage in existence. However, by looking at the existing smart contract that may not be a "simple" solution.
An alternative solution is to change how the data is pointed to initially. Currently, chunks are stored within directories that are by default linked to an address. It could make more sense to create files outside of directories by default and have them floating in a "bucket" or just the general mapping. From there they could be linked to an address or a unique identifier that could in turn be switched by the contract on transfer.
Examples
Additionally, regardless of the solution; a contract once again would need to have access to control this contract functionality so an NFT contract could make this call on a send or a marketplace could on a sale.
┆Issue is synchronized with this Jira Task
SKALE Improvement Proposal 3
The Problem
When a file is uploaded to a SKALE chain, the owner is the individual who uploads the file. If that file is then used to support metadata or NFT data, what happens if the NFT is listed and sold or if the NFT is send or gifted to someone else? The answer is that the File still technically belongs to the original owner.
A Solution (Theoretically Simple)
The simplest solution theoretically, is to have a transfer ownership function within the storage contract that moves the chunks and locations to the new owner address. This would result in the highest level of mutable, yet irreversible file storage in existence. However, by looking at the existing smart contract that may not be a "simple" solution.
An alternative solution is to change how the data is pointed to initially. Currently, chunks are stored within directories that are by default linked to an address. It could make more sense to create files outside of directories by default and have them floating in a "bucket" or just the general mapping. From there they could be linked to an address or a unique identifier that could in turn be switched by the contract on transfer.
Examples
Additionally, regardless of the solution; a contract once again would need to have access to control this contract functionality so an NFT contract could make this call on a send or a marketplace could on a sale.
┆Issue is synchronized with this Jira Task