Me too. In fact I think that public data must be anonymous perpetual immutable and only private data can be deletable. Easy to control and easy to understand.
2 Likes
I think we agree on everything, except maybe on this:
In my mind, the conditions are strictly the same between immutable data and structured data: in both cases you provide a public signing key only if you want ownership, meaning the ability to delete the data and additionally modify it in the case of SD.
Of course all this suppose that MaidSafe implements the 2 modes for the PUT command (anonymous mode and temporary mode). For this purpose I have added a comment in the PR.
1 Like
I agree there should be 2 types of data, one which is public and is immutable and can’t be deleted and one that is private and can be deleted.
1 Like
Actually the proposal is for the two modes be on any immutable data. I can see cases for deletable public data and cases for private being un-deletable. The choice should be upto the person uploading the data. The default for Public should always be non-deletable and private maybe have an account preference that the user decides for themselves.
- Public deletable - Just an example and I am sure everyone can think of a thousand themselves. Announcements for organising an event. Most are not required after the fact and the organisers may not wish to have the announcements public afterwards.
- Private non-deletable - personal “logs”, crypto address info, etc etc.
1 Like
In the actual proposal there are not differences between public and private data and that is exactly my misgivings about this RFC.
The original SAFE network was based on the principle of perpetual data and that’s was exactly its name at the beginning. This “perpetual” feature give to all the data a timeless value that goes beyond their mere content. Any data leaving, for future generations, an archaeological trace on our thoughts and experiences.
This is why I believe that all public data should be immutable and perpetual as we must not be left to the whim of someone is existence.
And in a more practical sense, it allows easier handling. Otherwise, manage data starts to get quite complicated.
The private data, it is, by its limited access, basically temporary so the erasable principle is consistent with its nature.
Concepts can change, or give place to better ones. For example, there was no coin and no payment, originally.
What if we abstracted the payment?
We don’t pay for the immutable block, but for a deletable “Claim” on a block?
There are 2 basic scenarios here:
- I want to store a new block, so I create a Claim on it, which gives me (or anybody!) the right to upload it.
- I find a block that’s useful for me; I want to make sure it will never go away (404), so I Claim it.
Blocks could still not be deleted directly, but Vaults would do garbage collection based on whether there is still a valid claim on the block. Basically, an Immutable Block’s “right to exist” would depend on the existence of one or more Structured Data blocks’ (of the Claim type) referring to it.
Claims would (could) be anonymous: they would have a “response” hash, and if somebody provides the “challenge” hash (which, combined with the block hash, would result in the given response) the Claim is considered deleted (I think imgur does something like this, if you upload an image anonymously.) I’m not sure if SD blocks can be “disowned” so idk if the anonymity is possible this way; I’ll leave those details to smarter people.
P.S. I wonder how this would affect the possible PtP schemes. We could have community owned resources, where all the people who were willing to pay to ensure the existence of a piece of art on the network would also share in the revenues coming from the downloads.
If one wanted to participate in PtP, then of course they would need to share a wallet address in the Claim.
As a response to @digipl’s concern: Refunds would go to the wallet address from the original Claim (if it was given), but one could (but wouldn’t have to) specify another wallet address as well.
1 Like
This could also solve the problem that people have been raising earlier about transferring files by sending datamaps: if someone wants to share a file with someone, they could now just send the datamap along with a new Claim. The outstanding Claim will make sure that the file will still exist when the recipient gets it even if the sender releases ownership, and the sender doesn’t need to go through the process of transferring ownership to the receiver directly.
1 Like
This is a very smart idea! Let’s say I want to send you some data. I let you know what the hash of my block will be, so you can pay (create a Claim) for it. I can now upload the data for you, because the network sees that this block has been paid for.
1 Like
With this system there are not pay by delete. Without incentives why somebody will bother in delete claim?
Why do you think that would be impossible? We could have a field for a wallet address in the deletion request, for example. (Wanna stay anonymous? It seems you need either a throwaway wallet, or you’ll lose your coins. Not elegant, but whatever.)
EDIT: If one opted in to PtP when filing their Claim, their wallet address would’ve already been specified, so not even this would always be necessary.
What about public data? This system can work with shared private data (in the end is quite similar that the original proposal) but does not solve the problem of get access to Datamap but not the Data.
1 Like
Idk why you think there is a problem with that. If somebody wants a block to be kept, they can pay.
If I want to make sure the Data that a particular Data Map is referring to will be there later as well, then I can pay for it (file a Claim); otherwise, I can hope for the best.
It’s not unlike how things work now: If I see a picture on the web, I may bookmark the link (semantically: “store the Data Map”) and hope that the owner won’t delete it (404). However, if I really care about it, then I will save the picture on my hard drive, which is equivalent to paying for persistence with storage space.
1 Like
One of the main concepts was to prevent 404 and make data persistent. The current model achieves this by acquiring the needed funds for upkeep by adjusting future storage cost. A rent based model would immediately destroy this feature and make safenet fail in the same manner as the current internet.
I thought it was privacy, together with persistence. However, I’m not sure persistence was defined explicitly in the context of “even against your will”; that was mainly a side-effect that nobody cared to make a fuss about, until now.
I’m not sure I get the point about the “adjusting future storage cost.” In case this is what you mean: Yes, it’s expected that storage costs will keep going down, and deduplication will for sure help some more, but again: having to keep around stuff that nobody wants anymore is more of a bug than a feature.
I’m not talking about rent. I’m talking about shared ownership and garbage collection.
Would you elaborate on this? “Fail” is a very generic concept, and I’m not sure there’s an agreement about the exact nature and level of how the current internet exhibits this feature.
Wouldn’t the need to “reupload” it be the same thing. Just the process streamlined, but still all the issues of needing ID keys “to claim” and any other fors/against of what is proposed in the RFC.
Do you propose that this is for every file that you would need to do this?
And sorry if you mentioned it before. New ideas are not always clear 
There is no garbage in public data. If private data can be made deletable i am all for it, but once sometihng is published publicly, it should be available forever. This is where current internet fails in a well-known 404 epidemic, and what we should fix.
To be honest, after reading through the RFC again, I’m not sure if there’s much of a difference 
I approached it from a different angle, and I think it adds flexibility (e.g. paying for a document somebody else uploads for me) and transparency (of idea) if we explicitly differentiate between the upload and the request to keep something. Also, my approach may include the possibility for anonymous ownership, but of course accounts are private by default and one can have many, so I’m not sure that’s such a big deal.
2 Likes
When nobody cares about a piece of data, it’s no different from garbage.
Why? Because there was a possibility that somebody may have looked at it once? This statement tries to be accepted without arguments for it.
I get what you mean, and I hate it when it happens. Here’s what I’m talking about: With shared community ownership, the payment a single person needs to make to store a block could go down a lot. Enough so that I can imagine that clients (browsers, etc) will implement bookmarking as creating such Claims to keep the document available: no more 404.
The problem is that while one can generate throw-away IDs, but you must keep track of them to be able to delete later on.
The problem then becomes that after a while people will, for sake of keeping track, use the same ID for many files. This then increases the risk of linkages and tracking.