Immutability - does it change everything?

There’s also this article by the same guy :slight_smile:

The idea is that people are less likely to upload dog poo when they have to pay for PUTs.

Can’t the devices communicately directly, node-to-node? Why use PUTs for this??

That’s an interesting question, but it seems like streams are already moving towards immutability on the Internet. For example, most twitch.tv streams are recorded and users can watch past streams (with the whole chat experience and everything) whenever they want.

The Internet is increasingly becoming immutable, it seems to me. Facebook stores everything you put on it forever, even after it’s “deleted”. The idea of immutability is getting easier for people to accept as they are becoming used to it from the internet they already know.

This is really interesting. A problem I see with this is that someone can download the data, make a slight change, and reupload it – the hash will be completely different. When your original data rots away you may be misled into thinking it’s gone forever. Again, we would be feeding wrong user expectations about what “deletion” means.

This scheme seems to seek to answer the question of how do you distinguish between stuff which shouldn’t and should be deleted (like temporary files). And to me, it seems like you can make the distinction by whether you chose to pay for the PUTs, or not.

12 Likes

Does it have to be a binary choice: data is payed for or not? Could there be different tariffs or could you get (part of) your money back when you delete your data?

1 Like

Ok, i thought that that thread wasn’t primary about storing the data (or deleting, thus freeing space), but rather about privacy (you can’t take a post back once published, even if you published it 30 seconds ago).


[…] sensors are churning out readings every 1/100 seconds. This sort of data will increase massively, but it’s dog poo: there’s surely no point in keeping it in its raw form?

you could eg

  • correlate it with other data, and generate new data by doing that. better data/resolution of the data would yield better results
  • generate statistics over large periods of time
2 Likes

Yes that’s another issue that needs fleshing out, but I thought it would be useful to take a step back go over the benefits (and limitations) of immutability more generally, as that seems to be the way things are going.

Interesting, I didn’t know that.

3 Likes

Yeah, maybe it’s just a cultural thing. Maybe we need to get used to things being public for ever after we posted it, we should think about the stuff we are posting before we are posing it.

4 Likes

This definitely is 2 different discussion.

It’s true, but not sure if it’s such a good thing, to be inspired by :slight_smile:
Also, the word immutability can be changed for anything in that sentence.

The idea of surveillance is easier for people to accept as they are becoming used to it from the internet they already know.

I don’t think Facebook practices serves as a good measurement of what is desirable. They might be doing some things that are good, and some not, but that’s like all there is to it.

And besides, wasn’t it said that it’s boring to do like it’s already being done :wink: (just showing that that argument isn’t really good, it can be used in all sorts of ways).

The heaviest and most real arguments I see is:

  • Focus on releasing sooner rather than later
  • Network economy shows (?) that the numbers add up.
  • (Possibly) Data storage advances show that this is completely a non-issue (do they?)

(mostly in scope of performance / sustainability)

First point is not much to discuss IMO, only the most critical features qualify as to allow delay of release I would say. One thing at a time is a good device.
Second point though… The one thing that can show if it is sane or not, is the numbers IMO. Do the numbers add up?
And it is about this idea:

It is one fragment of the wider idea about the network economy;
If people are prepared to pay for the PUT, then the network capacity will be there (provided by those who want the rewards) to

1.Hold the data
2.Serve the data

In a sufficiently performant and sustainable way.

So. Is it shown that it is sufficiently performant and sustainable? Or have we identified where it is not, and clearly stated why we comprromise it, and what is gained by doing so?

That would, theoretically, then solve the question about excess duplication coming out of immutability.
If people pay for it, then there will be resources to handle it.
It’s not that it isn’t producing wasteful garbage - it’s just that, if someone thought it was more expensive to set up another non-SAFE layer of security and redundancy for their indexes and current state, then they would instead pay for storing it on SAFE, and that means the resources to cater for it will be there, regardless. Because people will want the safecoin, so they will contribute the resources.

In that case, we actually don’t need to say Don’t publish dog poo now. Because the idea would then be, Dog poo or not, If you pay for it, then resources will be there to handle it. But of course, not publishing dog poo, might be related to a knowledge that it is a waste of resources. Just because you pay for it, doesn’t mean it isn’t waste.

So, if I know humanity right, CryptoKitties and crap consumerism will drain as much resources as always, and there will be duplication of data (draining resources).

The most important thing is that the network can handle it.
Because if the useful stuff can happen, well then OK, the “useless” stuff in a way also enables it to happen.
Next thing (a bit more luxury), is to consider if it’s possible to come up with a smarter design. To not do as it is already done (costs didn’t prevent CryptoKitties). And somehow technically make it less wasteful with resources for humans to indulge in their stupidities (as they always have and always will). That’s a fairly large and imprecise issue, so maybe not realistic to think about for a very long time.

To wrap it up, my question would just be about the numbers, simply: Are they solid? And I would think that is where effort should be placed, just to make them add up. And that would redirect the entire question about immutabilty, towards the network economy. Just a redirect on to that: “It all works, look at the numbers.”
The rest is mostly various levels of philosophy, politics and metaphysics.

EDIT: (I am focusing mostly on performance / sustainability aspect here)
EDIT2: One more very strong argument: Simpler and more robust code!

8 Likes

Again, we would be feeding wrong user expectations about what “deletion” means.

That is correct, but it is not black and white. You could have a mutable data implementation that is mainly focused on sustainability / performance, but could still have (slight) advantages on the privacy / security front.
Not having a guarantee that data you marked as deleted is immediately and completely removed from the SAFE Network (let alone that someone could have copied it before your deletion) does not mean that it hasn’t any advantage on the privacy / security front…

