RFC: Dynamic Data Support

Development RFCs
1

A new Tag-Type appendable by anyone. Let’s see what the experts say

5 Likes
2

Not sure if I qualify as an expert, but the drawback mentioned in the RFC seems too problematic to me.

Also, if we want open-to-all SD’s, why not publish the private key that owns the SD in question inside the SD data field? Then we don’t need core support for a special SD type.

3

At first I feel the same. Many problems and few benefits. We await Devs. answers.

To prevent anyone, except the creator, can erase the SD.

4

For me to. Any disgruntled forum member could use a bash script and systematically destory the forum by overwriting all the SD elements.

The trick will be to restrict updates to the registered APP only without credentials to the SD stored in the APP.

At least them an attacker needs to do code injection, but maybe that could be addressed too somehow

2 Likes
5

Thinking about it for the moment. It might be possible for something like a forum to use a mirror set of SDs.

So the APP relies on the mirrored SDs initially and then the RFC’s (tag type 8) SD objects could be used to view updates that have occurred since the ADMIN running another APP that takes the valid updates and writes the mirrored SDs.

1 Like
6

Finally

This could actually justify a field in the SD object being defined for permissions, perhaps a bit like unix rwx permissions.

groups

  • Owner
  • others

permissions

  • r - allow reading of SD contents by
  • w - allow writing to any of the SD contents (update)
  • a - append to contents of SD (up to SD size limit)
  • d - allow deletion of SD

Now obviously to allow “others” to delete invites all sorts of trouble, but there might be a use case for it.

So this could be stored in a single byte, one nibble for owner permissions and the other nibble for others permissions.

Obviously this is only an example of what the permissions could be and no reason not to have other permissions.

But since we are talking of a basic data structure it does not seem reasonable at this time to suggest some sort of ACL list as that chews through too much of the SD small max size of 100K

Using a tag type for this functionality seems odd since its not really a tag function but a permissions functionality

3 Likes
7

Don’t forget that SD can have multiple owners.

owner_keys : mut vec<crypto::sign::PublicKey> // n * 32 Bytes (where n is number of owners)

Maybe this can be used to achieve a primitive layer of permissions. But more likely I can imagine a permissions layer like @neo suggests being implemented as an overlay on this SD.

I think having ‘one standard for permissions’ will be important. Whether it’s at the safe network level or whether it’s an overly, I don’t know.

8

True, so owner in my permission groups is meaning all the owners specified. The benefit of permissions field that the core handles, is that you don’t need to make everybody an owner :slight_smile:

Also then a misuse of tag type is not happening and any SD of any tag type can have this functionality.

My thought is that maybe as the network grows in functionality that their might be one or more permission groups to add.

Maybe the owners field of the SD could have a primary owner and additional owners thus the permission groups could then become

  • primary owner
  • owners
  • others

Which is more like unix’s “owner”, “group”, & “others” permission sets used in the file system

9

Due to the data being easily appended to/corrupted, I suspect this would have limited usages. However, it could be useful for managing subscribers to a site, rather than their data.

The application could then request that other subscribers keep their own list, perhaps only writable by themselves. This would allow subscribers to provide a moderated list and/or enable other subscribers to validate a non-corrupted list.

All other data could then be distributed, with subscribers posting their own data, to their own storage. This data could be saved in a standard way, to allow other subscribers to read it (via the application, probably).

This is the approach I was considering for blogs, forums, friend networks, etc where data can remain owned by the author, but should be shared with others. However, managing the subscriber list isn’t easily possible without a way to update a publicly writable data store.

Edit: in short, it would be a good way to bootstrap a shared app.

10

Only observing here I really want to be considered nothing in rfc’s to explore them properly. In saying that we have

  1. Current owners
  2. Previous owners

This RFC introduces append method on a particular data type (tag 100). It’s a bit of an exploration as well into what we use these 10,000 tage for in an effort to allow all data types as well as computation moving forward. What we are really wanting to achieve is exactly this thread really. So there will be complete access to the SD above 10,000 where folk can really innovate.

I see the up to 10,000 as a place where we will implement fundamentals that are built on, so many RFC’s coming there. This thread is why we will do this though, to get as much feedback as possible and so far so good.

There is a couple of fundamental types we do require, append is for sure one, but there are a few types of append data we will require. So we can have separate types or encode further computation in like the posix style you mention. So it’s a case of bashing it out. The posix style would allow transition from everyone to group perhaps so type 100 is only then appendable and we cna have different access control on each one or we can have separate SD types for this. So great to see the debate and queries coming in. Just what we want to see here IMHO And the more the better. I hope the devs get time to get more involved here as we get past MVP.

It may be an idea we also link forum threads to rfc conversations in github as well as the issue tracker there to capture all input?

5 Likes
11

There are two permission systems that have really impressed me.

  • unix file permissions
  • bitcoin multisig transactions (m-of-n)

I think both these can be used to enhance SD, or added as an overlay on top of SD.

It then seems like we’re creating ‘special conditions upon which data can be changed’, which is very-much like smart contracts.

The scope for SD seems wide, and a robust permission system will really open it up.

My current understanding of SD (based on the validation section of the rfc) is

  • upon signing by the current owner, the owner and / or data of SD can be changed.

but I feel SD needs to grow into

  • upon some condition (m-of-n, group conditions, conditions set by some linked sd, etc…), the owner and / or data of SD can be changed

A good permissions layer turns data from ‘bits-and-bytes’ into a ‘social construct’, which is exactly what ‘the law’ and ‘politics’ aims to solve (to questionable success). I’m very interested to see how this evolves.

4 Likes
12

Yes all structured data currently follows this paradigm. Nice catch. The N+M machinery is all in place, but until messaging is also in place there is no easy way to get all the signatures to make the change to SD on the network. Messaging is in a branch right now, but on close roadmap.

Vaults currently to handle churn/read only network and then a cleanup → farming rate then added (again) and then messaging (before safecoin). So that’s a glimpse of the road map for vaults in near future.

4 Likes
13

The RFC has been merged to Proposed > Discuss - 0027- append-by-all-structured-data-type · Issue #113 · maidsafe/rfcs · GitHub

3 Likes
14

All of this seems straightforward. I personally would never use this in my app because my app cannot afford free-for-all editing. “If it has multiple owners, then at least (n/2) + 1 owners must sign the Structured Data for any update or delete.” ← if that’s a big problem I wish the answer was to have a type tag for any single one of those owners to update it (this more fits moderation permission models) but meh.

I look forward to the forum post for discussing Discuss Proposed - 0016-launcher-data-types-api · Issue #77 · maidsafe/rfcs · GitHub. In the meantime, I read this needs LOW_LEVEL_ACCESS for API use but not any mention in this RFC about what that API looks like.

Edit: I have a question. Why is this called “append by all” when it appears to be “replace by all”? Did I misunderstand something about the nature of appending here?

3 Likes