Pre-RFC: Linkable Data Structure

If the public entry point to a “public data” is fragile, the whole network is broken, and I don’t think so…

Honestly speaking, I do not know this is the best idea/solution (linking data structure)… However, I am trying to solve the above shown problems; otherwise, in my point of view, the promise of an “Internet 2.0” using the current SAFE architecture is baseless.

The current state of the SAFE network is pretty solid to store data (ex: “Here, I have this file… store for me.”), but not to link the data together in order to provide base for a real “Internet 2.0” (ex: “I have this blog post, what are your comments? Here my blog post is linked to…”);

So what could be the solution?


True enough.

The SD data type is a later addition to the SAFE network and the first use was SAFEcoin proposal and that has core network programming to provide the transactions.

SD data was also for storing modifiable data.

Where I think the SD has not evolved enough is this very area, how can an APP use SDs and still keep sole control over the SDs the APP wishes to “own”. Its not a problem for APPs using SDs if the User is the owner.

The linkage issue is not new and the usual quoted solution is to have the key be the linkage, as was mentioned above. But that, as does system linkage, still leaves the problem that a hacking user can modify the SD or tell the system to scramble linkage.

That is why I suggested that if the problem of an APP losing sole control of its SDs that it wishes to (re)write/(re)link then any form of linkage can be implemented by the APP and/or (APP) library. So while SD is still evolving this is the time to consider these things and maybe ask on the RFC for SD data types. (not sure which but just look in the RFC subcategory)

Personally I would prefer to see the APP be able to have some sort of meta data where the network stores the required keys to SDs so that the developer can have their APP without having the keys handled in the code. Call it registration, or security key registration that the APP can indirectly use which is handled by the network. And if someone copies the APP or forks it, or otherwise modifies it then it is stored in a different file and the meta data with the security keys is not copied, so the fork/copy cannot modify the SDs of the original APP. The developer can of course upgrade/copy the APP and supply the security keys for the new version/copy to be stored/registered in the meta data associated with the file (chunks) when the APP is stored.

Remember that PUTs are not free. When it costs to spam, the spam doesn’t happen.

Additionally, linked lists are likely to be single threads of debate or data items. I would suggest that application designers encourage a new base node to be created more frequently than not.

There could also be techniques to link a latter node as a root node. Essentially, you could index a list in this way. Anyone could create these indexes, but maybe a moderator would be inclined to do so.

Then the issue will likely boils down to moderation of abusive/corrupted elements. I think anyone could suggest a moderation list, with the user able to choose one (such as the application moderators, owners, etc).

@Traktion true, but spam isn’t the issue here, it is malicious or accidental corruption of the key data structures. All sorts of potential motives for malicious attacks, and even if not free, very cheap because it doesn’t rely on spamming.

@neo / @knuppe don’t forget that smart contracts may provide the compute-with-authority function that’s needed to get around this.

Meanwhile, my own thoughts have been on social solution: crowdsourced / trust, rather than verified app authority. Both will have their uses.

I don’t want to take this off topic though, and my thoughts are still unformed anyway, so please keep the discussion going :slightly_smiling:

Sure, but we can ensure that data must validate before use. We can add checksums, hashes and so forth or define valid ranges etc. We shouldn’t trust any data which can’t be pre-sanitized.

Obviously, circumventing loads of blocks of data may be less efficient, but there will be a cost involved. If every client indexes the lists, the padding will be skipped past after first try.

Ultimately, client applications should be intelligent enough to index/cache, cope with bad data, etc. They could also look at other indexes created by moderators (essentially, cloud moderation).

I am somewhat concerned about the performance of traversing large lists, but indexes should help a lot with this.

If you can solve this issue please step forward! It is currently beyond me - not saying much I know, but you can’t say that and leave us wondering :stuck_out_tongue:

1 Like