Appendable Data discussion



In fact it is up to the application to store objects directly in a MD or to store pointers to them. For example WHM stores “File” structures directly in the MD corresponding to a directory. This structure has then a pointer to the datamap pointing to content of file. So we have a mixed situation in this example.


Well then the issues can will still arise to varying degrees depending on the application. But still a double access to get data that is “stored” (well referred to as stored but not actually) in a ALD. Only if the APP stores the whole data in the ALD is it a single store (then its an AD I suppose)


Interesting! So they can be/are used as general purpose indexes to immutable data items.


Ownership isn’t the same as authorship. Proof of authorship should always be based on a cryptographic signature, not on a public key record. As long as software devs understand this and properly implement it in their applications, there shouldn’t be any confusion about that.


Agreed, completely. Also though

safecoin can change ownership no prob as there is no data (no list of entries). Take a website pointer though it points to a series of different data maps. If there is then change of ownership of this website location, then we change the owners keys, no prob, even multisig is fine. However nothing stops us forcing that list entry to point to the ownership change data. Therefore the list can show ownership change at points in the sites history etc.

Of course many ways to do that, but as an example this is valid. The RFC should be great if it comes soon as everyone is primed to find bits to be used against the network, so this is perfect timing I suppose.

The authorship is very important as well and not something we have really answered yet. It is worth thinking more about.


Ok, I did not know that. Is the possibility to see earlier edits restricted to the administrators only, or can anyone see edit history of others?

That is OK when you know in advance that you are wanting to hide your personality. I’m talking about the cases after the fact that you have published something that you realize would have been better to stay out of public. Now I hear you and other saying that once you have published something, you can never be sure that it can be hidden again. And you are right of course. But while you can not be sure if you manage to hide again (if someone else has seen and copied it), neither can you be sure that someone else has actually seen and on top of that copied it. Well, in the case of Oldnet platforms, you actually know that it is copied somewhere, but in principal that would not have to be the case.

Another thing, are you even planning to have accesses to data like “Shared with 20, which of 15 can only view and 5 can modify”?


Initially it would be shared with 20, viewable by 20, changeable by 5, if that makes sense. Again though viewable by 20 likely means public in many cases.


Ok, but is this in plans? It’s not only about me trying to cirmumvent the current design, but about having a platform where people can collaborate and limit the damage of the less skillfull collaborators (or clients of the team etc.) can do.

One more thing about hiding the public data, and then I’ll stop :wink: The reason why I’m arguing is that it is very different to have something that everybody knows being held in public or not. While in general it is good idea to make that kind of things public, that is not always the case. For example, as a young kid I sometimes participated in bullying. Once I invented a clever way to mock a boy. I invented a kind of “riddle” that was very catchy and allowed some creativity for anyone willing to bully this other kid. I regret it deeply now, and regretted it already back then soon after releasing it, as I saw what it did. I cannot take it back, but I have made a decision not to tell it anymore to anyone - in order to try to save him from having to face it ever again. For example, I’m not going to tell it here, even though the chances for the damage to spread from here to him are very slight. I see this comparable to the situation, where the way of bullying would have been publishing of a photo, for example. Everyone has seen it, but it is still different, if it can bee hidden from public. Even if everyone has copied it to themselves, it is still different from having it public.


But that isn’t going to happen with many forums and their replies and many blog entries.

The ID used to post will be taken as the ID.

Then I can fake that.

Yes you could take further steps to make the person sign each reply, but will the APPs do that step?

BUT the real issue is as David mentioned the web sites. There has been no mention or requirement that each web page is crypto signed and you have potentially 10s of millions of people creating their web pages and I bet bet you that only a few smart ones will do it, and maybe 20% will use helper Apps that do it for them.

So the ownership of the web pages will be taken as the owner of the ADs that point to the web pages.

Thus ownership is very important.

Now if we do as David suggested and somehow FORCE this ownership info to be stored with the web page itself then it could be done. But there are holes in that so again the history of the ownership of the AD will play a critical role in PROVING the authenticity of all those web pages and some/many blogs and forum replies using forum software that doesn’t FORCE crypto signatures on each reply.


Moving from MD to AD, rather than a change, seems to be the confirmation of the fact that never existed a real deletion option on MDs. The truth is that it doesn’t surprise me because everything indicated that the Devs tended inexorably towards the immutability of the data.

I wait for the RFC to see how the data is defined but it is also true that it opens very interesting options to advance towards a Strong Eventual Consistency model.

The discussion about AD has relegated other news, tremendously important, such as the change to BLS signatures, which can place the network at another level, and the solution to make Parsec truly asynchronous. I am very happy to see Andreas collaborate again, even temporarily, with Maidsafe. The truth is that I was following his work in POA, via Github, and I was always wondering if part of this work, in implementing Honey Badger, could not be used also in Parsec.


Just to expand a little on the Safecoin privacy/anonymity discussion, with the current proposal for the user experience.

