Appendable Data discussion

appendable-data
immutable-data
mutable-data

#181

security through obscurity is not security at all.

And similarly by placing the history of ownership occurring on the APP playing nice is not universal perpetual data as is required by the fundamentals.

No they don’t need to be signed and that is the whole point.

Without web pages having a history of ownership then I can create a very damning (lies of course) set of pages and then change the ownership of them to you.

Now in the pages I write it as if you wrote it using your name etc. Then change the ownership of the ADs to you. Now without history then in 5 years people assume, rightly, that you wrote it. BUT if history of AD ownership is kept then the truth of the matter comes out. And that is what the fundamental is aiming at.

it does not matter if the entity behind the original owner ID is known or not. It just allows the truth be known that it is not your normal ID that did it and so is unlikely you since it hopefully is out of character for you to publish such things


#182

I’m not entirely sold on this argument. I would like to avoid lying to users, even if it’s a lie* that’s “comfortable” for them and what they want to hear. Ethical issues aside, misleading them could lead them to misuse the network and make the same blunders they made on the internet. It’s like the message you get when you open Tor: the software isn’t enough, your habits and mentality have to change as well if you want the full benefits that the software provides.

*Maybe “lie” is too strong a word, but in any case, I think we want to avoid users losing trust in the network. E.g.: “You told me I could delete my data, so why is it that insurance company X still has my medical records, and my friends still have my nude selfies?”


#183

Yeah, sounds more like a RISK Network (Regret Infinitely Single Klumsiness) or TRAP (These Repercussions… Ad Perpetuum).


#184

It’s not really a lie, though. It’s a guarantee that you have the ability to delete the data you uploaded. Perhaps someone else already grabbed it and will hold onto it in perpetuity. That’s a bummer, but it’s pretty likely they will not reupload that into a public space as I doubt most archivists will want to pay the SAFE Network fees for uploads. There’s still a chance no one grabbed it, and you can just delete it, no harm done. So it is a feeling of comfort that “out of sight out of mind” sort of feeling. It is unlikely the user will ever know if someone grabbed their data before deletion, so for most, they can go about their day with a little less worry. At the worst, they were able to pull it off a public location directly tied to their account, so it may be harder to identify the item with that person.


#185

The data hoarders can just store data locally for pennies and continue to data mine it etc., though obviously to a limited extent compared to the internet.

This argument is not very convincing. I’m far more worried by the accidental-uploads concern you raised above.


#186

I disagree: archive.org “has an annual budget of $10 million, derived from a variety of sources: revenue from its Web crawling services, various partnerships, grants, donations, and the Kahle-Austin Foundation.”

Should history be kept by those who pay to keep it, or should it be kept by default with everyone fully aware of that fact (and behaving in ways that account for that)?

I understand mistakes get made. Maybe that’s a good case for an in-between hot-storage layer, and SAFE is like your cold-storage layer (just spitballing here). I don’t think there’s any good examples for adding a delete function to the only network that offers truly permanent storage. The only network. Permanent.

Bitcoin can be used to buy drugs so we’d better change it… it’s the same bad argument.

Same thing with ownership vs authorship and switching ownership. If everyone knows that it’s trivial to change ownership without their permission then it doesn’t matter. Nobody assumes the owner is the author. That’s just a fact of how it works and anyone making that argument would be immediately discredited.


#187

But it still breaks perpetual data model as presented in the fundaments and the talk David recently had with @fergish

Also researchers years down the track may not be able to know what is attributable to which person because the mob on one side of the story (victors) are writing articles as if it were the losers and actually rewriting history due to the volume of articles they can write. This is what we have today with books of the wars in the past. We only end up with the victor’s side of the story being written about. And supposedly the losers saying similar things reinforcing the falsehoods.

If the original author of these articles can be establish (part of perpetual data) then the truth is easy enough to establish and trustworthiness of the articles established.

And this does not prevent publishing anon since the author can use a throwaway ID.


#188

I agree we need to disambiguate this.

We have perpetual data - it may have authorship claimed via signatures etc.
Then we have who published what?

This last part is a separate issue and has many side effects to clean up. I showed earlier a simple way to show what key published what web sites, for instance. That is quite easy, but who owns what key is another issue. SAFE allows that part to be private and anonymous. however large corps will surely identify themselves by publicly showing they own a key/id. Just as they do now with web sites and DNS (sometimes signed by a key). So this is not as hard an issue as we think, but attributing published data to an actual person is not easy (good), but attributing it to a key is easy (good).


#189

I think you are either missing a point or I have made an invalid point somewhere :wink: Either way @mav is right the uploader/publisher is not necessarily the owner, these are different things. The publisher id can be made permanent as I said above, but only the key, we need other ways to say who the key belongs to.


#190

Yes you missed my point.

It is very important to know the uploader who is the owner of the AD. At no time was I equating owner of the AD as the author of the article or even the owner of the ID. They may or may not be the same. And as you say people will often associate one of their IDs with themselves, especially if they are publishing.

If I can see the history of owner of the AD then I can attribute trust or no trust to the contents. Or at least determine with some confidence if the article is falsifying truth or adding to truth.

