I don’t know if everyone can, but I can. It might depend on trust level, but it doesn’t require admin rights AFAIK.
A point to note is that edits shortly after you post are not recorded. So correcting minor typos in the initial post escape!
4 Likes
Trying to make a clear distinction between the ideal (ignoring technical difficulties), priorities (like making sure the public/immutable/perpetual is working properly before looking at private/mutable data) etc. is helpful.
Also: on Discourse forums moderators can see more than normal users, like posts that are deleted.
2 Likes
Yes, this is a multi layered branching.
What are the goals?
What is the definition and scope of them?
The definition and scope of the goals will be very important, as to get to a common understanding of what is then a realistic path (technically/idealistically), and what the actual options are.
And as there might not be a full consensus immediately on what the definition and scope are, the possible paths can be in a super-position (unless there is some higher level path that can allow the different paths).
Also, might be that some interpretations give that not all of the goals are 100% attainable together, there might be conflicts between them.
This nature of things get unearthed at points of discussion like this.
4 Likes
I fully expect that if the previous versions of public data are kept in the network itself, there will be easy way to see them. This might create problems of someone accidentally mixing a previous version instead of current one and there may be only slight difference in these versions. Like webshop, where a product or price is a bit different. It is not the end of the world, but it creates hassle.
The previous version of the data is currently stored in almost any database. In fact the tendency is to use, more and more, immutable systems such as Event Sourcing.
http://www.odbms.org/2015/10/the-rise-of-immutable-data-stores/
4 Likes
This is true, in some sense, and I am for one almost only writing event sourced applications.
But I don’t think the tendency can be taken as proof that 100% immutability is desirable (not implying that’s necessarily what you meant).
You would never be able to re-encrypt anything if it was actually so. Well, you could, but it would be pointless, since old keys would still give anyone the old data.
And that is just one example of how immutability is not a silver bullet.
I might add that the event sourced applications are almost never using event sourcing only, but some other projection storage as well, for efficient querying. That storage indeed would be troublesome with immutability…
On the other hand, it is often possible to run in-memory projections. But the larger the streams, the beefier machines needed to process the streams in reasonable times, snapshotting not always applicable.
It would be limiting, but maybe an OK evolution of things.
2 Likes
Isn’t this just the same as “If I publish something on SAFE and then update it with a new version seconds later, I’m 99.99% sure nobody noticed it and will ever notice it…”?
I am also one of those still concerned (or at least wondering and trying to be as objective as possible) about not being able to delete private data, but more from maybe a technical perspective (or ecological?) wondering WTH we want to waste resources to keep/hold something that I’m not interested in keeping it, and that nobody will have access to, ever, specially if I simply throw away the encryption keys (so here I’m assuming that’s good enough to prevent access to anyone, including myself, and even in a distant future there will be no way to break that encryption with some alien tech. Will I care if aliens share that tech after I die?).
On the other hand I know there is no way to be sure that something private and encrypted is effectively deleted from the network when I requested to, so I do get that, at most, the network could create an incentive for vaults to remove what has been flagged to be removable. Perhaps the incentive is that if they remove something flagged to be removed by a user, such vault has more space to store something that it’s effectively being used and more likely to receive a GET request for, but this will also need some different type of farming mechanism where more used data generates higher rate of earnings to farmers (which from my understanding it’s not the current plan for farming rates and lotery). So there are clearly technical challenges here, but it sounds like they can still be figured out. So from the perspective of technical challenges, I’d agree on saying that perhaps we don’t need that for v1 of SAFE, but just consider and/or decide if it can be upgraded so users can flag private data (i.e. encrypted and not shared) as “deletable” and figure out a way to incentivise vaults to be more “green” (I also wonder if such a flag could be bad as it may imply it’s likely more interesting data to try to break the encryption for?).
12 Likes
I was thinking about same vulnerability, but with “hard reset button” of your autorization aplication you could lost access to your all data forever before torture. Or even better you will lose access, but somebody else will get new keys. Anyway I think, that 3 letters agenies etc. have some other options to get all information they want.
Another option might be that for such a situation, no single person has the whole key. In that case they might still feel comfortable with uploading the data, even though they know they will never be able to avoid getting that price on their heads by that - which they will likely have even if they all try hard to forget their part of the key. And the data will always be susceptible to the rubber hose attack. With mutability, the rubber hose attack could be protected against by deleting, or an increased risk (by leaks) could be restored by re-encrypting.
So the need for “revoking” keys is not exactly circumvented by the partial keys, more like, post-poned.
Hey, I really want to share these two poems from Polish Nobel prize winning poet Wislawa Szymborska. I think it is self evident why the first one, Discovery, but the second one On Death, Without Exaggeration, might need some justification. I feel that on some level it is against the first one, but most of all it is just a very beautiful poem that I cannot help but share.
I feel and hope that these poems help to open the scope of these questions in a new way.
Discovery
I believe in the great discovery.
I believe in the man who will make the discovery.
I believe in the fear of the man who will make the discovery.
I believe in his face going white,
His queasiness, his upper lip drenched in cold sweat.
I believe in the burning of his notes,
burning them into ashes,
burning them to the last scrap.
I believe in the scattering of numbers,
scattering them without regret.
I believe in the man’s haste,
in the precision of his movements,
in his free will.
I believe in the shattering of tablets,
the pouring out of liquids,
the extinguishing of rays.
I am convinced this will end well,
that it will not be too late,
that it will take place without witnesses.
I’m sure no one will find out what happened,
not the wife, not the wall,
not even the bird that might squeal in its song.
I believe in the refusal to take part.
I believe in the ruined career.
I believe in the wasted years of work.
I believe in the secret taken to the grave.
These words soar for me beyond all rules
without seeking support from actual examples.
My faith is strong, blind, and without foundation.
.
On Death, Without Exaggeration
It can’t take a joke,
find a star, make a bridge.
It knows nothing about weaving, mining, farming,
building ships, or baking cakes.
In our planning for tomorrow,
it has the final word,
which is always beside the point.
It can’t even get the things done
that are part of its trade:
dig a grave,
make a coffin,
clean up after itself.
Preoccupied with killing,
it does the job awkwardly,
without system or skill.
As though each of us were its first kill.
Oh, it has its triumphs,
but look at its countless defeats,
missed blows,
and repeat attempts!
Sometimes it isn’t strong enough
to swat a fly from the air.
Many are the caterpillars
that have outcrawled it.
All those bulbs, pods,
tentacles, fins, tracheae,
nuptial plumage, and winter fur
show that it has fallen behind
with its halfhearted work.
Ill will won’t help
and even our lending a hand with wars and coups d’etat
is so far not enough.
Hearts beat inside eggs.
Babies’ skeletons grow.
Seeds, hard at work, sprout their first tiny pair of leaves
and sometimes even tall trees fall away.
Whoever claims that it’s omnipotent
is himself living proof
that it’s not.
There’s no life
that couldn’t be immortal
if only for a moment.
Death
always arrives by that very moment too late.
In vain it tugs at the knob
of the invisible door.
As far as you’ve come
can’t be undone.
3 Likes
Toivo, I really liked them, thanks for that.
And also a very interesting way of broadening a discussion.
The last one, the last lines made me chuckle.
Death
always arrives by that very moment too late.
In vain it tugs at the knob
of the invisible door.
As far as you’ve come
can’t be undone.
It’s like a defiant statement: “Oh death, are you here. Well you are too late, because I have already lived and let live. That can’t be undone, so do what you’ve come to do.”
The first one made me think of the nuclear bomb.
1 Like
This is exactly what I’m thinking this last days. Ok, we’ll never sure that some data will be erased so we must deal with that. But we can take advantage of two universal laws, related to each other, such as the optimization of resources and laziness.
A node may not take the trouble to remove flagged data, but it probably won’t bother to send it to a new neighboring node if it can avoid it. And a new node will probably refuse to save data that won’t provide any benefit.
I call it lazy delete. In a way this data will fade slowly as the network nodes of a section change.
2 Likes
I’d make a comment here that if you upload an immutable file then by definition you have uploaded perpetual data. Now if you “lose/destroy” the datamap then that file is effectively destroyed.
But in agreement as far as the SD/MD/AD/whatever types are concerned.
This is solved by the fact that immutable data is where dedup occurs and without the data map any chunk is effectively unreadable and just wasted space till someone uploads the same thing then dedup occurs and the network benefits.
Of course the biggest issue is the question of public?/private?
It might be easier to step back a little and look at your earlier analogy of writing in the sand and how everyone who sees writing in the sand knows its temporary.
So if the SD/MD/AD/XD/whatever is marked as version-kept then its perpetual (private or public) and if not then its writing in the sand (private or public). This can be safeguarded from people marking perpetual one day then later on marking it as sand by only allowing the marking to be changed from sand to perpetual and no option to reverse that. Maybe allow for mistakes by being able to reverse it if the version has not changed AND noone has accessed it since.
You can.
The forum though gives a 3-5 minute window so any edits in that window are lumped together.
So for 3-5 minutes after posting you can edit and its not showing as any edits.
OR if you make an edit there is that 3-5 minute window to make multiple edits and it shows up as one larger edit.
Thus its not like what AD will do but half way I guess.
If you can truly modify private data then the solution to public data is to do like most systems (eg writing books, email, etc) and that is use apps that make draft copies “in sand” of your writing till you are satisfied its correct then publish (make public) the work.
@dirvine David, maybe the solution to perpetual data is to allow true delete and then have a billion monkeys on “typewriters” to recreate the lost files as public. 
5 Likes
Yes, because the network doesn’t know time.
But having a few minutes window during which an AD could be saved several times without creating intermediate versions would answer some objections raised in this topic.
1 Like
As you say. It did occur to me that would solve a few issues too, but didn’t suggest it because of the time factor.
Even the “if no one accessed it since” is problematic because of caching. But then again changing it to perpetual would invalidate any caches I suppose and could work. So rather than time have “not accessed since last change”.
1 Like
That’s right, good that you point it out, it is incoherent. I did mean the SD/MD/AD in the first part, but of course the second part about dedup is not applicable to those types (disregarding the possibility of AD just pointing to ImD).
So, to clarify, I am considering the ImD to still be immutable, and outside of the discussion.
And I might as well take the chance to point out that there was a bantering (if that’s the right word I’m seeking) tone to that long text of mine, it was late at night when I wrote it and I got “feeling” 
I often source interesting (to varying degrees) ideas late at night, and get more vivid in my expression of them.
It’s not so much that I think that view is necessarily a full picture, or the right way to see things, it’s more like “oh, oh everyone, I can feel it…! …here is a way to see it” and then I enjoy going into that thoroughly … FWIW 
1 Like
In all these discussions we may have glossed over an important question.
Its about datamaps, where they are stored and how to “lose” them. This is in respect to private data since once its public it cannot be reliably lost anyhow
There was talk a while back that the datamap would be stored in the last chunk written out for the file and a pointer to that would be supplied
Then there is talk above that it is stored in an AD
But in both cases the datamap of a private cannot be lost because it is in perpetual storage and remote chance it can be found by various means and then trawl through AD history.
Yes if you do not share your AD addresses it would be hard for a random person to search for it.
BUT I guess the real issue is that you can retrieve it easy enough by trawling back through your ADs and if you can so then can the authorities also. Very bad for whistle blowers and even for ordinary folk.
5 Likes
I second that. The fact that the network has from the start been planned to be efficient and not hog resources by using something useful such as PoR, deduplication, opportunistic caching, anti spam mechanisms planned for outboxes, etc were some of the main reasons I was initially attracted to SAFE. To keep private data after wanting to delete it would be a complete waste of resources.
The only arguments I could see against it atm would be if someone was left logged in and someone else deleted their data against the others will or perhaps the owner of the data accidentally deleted data because he or she drank too many pints and would like to recover it. Could be an opportunity for an app to have a recently deleted folder that only actually deletes after say 30 days.
Just some thoughts.
1 Like
@Nigel Providing the capability to delete private data might well cost resources, and could have other effects - on performance, security etc - so these decisions are complex.
6 Likes
It isn’t, because the previous versions in SAFE are open for anyone to fetch, when nowadays only Facebook can access the versions I have thought to be gone.
I’m quite sure that there are going to be easy tools to utilize all data that is openly available. For example a “show previous state” button in a browser etc. Perfect stuff for procrastination.
I understand the hurry to get the network published and I think it can be done with append -only data. Still I would like to see the possibility of true deletion of private and public data to be a goal, maybe for later developement.
This whole privacy / publicity thing is actually quite complicated. I was thinking yesterday, walking down the street, that everybody see me walking, I’m not hidden in anyway. Still it would be awkward if everybody would suddenly stop and start to stare at me. Privacy is not only about “not seeing” something, but it is about shared behaviour of “not saying out loud” something. Children often “publish” stuff that everybody knows but leave unsaid. Sometimes it’s funny, sometimes awkward.
I hope I am not rambling too much…
5 Likes