nicklambert: nicklambert: Maybe referring to the network as data and communications as opposed to storage and retrieval?

happybeing: happybeing: How about “data storage and communications network” in the first sentence

Amazing that you both picked up on a point that I really labored on while writing. For me, ‘data and communications’ seemed too broad to capture the readers interest, so using ‘storage and retrieval’ seemed focused and precise. Having seen this feedback I think it’s best changed to ‘data storage and communications’.

Mindphreaker: Mindphreaker: I may suggest a small additional section about the difference to “similar” projects

Traktion: Traktion: One suggestion I would have, would be to compare to current infrastructure and platforms out there, in a similar way to the blockchain references

This is a good idea, but I think the document becomes too lengthy. I also think talking about what’s broken in existing systems doesn’t actually help in understanding the safe network in the context of this particular document.

happybeing: happybeing: How about Network tokens called Safecoin

Good one, I’ve updated this.

happybeing: happybeing: The datamap also acts as an encryption key for the chunks it refers to. Sounds very neat, but is this right, or does the data map include / hold the key?

happybeing: happybeing: I thought all files were encrypted, but that private files were made private by encrypting the data map, and public files shared by sharing the unencrypted data map.

Datamap is defined in maidsafe/self_encryption as “Holds the information that is required to recover the content of the encrypted file.” The data it contains is just the list of chunks. There’s no indication of encryption for private data (although from memory this is not yet implemented).

Each datamap chunk “Holds pre- and post-encryption hashes” (L20), implying the chunk is what is encrypted (via self-encryption, not to differentiate public / private data).

So I’m not totally clear on the specific detail and would benefit from further clarification from maidsafe devs about how public / private data differs (preferably a link to an existing document).

I’d like the explanation in the document for private / public data to be a little clearer.

happybeing: happybeing: I’m a bit vague about what qualifies as a resource identifier and what a resource is. I’m thinking that they are an address of something, such as a data map (eg for an immutable data item /file) but maybe not always. Could you explain that a bit more here?

Yes I feel there’s not enough clarity in my use of the terms chunks vs resources vs files etc. I’m pretty sure the usage is consistent, but it’s not clear. I’ll try to improve it.

happybeing: happybeing: David (on the forum - I can find if you need it) has outlined how smart contracts can be implemented with existing MD, so maybe add this to the use cases with a reference or short explanation?

Yes, smart contracts are briefly mentioned in the Messaging section of the document, but I think it could benefit from a little more detail. I’ll see about adding some more info.

happybeing: happybeing: All vaults are allocated a random unique 256 bit identifier by the network upon joining. Maybe add … or rejoining.

Good idea. I’ve added this.

draw: draw: The identifier for these resources are SHA3-256 hashes of on the resource content.

Good catch on the typo. Fixed.

dirvine: dirvine: for mutable we can name it many ways though.

One detail I’m not clear about is how mutable data names are defined. The Mutable Data RFC doesn’t seem to specify this. Can anyone link to a document or code that clarifies how mutable data names are determined?

tfa: tfa: What you call group is now called section.

Thanks, I’ll fix this terminology. I tried to be consistent with the terms as used in Close Group Consensus vs Disjoint Sections… maybe some guidelines around when to use Group vs Section could be helpful to me.

tfa: tfa: What you call section is in fact called prefix

Good catch. I’ve changed this.

tfa: tfa: Section size is >= 8 but is not necessarily <= 16

I’ll update this as per your detail. Great use of the word hysteresis too!

tfa: tfa: Permissions are not associated with specific keys but are applicable to all keys of a Mutable Data.

My phrasing is probably a little ambiguous, but is still correct. The Permissions Section of the Mutable Data RFC says MD can have multiple users with multiple permissions. So permissions are applied per key, not to all keys of a MD.

To clarify via the code for MD permissions, permissions is a BTreeMap<User, PermissionSet> , which “Maps an application key to a list of allowed or forbidden actions”. This uses different terms for the same concept of User and Application Key.

Permissions as designed in the RFC allow multiple permissions per user with the definition permissions: BTreeMap<User, BTreeSet<Permission>> but as implemented in code is defined as BTreeMap<User, PermissionSet> . Just a subtle inconsistency in the definition of ‘multiple permissions’.

This also means permissions are allocated to users, not users allocated to permissions.

… but I’m getting stuck in the weeds here… I think the phrasing in the document is adequate to convey the concept! If you can think of a more suitable way to word it I’d be glad to know.

Thanks everyone for the feedback. This is such a great community and project to be part of.