Nopes. That is wrong. There is nothing, in current proposal, that can be deleted.
So, again, the datamaps needs to be stored somewhere. If it is on your own disk, well, that is basically the same - with regards to security and robustness - as if you had all your data there. The benefit of the network is nullified.
So you store them encrypted in the network, but then you need to go between these two ends:
granularity; encrypt each datamap, so that you can forget that key as to “delete” it.
Or you can have it all under your login (that is something you can actually remember, as opposed to datamaps), so when you want to delete one thing, you need to forget the login, as well as copying all that you want to keep to a new login.
This has been a massive discussion to follow, and I believe that I finally grasp it. Funnily enough AppendableData is about what I thought SAFE would be at the start but this discussion has raised interesting points. I’ve also thought many times about the possibility of a ‘rubber hose attack’… the endpoint is likely to be the weakest of the network. One advantage that hadn’t previously occurred to me would be that an attacker, even with control of your account, could not delete your files as you could merely use a previous version to recover them. So they may be copied, etc. but there is no way for you to lose access to them. Hardware security like Fido-U2F on e.g. a ledger seems almost a requirement for the network, especially if you use the deniable second layer.
I buy that increasing storage capabilities will exceed the growth of data on the network. Particularly if publishers are smart about how they use immutables and the pointers to them to minimize the size of updates.
I would think that having MDs with true delete is easy enough. Delete could be simply zeroing the data and can be rewritten over rather than an append done. Sounds easier than the other. If you encrypt the data in the MD then noone can read it anyhow.
I definitely do see some advantages/usecases for having a fully mutable scratch pad, a la truecrypt container. Some of these use cases are highly relevant to some core SAFE missions… such as for things like email or deniability… imagine a datamap to documents or safemails about government corruption: the map could be shared and then deleted, with no way to prove it was you, even with an account compromise which would otherwise reveal you through AD versioning. Simply delete your account password and various governments will put you in jail for refusing to divulge. And what if you spam someone’s safe inbox with incriminating stuff? Wouldn’t you want to be able to delete mails like that?
It could be relatively easy to implement, particularly if it is of constant size, e.g. always a 1 full MB chunk reserved on creation. Updates could then take the form of binary diffs / zeroing with no need to save versions. Perhaps something for later, but then again if it is a small container, then storing each new iteration should not be stressful for space. I do think though that part of SAFE is that you aren’t scared to put things on it or use it to its full potential. Immortal things are immortal, but there will be bad actors who use use the network in ways difficult to fully map out, and having some control over what others try to send to you via apps etc. seems more comfortable to me.
You mean something like Rc (reference counted value), you count the number of references to the data, if it fells to 0 you can remove the data. There’s are problems with that:
you can have links in others systems, like the current clearnet referencing some images or scripts on the safenet (like a package manager eg npm)
not even the safenet can see those, if the references are encrypted
For simple device only local tmp data, as i already have written: use an encrypted local partition, which key is randomly generated. On logout you would “forget” the key, and make the data unaccessible. As long as you are logged in there will be a connection between your device and your safe account, so there is nothing lost by storing tmp data locally. Storing that data on the network would be relatively speaking really slow, as network is slow compered to local file access.
I guess, what he’s saying is, that the data is separately encrypted (not self encryption), thus you would be able to change the encryption key (your safe account password), making the old data (encrypted with the old password) not directly accessible.
We did look at that previously, the list could be billions of entries watching a chunk for popular data. So the management is larger than the thing you are trying to delete to save space. Each reference will be min 1/32 of the chunk size, then managing that data is again hard, the vaults need to check the person saying delete is actually the person who uploaded it. Then you can have an attack where I somebody just adds themselves as a reference and deletes their own id. So no delete ever, but more management of the chunks etc.
Yep, that’s what I was suggesting and what the encfs library could easily allow. Although I think deleting the partition when finished would be cleaner.
I’m sure there are other alternatives too. and @neo’s idea of using MD’s in the account blob would work too, but maybe slower - although would be less temporary (and would travel between devices) which could be a plus for some things.
I’ve never seen this other account blob.
From what I have seen, the account blob is today an MD, and if MD is replaced with AD, then that would be immutability with current proposal.
But if it is truly like this, that there is yet another type of data, that can be deleted, well then there are some more factors to it all… Can’t say yet how I would recompute that info. but I’ll be back
You add one password - it encrypts stuff.
You add another it derives the location of the encrypted stuff.
You pay a bit of safecoin to store in that location and store your blob there. (you cannot store any old stuff, it is restricted and not shareable).
Go to any computer with those two passwords and you are logged back in with your keys and root dir all there for you.
So that is it. The stuff, is a blob, obviously it is things like keys and such, but also at least your root data map, which you may have several. So you have a bunch of data that is accessible from that root dir. If you then kill this block or just don’t ever request it then all the data from that root is inaccessible from anywhere, unless it was public. In that case it is all still there. All your private data though is gone.
However, i am personally a bit confused when we say data once published cannot be removed. Hope this does not mean that if I post a comment in safenet forum for example and want to delete it, that I cant do it if the forum is on SAFE network. I hope thats not true - if yes, this needs to be thought through…
With the current implementation it would be like everything is a part of the wayback machine / internet archive. So you could remove / edit your comment, but it would still be recorded and part of a public archive.
Let’s face it, your deleted/edited comments are already treated like this. It is just that on services like facebook, only facebook have access to them, not everyone.
Also, mass surveillance ensures that such deleted/edited information remains accessible, but exclusively to entities with the resources to collect and store massive amounts of information.
So the different with SAFE really is that it gives everyone access to the history of public information, not just powerful bodies.
I think there should be some flexibility around it. Its not always about imp data that can be sold. There could be numerous other instances where I may want to delete something I posted 10 secs ago and repost something else.
I agree - and I do see both sides of the argument. But permanence is something I’m not entirely comfortable with and the success or otherwise of SAFE in this regard will be in the implementation.
In nature nothing is permanent. We all forget things, or blur them, and sometimes for good reasons of psychological wellbeing. Things die and are forgotten, even stars and planets. People should be allowed to have their transgressions forgiven and allowed to fade into history, otherwise the judgmental and the control freaks could end up having the whip hand, the opposite of what’s intended. That said, I once thought the arrival of the web would force politicians to be honest, or at least consistent, since all their previous utterances would be recorded, but in fact the opposite seems to have happened.
But I do feel people underestimate and possibly miisunderstand the implications of data permanence. It goes way beyond the technology and the ability to delete a drunken tweet, that’s for sure. It’s something that requires a wider debate and should definitely not just be left to technologists. Maybe MaidSafe could start the ball rolling?
Exactly this is what I’ve been saying @JPL.
There is a deep philosophical implication of this, that transcends convenience of non-broken links, maybe even that of secured history (which is a pretty big deal IMO, just imagine all knowledge that has been lost in various epochs).
Completely agree. Specialized people are pros in their area. When building or inventing things that might change people’s life entirely, the way society works etc. it really would be super important to at least try find experts in relevant areas (what would that be, sociology, anthropology, psychology, philosophy…?) that can be part of the design process.
I can’t imagine any of it to be other than immensely difficult anyway though.
Users will affect i important implementation details such as this through their adoption / shunning of the network or rather its different functions: private storage versus public sharing for example.
So while I share some of the misgivings, I’m not so concerned about them at this at stage. I’m interested to see what a perpetual Web will become through the choices users make about how they utilise it.
For sure we cannot fully comprehend yet how a pWeb would make us evolve and what the exact impact and transformation of societies will bring, I’m just now thinking (after reading your last post @JPL), that perhaps the pWeb could help us in being more humans, in the sense of accepting us, being upfront when dealing with our mistakes and bad decisions, we are really scared of being exposed in perpetuity with some bad decisions or acts that we cannot remove from people’s memories, like it would be with a pWeb.
But what if that will actually force us all to be more humans and more understandable of our extremely non-perfect nature, we always make mistakes and usually the problem (as you say) is the judgement rather than probably the result of our acts (ofc this is a case by case thing), what if we become more comfortable with being able to say “yes, that was my post 10 years ago and I do/don’t regret it because…” and everyone understands since we all could end up in the same situation with our acts. In fact, don’t we feel a relief (sometimes or some of us at least ) when we can say “hey I’m sorry, yes it was me making a bad decision” and knowing the rest is aware of you recognising it rather than hoping they forget it. Anyways, it’s all to be seen. Just thinking out loud
We all ask for the truth of things, are we ready for it?
This could be done at the app level. For example, in our SAFE Network Forum we have a 5-minute window to modify a new post we just created. This feature could be reimplemented by a discourse like app by buffering a new post in a mutable data and moving it in an append only data after 5 minutes (or any other default delay chosen by user).
Creation of mutable data and then append only data is done by the app, but the network offers natively the following features:
Other users are not able to see the post during this window.
The user can delete the post during this window
Note also that if the app is closed during this window the countdown is naturally stopped. The user needs to relaunch the app so that it can move the post to an append only data.