In case it isn’t clear: all Safecoin transactions are private i.e. there is no public ledger, or list of entries. When I trade a Safecoin, I send it to a wallet address, and the receiver can see the address it came from—but no-one else.

As a SAFE Network user, I have a few options:

  1. I can directly associate a wallet with my real identity via a (human readable) WebID.

  2. I can associate a wallet with a pseudonym, via a WebID. Remember, I can have as many wallets and WebIDs as I like.

  3. I generate a re-usable wallet address. This would be pseudonymous, but could become associated with my real identity depending on my pattern of use.

  4. I can generate a single-use wallet address, which as the name suggests, could only be used once, for a single transaction. It cannot be associated with a WebID.

Option 1 is likely to be the predominant use-case (although not the default) as in most cases, financial transactions are far more useful is the send/receiver are easily identified to each other.

Option 3 is likely to be the default—liking a wallet address to one of your identities via a WebID would be an intentional opt-in function.

Option 4 would be the most anonymous option. I say “most anonymous” as anonymity, in reality, comes in degrees—It could be rightly argued that it is still pseudonymity. But the practical case for fully anonymous transactions (an Option 5), where the recipient is only aware that their balance has increased and the sender is unable to keep a record of where they sent funds, is limited, and difficult to achieve. We may get there (and I have argued the case) but in the first instance these four options will still be a huge benefit.

In practice unmasking could happen in Option 4 by having your account compromised (like a rubber hose attack shudders) or via some elaborate honey pot. And with the later, a fully anonymous Option 5 wouldn’t help, as the honey pot could be tailored to that scenario, or your device could be compromised with a key logger or some-such.

Perhaps this Safecoin related discussion could even do with its own thread. Might make things easier to follow, and contribute to without getting lost.


Once again it depends on if the owner ID of the AD is considered to be a part of history that needs to be kept. If history of the owner of the AD is kept then your above analysis has to be changed.

Granted an exception could be made for the safecoin tag type and probably would be, so then your analysis is correct and agrees with what we always believed.

Perpetual data requires the owner of the data is known for what I hope is obvious reasons.

Now the only solution given by others is to embed the ownership of the data within the data itself, but that is as bad as security by obscurity. And it won’t happen enough to consider it happening much at all.

So then we are left with the obvious and that is keep a history of owner of the AD along with the AD history.

Thus for the obvious correct operations of safecoin (as outlined by yourself) safecoin will need to have an exception of the history of ownership. Not a bad idea anyhow since safecoin will have to be treated differently in the processing anyhow.


I don’t think there is any intention of associating an owner with a Safecoin by default, it would only be via a user expressly and intentionally associating a wallet address with a WebID.


Missed what I was saying. I agree there is no intent.

BUT if the general case of ADs require a history of AD ownership to be kept in order not to break data perpetually then an exception for safecoin will have to be made.

And my years of data mining inform me that ownership of the the data object itself is essential for data perpetually. Especially in the context of the fundamentals of the SAFE network (you know truth which includes who originated what)


Again, the fundamental refers explicitly to “public/published” data, which would would exclude Safecoin, as this is expressly private.


If you read above David said for that all data has to be considered public since it could be made public at any time and the data perpetually would have to apply to all data.

So all I am saying is that safecoin will have to be the exception if history of ownership is kept in general.


Not important, but why is this attack called ‘Rubber-hose’. ‘Torture’- or ‘coercion’-attack was probably too simple. Or is it because a rubber hose is a versatile tool for such things.
This well known picture also makes clear what is meant with the attack:

Another side note. Sometimes necessary to remind us of the basics:

  1. what are the requirements to run safe? like a few MB RAM/HDD?
  2. for privacy: just do as encrypted swaps on linux (1. get the encryption key from an RNG 2. mount an encrypted filesystem as the swap partition 3. “forget” the encryption key on shutdown, or in this case whenever you want, eg logout)


So much of this debate revolves around “we can’t delete data because in order to do that, data must be linked to an owner”. That doesn’t need to be the case though does it? If data is marked as “deletable” we know we can’t “trust” it in perpetuity. However, with the deletable tag and a zero knowledge proof where only the owner has the proof answers, it could be deletable correct? The actual data, not just the map, then you can delete things even if shared with other users.

After writing this, now I’m wondering if this messes with deduplication. I guess that’s the next snag?


Yeah, if we use a “perfect” encryption that is absolutely bug-free and can’t be broken ever (quantum computing).

also how would “DNS” work with AD? With MD you we could hash the name, then use the hash as the network id for the MD.

Maybe it should be hidable at the app level then? Facebook is also not deleting anything you post, they just hide it from you. (at least that one copy, anyone else could just upload their copy of that image)

How is this possible, SD is content-addressable, so there’s no way to publish different content at the same ID?

I would just store the pointer to the newest version of the A(L)D at that time, so it would need to iterate just from that version to the current version, also it would be following the A(L)D links, so no real data would need to be processed.

It would even work with ID only for the data structure it self, by storing it as a DAG (git is doing that).