search

skalenetwork / filestorage

SKALE filestorage extension to EVM
GNU Affero General Public License v3.0
20 stars 3 forks source link

[SIP-3] SKALE File Storage -> Default Ownership Transfer on Action #91

Open TheGreatAxios opened 2 years ago

TheGreatAxios commented 2 years ago

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

DmytroNazarenko commented 2 years ago

Hi @TheGreatAxios ! This is really good suggestion. But both solutions also require changes from sChain side and need network upgrade. The changes related to precompiled contracts and storing architecture on the nodes. Our team will take a look on this possible solutions.

TheGreatAxios commented 2 years ago

@DmytroNazarenko Understood, that was my thought process as well. If your team has any "client" side solutions where the solution could be based off an external contract I will be happy to help in that process. Also happy to explain any thoughts in more detail if needed.

DmytroNazarenko commented 2 years ago

@TheGreatAxios There are several possible solutions that could solve the problem:

  1. We can make files immutable so anyone can delete them
  2. The "manager" contract can be the owner of the files and will handle the permissions for them, in that way the file interaction operations should be through this "manager" contract. And this contract can pass the permissions for the file from one account to another
TheGreatAxios commented 2 years ago

@DmytroNazarenko I think Option #2 is ultimately the best option

Just an additional thought here from the standpoint of file location; currently the path to an uploaded file is something along the lines of

https://SKALE_CHAIN_FS_PATH/[lowercase_user_address][optional_dir]//[file_name].[file_extension]

Would it possibly make sense to just use a counter as a replacement for the lower_case_user address if the files are owned by the manager? That way looking up a file is not linked back to a user but just a file or folder id on the manager?