Files are the chunks. There is no data type called a file. To delete a private file completely from the network you need to delete the chunks.
For public files there is an extra chunk stored that defines the chunk addresses and order.
Its simple, delete your local copy of the datamap
And to protect against your example which required you beating the thief to delete the chunks, the sensitive file uploader APP only needs to encrypt using your memorised pass phrase or account keys for that. Then thief will only have an encrypted datamap and useless to them and then the chunks (file) is encrypted again as well.
Its not that it would not work, but that you would be required to do a large redesign of the network and bring back consensus/state table/chunk lists/etc to prevent replication restoring the file on you.
Private file is defined by a datamap which lists the chunk addresses and the order they are in. There is nothing else stored on the network for that file.
So a private file <12MB is stored as 3 chunks. No more no less. You are then given a local storage of the datamap that never goes on the network.
Yes immutable. But replication of chunks is the basis of the current design. To delete a file completely from the network requires deleting the file (defined as a series of chunks - no more no less). So deletion works against the very basis of the network design
I’m kind of ignoring that because it’s not relevant to the perception problem that data can NEVER be deleted, so will affect the market for private data on Autonomi as that scares some people, and I can see why.
Yes data could be encrypted separately before uploading, but that’s extra hassle and more credentials to remember.
If it’s impossible to have flags in a location derived from the chunk, editable only by the uploader, and easy for nodes to validate without consensus while engaging in replication etc, then ok, it will be a trickier implementation… but I think it will still be a valuable one, if not a top priority.
In these types of networks with perpetual data web cannot delete data. We can update data (with no concurrent access etc.) using CRDT monotomic counter, like ScratchPad, Pointer and GraphEntry does, but @neo is correct replication will “restore” anything you think is deleted. It’s just a physics issue.
Even counter types cannot be deleted, the highest counter value data type will always resurface if a node tried to remove it. That is what replication will do.
So the best you can do is have a counter type device and always have the last counter (highest value). Otherwise you need to make all data “republishable” or be removed. Then you need timers and trust a universal clock etc.
We need to distinguish data, large data, like file content is in chunks. So not deletable, but chunks are very very secure. They cannot be removed.
Other smaller data etc. can be updated and old versions of that data, held in a pointer or scratchpad can be removed. It will and should be way too expensive it put large data content in scratchpads as they are an anti pattern in a secure, deduplicated p2p network.
I.e. use scratchpads to have deletable data and it breaks a lot of network promises for persistence and security. [also multi user access will be very poor]
I think many folk will do just that, but I think apps doing that will be considered bad apps and folk will not want to use them if they actually do want a perpetual web etc.
It seems by this you misunderstand what a private file is.
A private file has no datamap stored on the network. Thus a pointer is meaningless.
You are describing putting a datamap into pointer types just so you can delete it. BUT the datamap for a private file is NEVER on the network. The private file on the network consists of JUST the chunks.
Fwiw, deleting a file from a HDD/SSD drive also just deletes the reference to the data in a file too. It doesn’t wipe the data, as that operation is much slower.
Moreover, when you delete something on facebook, instagram, dropbox, etc, there is no guarantee it is nuked. They may just flip a flag or delete a reference too. It’s probably still in their backups, probably often still on hard drives, etc.
At least with autonomi, without the map, there is no feasible way to scan the entire network to find what has been orphaned. It’s vast.
I’m just joining in to comment on the likely solution that will come out - a version of the network in which all files can be deleted.
With Autonomi we have two amazing things - the ability for people to connect their free resources and store data forever.
But each of them can exist separately. Large corporations can connect their infrastructures more effectively, completely avoiding the end user’s resource - this will be one version of the network that we will see.
And another version will be one without forever stored data, but with a resource provided by end users.
All possible flavors and mixes will be created. We don’t need a Swiss army knife that does everything in one.
Then you need a map to know where those pointers are.
Aren’t you just reinventing the wheel here and still have to have a pseudo datamap stored on your local machine that holds the addresses of the pointers.
Why not just keep it simple and just have the datamap and no risk of anyone stumbling on the pointers and accessing your private file
I thought the fear was that there would still be chunks on the network after the delete? This would still be the case here, right?
Sure, you can add more indirection, more layers of encryption, etc, but the chunks will still persist.
For me, users/devs are free to add more layers if they want to. I don’t see how that detracts from the network or its current/default way of handling private data. I feel that is fine too.