3 Likes

There is many benefits to these possibilities, but these are also the possibilities that can turn “thought-to-be-harmless” pieces of data into weapons used against you.

I wonder if the ID that uploaded a public data is published alongside the actual data? If it is, then it means that no one can upload the exact same data twice. I mean that if an ID uploads information that “The head of our secret police took bribes.” the metainformation of what ID uploaded it is very relevant too. Now if someone else copies it and uploads it again, the information will have different metainformation. But can the uploader ID be hidden in the first place? This way the person uploading this stuff could protect herself against accidentally revealing her true identity and correlating and statistics would be a bit less effective against her.

1 Like

It was a post from years back.

Immutable just seems too permanent for some data. I think the devs accept this by suggesting it is covered by local storage, but that only partially covers the use case.

For logs or some such, local storage may be fine, but what about an instant message? How about logs which may need to be viewed by others? How about safe quick file share with someone? How about stuff you would rather not be remembered (something encrypted, but requires temporary persistence)? Etc…

Clearly, IPFS and other technology have identified this as a common use case, as their tech stack is dedicated to addressing it. IPFS seems to be growing in use too. Why not just have a way to cheaply publish stuff without guarantees to immutability? Seems useful to me.

5 Likes

I think MaidSafe has suggested it is absolutely a possible direction, just that we need to take one thing at a time, and that thing can still wait. Even so far as: if community wants to delay release as to broaden the scope a bit, then it is also possible. But I mean, discussing this within the community, and how it can be solved, is still valuable work being done, which can be used later when it’s time.

3 Likes

I agree, but given threads like this are being created by moderators suggests the message is a bit murky.

5 Likes

I wonder if it’s not quite bound to be like that. It’s just a thought that hit me. Since there are so many possibilities, and unknowns of various sizes, and we all know we can’t say when things will be done - it’s been research and exploration.
So, to me it seems that it naturally follows, that it is equally hard to precisely say what the network will do, or what we can aim at. It’s quite possible that we talk about the future possibilities when describing the network, and that it isn’t at any time quite clear what of that will actually make it to the first release.
Then in the middle of it, there won’t be that much attention paid to things that don’t seem immediately necessary, so for example this question might not be un-murkied in the way that perhaps could have been. Not all gray-areas are delved into.

I don’t know, maybe it’s not like that, it’s just an idea I got.

While some seem to be waiting for the RFC about AppendableData before saying much, I for one don’t think it will cover the larger picture. I think it’s a much more narrow topic, I would guess it is more a technical specification of how AD should work. I don’t expect it to be about risks, benefits and drawbacks of immutability in a distributed autonomous data network (maybe I’m wrong).

Anyway, that could also be why it is maybe a bit “murky” still.

6 Likes

Hmm, i would rather say, it’s the other way around, their tech isn’t able do real permanent data. But they still advertised them self as “The Permanent Web”.

IPFS provides an interface as simple as the HTTP web, but with permanence built in.

2 Likes

Well, so much for a Twitter clone for now. :stuck_out_tongue_winking_eye:

8 Likes

Yes, agreed - that’s my point. We can do non-permanent data in SAFENetwork in a similar way, for when people don’t want permanent data.

It strikes me that it is much easier to work from immutable to temporal than the other way around - it is easier to remove guarantees than add them.

4 Likes

how this pans out I think largely depends on how the safecoin economy works. If you pay to store something and there is no limit on time, what is the motivation to clean up, unless of course you get some of that coin back.

To the point of IOT sensors: I think they are really not creating a lot of data. To store “the light is off” ever 100 seconds is really not that much data. Its just one yes or no variable. Can you think of an example of a IOT sensor that would be creating a lot of junk?

I believe the assumption was mutable data would be cheaper because it is something that doesn’t require guaranteed access.

The problem I see with any sort of flagging mechanism is that the network is not time aware. If you set it to remove flagged data when churning elders, or something similar, that could be a minute after you put the data there, or weeks (I’m actually not sure what the average time on this is?). If the network charges a user to upload a file they were temporarily storing to share with a friend, and it gets deleted a minute after upload even though their friend has yet to access it, that causes a problem. With no time awareness, there can be no guarantee of availability for any given period of time, so no one could trust the network to upload such data.

Perhaps a fix would be a two bit flag, one bit the user sets it to mark it as able to be deleted, and one where the network sets the second bit after it has already gone through one elder churn pass.

1 Like

Is there any reason you could not buy a block of mutable space (prolly for a higher price to cover the extra costs of it changing) then its just like onedrive or whatever… you can just keep reusing the space you bought as many times as you like but if you just can’t bring yourself to delete any of those bad selfies you need to buy more space :stuck_out_tongue:

also why would you not just buy this cheaper mutable space and just not mark things as deleted ever and hence have normal space for a cheaper price?

I think I misspoke when I said it is cheaper because it doesn’t require guaranteed access. What I meant by that was changes can be made to the data without having to pay the full cost to re-upload that data. With an immutable file, if you find you need to make changes, you have to then upload and pay for the full size of the file a second time. This could get pretty expensive, even if you only needed one small change. Whereas with mutable data, you could change one byte and only have to pay one PUT. The result is, with immutable data, you have all copies of the file in their original form. In mutable data, you just have the new file. The new possible approach other than mutable data is appendable data, which is kind of a mix of these two.

The thought of having a chunk of mutable data space that is purchased in large blocks is interesting in my mind. Perhaps a future release could add such a feature if mutable data ends up being the way they go. For the time being, they are just trying to get to a final release as quick as possible.

1 Like