Without this knowledge of the history of ownership of the AD then I can falsify who wrote what and that breaks the desired perpetuals

But that relied on APPs/people doing the right things and we know from history this does not happen often enough to be worth while and becomes another case of thinking obscurity gives security.


#191

Ah no, I see the issue. What I was meaning is that to change ownership there would be a an agreement. So the change would require the new owner signs the old owners key (accepts exchange) and the old owner signs the new owners key. That can be done via an RPC the vaults recognise to change the key. So not possible for somebody to just swap a key to any other key, the receiver has to agree.

In any case that only means no false attribution, but does not say who the publisher is, just that key X published Y docs/sites etc


#192

Yes that should work. But how to implement this for ADs (has to be all ADs except safecoin ADs) since I can make a private document then upon transfer of ownership it also becomes a web page by doing the necessities. But articles/books are not necessarily webpages either since making a vid full of lies can occur. So a general thing for all ADs.

But how to allow transfer while I am asleep and the other is awake? You would need it to be a 2 step process and delays obviously occur.


#193

Well not all, but safecoin if it is an AD is tag < 10000 so it can have different params from those above 10,000 (vault special tags). However there is a few things here

We can define a publish tag type (say 7) for DNS which says which services this “dns” type has. Those can be agreement based.

Agreement types will need to be made clear and perhaps these are default to begin with.

On that, there is a few other issues, we can on SAFE ensure data is actually deleted and even real time editing of live data, but all for later. The issue I see is two fold, 1: Launch fast, 2: the paradox of choice.
The latter being a big issue for confusing users and devs. Of course all devs want everything immediately but best to start small and build. I suspect this paradox of choice has slowed us down to launch. So if we get a minimum AD type that covers most use cases then get apps to build on that, if apps can provide delete/edit etc. then great, otherwise we force the network to provide it. I hope for the former though as the simpler the network is then the more secure it will be as well as launch faster. So this is why these convos are great, so see how much we can get and miss from forcing simplicity first and squeeze everything from that.


#194

No the issue is for any data (except special types like safecoin)

A web page can link to the AD (datamap) for a document that is not a web page.

So it has to be for any data except some special types.

Yes, but I suggest a laid out plan first for those changes so that people know what will be implemented and thus can be happy with small beginnings


#195

Yes I agree, that is why the guys are working an an RFC while all of us are throwing ideas around :wink:


#196

Although history of AD ownership is such an easy things to do. Just include the previous owner in the appended field’s data structure.


#197

I’m not saying permanent storage shouldn’t exist. I’m saying having everything as permanent storage is a mistake. It actually curbs creativity and free thought because people will be self conscious about every single thing being around FOREVER. Appending data would be great for scientific research, Wikipedia, etc. It’s not so great for every single purpose under the sun. Having no freedom of choice with our own data is a network killer. I strongly believe that.


#198

It can be a bit difficult to see where all this washes out, so I’m going to give my understanding of the conversation and maybe someone can confirm or correct:

My understanding of how the function was developing is that Immutable Data is there perpetually, as is, at the address equal to the hash of it’s content. Access to that is only possible by someone holding, or having access to the data map for that IM. No change here.

To put up a web page or site, Mutable Data could be used to point to IM and other MD, basically exposing the data map to each. An owner of the MD (whether solo or shared ownership) could change the “site map” MD and add, delete any or all the referenced links, even deleting the whole site by zeroing the MD. Deleting a link to other data would hide it again as far as that link is concerned. If someone copied the data or retained the data map, they would still have access to it and could pass it on to someone else or make it public elsewhere, but that is a situation that is never going to change, I think. This allows someone a high degree of control over who views their data and how long it is exposed to access. If they accidentally publish a data map to content meant to be private, they could change the MD site reference and minimize the damage, much like is done on twitter, etc., at least from the users perspective.

Appendable Data enters the situation of making even that immutable, but appending changes. If one wants to hide references to other IM or AD, the correction would be made by adding the change so that the desired result would be exposed by default. Though it might be less than trivial to explore and reveal the history, it’s there and accessible via the original MD forever.

Am I wrong in understanding that all that has then been publicly revealed at any time is then publicly accessible forever via that AD? I mean, that’s the point of perpetual data, and it still is true to a large degree with MD. It’s just more complete and history of it all is discoverable right there with AD. It doesn’t mean that a mistaken post that’s changed will be more obvious with AD, just more discoverable after the fact, even if no one saw it in the first place.

Aside from the technical execution advantages/disadvantages, does that pretty well frame the key points at issue?


#199

That is correct. The point about mistakenly exposing a datamap that was meant to be private is a good point and one that people may have to live with if AD is the final solution.


#200

Yeah. It is something to be cautions about, but it might be a good teaching point. The current situation is actually a lot worse if you think about it. Would be a good point for app devs to put in “Are you absolutely sure you want to expose this data to potential public access forever?” as a standard publish step, a step that is not too easy to turn off. Should bring about more responsible usage of data sharing. I bet there are plenty of teenage SnapChat users that are going to wish they’d had that warning put in a way that they didn’t easily dismiss.