From ebb08f04991ce601799e7c38b5ed613155525ed1 Mon Sep 17 00:00:00 2001 From: ustulation Date: Thu, 9 Jul 2015 20:03:42 +0530 Subject: [PATCH 1/9] initial commit --- ...006-unified-structured-data-imporvement.md | 147 ++++++++++++++++++ 1 file changed, 147 insertions(+) create mode 100644 proposed/0006-unified-structured-data-imporvement.md diff --git a/proposed/0006-unified-structured-data-imporvement.md b/proposed/0006-unified-structured-data-imporvement.md new file mode 100644 index 0000000..21628ae --- /dev/null +++ b/proposed/0006-unified-structured-data-imporvement.md @@ -0,0 +1,147 @@ +- Feature Name: Improve Unified Structured data +- Type: Enhancement +- Related components: routing, maidsafe_types, maidsafe_vault, maidsafe_client, sentinel +- Start Date: 09-07-2015 + +# Summary + +Make Unified Structured Data (Rfc 0000-Unified-structured-data.md) work without the field `previous_owner_keys`. + +# Motivation + +##Why? + +The field `previous_owner_keys` causes code complexity and cofusion. Unified Structured Data can be made to work without it. + +##What cases does it support? + +This change supports all use of non immutable data (structured data). This covers all non `content only` data on the network and how it is handled. + +##Expected outcome + +Removing the field `previous_owner_keys` simplifies code and reduces logical complexity during Structured Data Updates and ownership-transfers. This might further simplify vault logic in future to avoid Structured Data Collisions even for the same `location` (64 byte network address for the data) as vaults will now have to look only for a single field (`owners`) to make the storage key unique even though `location` wasn't unique. + +# Detailed design + +##StructuredData + +``` +struct StructuredData { + tag_type : u64, + identifier : crypto::hash::sha512::Digest, + version : u64, // mutable - incrementing (deterministic) version number + data : Vec, // mutable - in many cases this is encrypted + owner_keys : vec // mutable - n * 32 Bytes (where n is number of owners) + signatures : Vec // mutable - detached signature of all the `mutable` fields (barring itself) by owners +} +``` + +Fixed (immutable fields) +- tag_type +- identifier + +##Flow + +The following shows Creation, Updation and Transfer-of-ownership of Structured Data: + +step 0: +Client-A sends: +``` +StructuredData { + other_fields: Value-00, + owner_keys: A-PublicKey, + signatures: Signed by A-PrivateKey, +} +``` + +step 1: +Vault receives for the first time. So Just Stores it: +``` +StructuredData { + other_fields: Value-00, + owner_keys: A-PublicKey, + signatures: Signed by A-PrivateKey, +} +``` + +step 2: +Client-A updates it: +``` +StructuredData { + other_fields: Value-11, + owner_keys: A-PublicKey, + signatures: Signed by A-PrivateKey, +} +``` + +step 3: +Vault will check if new data is sent by valid owner. Use `owner_keys` from the stored data in step 1 to verify signature of data in step 2. If valid replace previous data and store new one: +``` +StructuredData { + other_fields: Value-11, + owner_keys: A-PublicKey, + signatures: Signed by A-PrivateKey, +} +``` + +step 4: +Client-A wants to tranfer ownership of structureddata to Client-B: +``` +StructuredData { + other_fields: Value-22, + owner_keys: B-PublicKey, + signatures: Signed by A-PrivateKey, +} +``` + +step 5: +Vault will check if new data is sent by valid owner. Use `owner_keys` from the stored data in step 3 to verify signature of data in step 4. If valid replace previous data and store new one: +``` +StructuredData { + other_fields: Value-22, + owner_keys: B-PublicKey, + signatures: Signed by A-PrivateKey, +} +``` + +step 6: +Client-A tries to update illegally: +``` +StructuredData { + other_fields: Value-22, + owner_keys: A-PublicKey, + signatures: Signed by A-PrivateKey, +} +``` + +step 7: +Vault will use owner field from step-5 == B-PublicKey and signature verification fails. So it will not update anything. + +step 8: +Client-B tries to update: +``` +StructuredData { + other_fields: Value-33, + owner_keys: B-PublicKey, + signatures: Signed by B-PrivateKey, +} +``` + +step 9: +Vault will check if new data is sent by valid owner. Use `owner_keys` from the stored data in step 5 to verify signature of data in step 8. If valid replace previous data and store new one: +``` +StructuredData { + other_fields: Value-33, + owner_keys: B-PublicKey, + signatures: Signed by B-PrivateKey, +} +``` + +# Drawbacks +None identified yet. + +# Alternatives +None yet. + +# Unresolved questions +None yet. From e7a585a74b3022abcc6908c11b51914f8ce2ae96 Mon Sep 17 00:00:00 2001 From: ustulation Date: Thu, 9 Jul 2015 20:05:50 +0530 Subject: [PATCH 2/9] spellings --- proposed/0006-unified-structured-data-imporvement.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposed/0006-unified-structured-data-imporvement.md b/proposed/0006-unified-structured-data-imporvement.md index 21628ae..32468f2 100644 --- a/proposed/0006-unified-structured-data-imporvement.md +++ b/proposed/0006-unified-structured-data-imporvement.md @@ -85,7 +85,7 @@ StructuredData { ``` step 4: -Client-A wants to tranfer ownership of structureddata to Client-B: +Client-A wants to transfer ownership of Structured Data to Client-B: ``` StructuredData { other_fields: Value-22, From 3bd886685adfc54a54246e70776006c11944f286 Mon Sep 17 00:00:00 2001 From: Spandan Sharma Date: Thu, 9 Jul 2015 20:09:37 +0530 Subject: [PATCH 3/9] make steps bold --- ...006-unified-structured-data-imporvement.md | 22 +++++++++---------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/proposed/0006-unified-structured-data-imporvement.md b/proposed/0006-unified-structured-data-imporvement.md index 32468f2..35075b0 100644 --- a/proposed/0006-unified-structured-data-imporvement.md +++ b/proposed/0006-unified-structured-data-imporvement.md @@ -19,7 +19,7 @@ This change supports all use of non immutable data (structured data). This cover ##Expected outcome -Removing the field `previous_owner_keys` simplifies code and reduces logical complexity during Structured Data Updates and ownership-transfers. This might further simplify vault logic in future to avoid Structured Data Collisions even for the same `location` (64 byte network address for the data) as vaults will now have to look only for a single field (`owners`) to make the storage key unique even though `location` wasn't unique. +Removing the field `previous_owner_keys` simplifies code and reduces logical complexity during Structured Data Updates and ownership-transfers. This might further simplify vault logic in future to avoid Structured Data Collisions even for the same `location` (64 byte network address for the data) as vaults will now have to look only for a single field (`owners`) and track its changes to make the storage key unique even though `location` wasn't unique. # Detailed design @@ -44,7 +44,7 @@ Fixed (immutable fields) The following shows Creation, Updation and Transfer-of-ownership of Structured Data: -step 0: +*step 0:* Client-A sends: ``` StructuredData { @@ -54,7 +54,7 @@ StructuredData { } ``` -step 1: +*step 1:* Vault receives for the first time. So Just Stores it: ``` StructuredData { @@ -64,7 +64,7 @@ StructuredData { } ``` -step 2: +*step 2:* Client-A updates it: ``` StructuredData { @@ -74,7 +74,7 @@ StructuredData { } ``` -step 3: +*step 3:* Vault will check if new data is sent by valid owner. Use `owner_keys` from the stored data in step 1 to verify signature of data in step 2. If valid replace previous data and store new one: ``` StructuredData { @@ -84,7 +84,7 @@ StructuredData { } ``` -step 4: +*step 4:* Client-A wants to transfer ownership of Structured Data to Client-B: ``` StructuredData { @@ -94,7 +94,7 @@ StructuredData { } ``` -step 5: +*step 5:* Vault will check if new data is sent by valid owner. Use `owner_keys` from the stored data in step 3 to verify signature of data in step 4. If valid replace previous data and store new one: ``` StructuredData { @@ -104,7 +104,7 @@ StructuredData { } ``` -step 6: +*step 6:* Client-A tries to update illegally: ``` StructuredData { @@ -114,10 +114,10 @@ StructuredData { } ``` -step 7: +*step 7:* Vault will use owner field from step-5 == B-PublicKey and signature verification fails. So it will not update anything. -step 8: +*step 8:* Client-B tries to update: ``` StructuredData { @@ -127,7 +127,7 @@ StructuredData { } ``` -step 9: +*step 9:* Vault will check if new data is sent by valid owner. Use `owner_keys` from the stored data in step 5 to verify signature of data in step 8. If valid replace previous data and store new one: ``` StructuredData { From 2fe8571be2ac668beefddc505ae82513e0644305 Mon Sep 17 00:00:00 2001 From: Spandan Sharma Date: Thu, 9 Jul 2015 20:10:36 +0530 Subject: [PATCH 4/9] make steps bold --- ...0006-unified-structured-data-imporvement.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/proposed/0006-unified-structured-data-imporvement.md b/proposed/0006-unified-structured-data-imporvement.md index 35075b0..25e627a 100644 --- a/proposed/0006-unified-structured-data-imporvement.md +++ b/proposed/0006-unified-structured-data-imporvement.md @@ -54,7 +54,7 @@ StructuredData { } ``` -*step 1:* +**step 1:** Vault receives for the first time. So Just Stores it: ``` StructuredData { @@ -64,7 +64,7 @@ StructuredData { } ``` -*step 2:* +**step 2:** Client-A updates it: ``` StructuredData { @@ -74,7 +74,7 @@ StructuredData { } ``` -*step 3:* +**step 3:** Vault will check if new data is sent by valid owner. Use `owner_keys` from the stored data in step 1 to verify signature of data in step 2. If valid replace previous data and store new one: ``` StructuredData { @@ -84,7 +84,7 @@ StructuredData { } ``` -*step 4:* +**step 4:** Client-A wants to transfer ownership of Structured Data to Client-B: ``` StructuredData { @@ -94,7 +94,7 @@ StructuredData { } ``` -*step 5:* +**step 5:** Vault will check if new data is sent by valid owner. Use `owner_keys` from the stored data in step 3 to verify signature of data in step 4. If valid replace previous data and store new one: ``` StructuredData { @@ -104,7 +104,7 @@ StructuredData { } ``` -*step 6:* +**step 6:** Client-A tries to update illegally: ``` StructuredData { @@ -114,10 +114,10 @@ StructuredData { } ``` -*step 7:* +**step 7:** Vault will use owner field from step-5 == B-PublicKey and signature verification fails. So it will not update anything. -*step 8:* +**step 8:** Client-B tries to update: ``` StructuredData { @@ -127,7 +127,7 @@ StructuredData { } ``` -*step 9:* +**step 9:** Vault will check if new data is sent by valid owner. Use `owner_keys` from the stored data in step 5 to verify signature of data in step 8. If valid replace previous data and store new one: ``` StructuredData { From a18c7d2ef6d2805fc492cd82f4bdf2b28a77b6de Mon Sep 17 00:00:00 2001 From: Spandan Sharma Date: Thu, 9 Jul 2015 20:11:21 +0530 Subject: [PATCH 5/9] step-0 left out from being marked bold --- proposed/0006-unified-structured-data-imporvement.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposed/0006-unified-structured-data-imporvement.md b/proposed/0006-unified-structured-data-imporvement.md index 25e627a..98f0375 100644 --- a/proposed/0006-unified-structured-data-imporvement.md +++ b/proposed/0006-unified-structured-data-imporvement.md @@ -44,7 +44,7 @@ Fixed (immutable fields) The following shows Creation, Updation and Transfer-of-ownership of Structured Data: -*step 0:* +**step 0:** Client-A sends: ``` StructuredData { From ada6b85d673de37c2d2ffd61eb3efab351f6c126 Mon Sep 17 00:00:00 2001 From: Spandan Sharma Date: Thu, 9 Jul 2015 20:12:38 +0530 Subject: [PATCH 6/9] formatting --- proposed/0006-unified-structured-data-imporvement.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposed/0006-unified-structured-data-imporvement.md b/proposed/0006-unified-structured-data-imporvement.md index 98f0375..c965a83 100644 --- a/proposed/0006-unified-structured-data-imporvement.md +++ b/proposed/0006-unified-structured-data-imporvement.md @@ -115,7 +115,7 @@ StructuredData { ``` **step 7:** -Vault will use owner field from step-5 == B-PublicKey and signature verification fails. So it will not update anything. +Vault will use owner field from **step 5** == `B-PublicKey` and signature verification fails. So it will not update anything. **step 8:** Client-B tries to update: From 215a3918c5aba7f38ac8448be584df83dbb9007a Mon Sep 17 00:00:00 2001 From: ustulation Date: Fri, 10 Jul 2015 13:39:48 +0530 Subject: [PATCH 7/9] re-introducing previous-owners field but for an entirely different purpose --- proposed/0006-unified-structured-data-imporvement.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/proposed/0006-unified-structured-data-imporvement.md b/proposed/0006-unified-structured-data-imporvement.md index 32468f2..2ceb21c 100644 --- a/proposed/0006-unified-structured-data-imporvement.md +++ b/proposed/0006-unified-structured-data-imporvement.md @@ -1,17 +1,17 @@ -- Feature Name: Improve Unified Structured data +- Feature Name: Handle Unified Structured data in conjunction with Vaults to prevent collision - Type: Enhancement - Related components: routing, maidsafe_types, maidsafe_vault, maidsafe_client, sentinel - Start Date: 09-07-2015 # Summary -Make Unified Structured Data (Rfc 0000-Unified-structured-data.md) work without the field `previous_owner_keys`. +Use Unified Structured Data (Rfc 0000-Unified-structured-data.md) `previous_owner_keys` to only prevent collision in vaults. # Motivation ##Why? -The field `previous_owner_keys` causes code complexity and cofusion. Unified Structured Data can be made to work without it. +The field `previous_owner_keys` will be filled only during alteration of existing owners (redunction, addition and transfer) to allow vaults to re-hash a new key to avoid collision. ##What cases does it support? @@ -19,7 +19,7 @@ This change supports all use of non immutable data (structured data). This cover ##Expected outcome -Removing the field `previous_owner_keys` simplifies code and reduces logical complexity during Structured Data Updates and ownership-transfers. This might further simplify vault logic in future to avoid Structured Data Collisions even for the same `location` (64 byte network address for the data) as vaults will now have to look only for a single field (`owners`) to make the storage key unique even though `location` wasn't unique. +Changing the behavior of field `previous_owner_keys` simplifies code and reduces logical complexity during Structured Data Updates and ownership-transfers. This Rfc also shows how this field can improve vault logic in future to avoid Structured Data Collisions even for the same `location` (64 byte network address for the data) as vaults will now have to look only for a single field (`owners`) to make the storage key unique even though `location` wasn't unique. # Detailed design @@ -32,6 +32,7 @@ struct StructuredData { version : u64, // mutable - incrementing (deterministic) version number data : Vec, // mutable - in many cases this is encrypted owner_keys : vec // mutable - n * 32 Bytes (where n is number of owners) + signatures : Vec // mutable - detached signature of all the `mutable` fields (barring itself) by owners } ``` From c206e584bdebffe1d8a6e8f98b38c89e5ed2e89f Mon Sep 17 00:00:00 2001 From: ustulation Date: Sun, 9 Aug 2015 19:17:16 +0530 Subject: [PATCH 8/9] further discussion regarding collision free PUTs --- ...006-unified-structured-data-imporvement.md | 42 ++++++++++++------- 1 file changed, 27 insertions(+), 15 deletions(-) diff --git a/proposed/0006-unified-structured-data-imporvement.md b/proposed/0006-unified-structured-data-imporvement.md index f87e789..043cdcd 100644 --- a/proposed/0006-unified-structured-data-imporvement.md +++ b/proposed/0006-unified-structured-data-imporvement.md @@ -5,13 +5,13 @@ # Summary -Use Unified Structured Data (Rfc 0000-Unified-structured-data.md) `previous_owner_keys` to only prevent collision in vaults. +Use Unified Structured Data (Rfc 0000-Unified-structured-data.md) `previous_owner_keys` to transfer ownership and to prevent collision in vaults. # Motivation ##Why? -The field `previous_owner_keys` will be filled only during alteration of existing owners (redunction, addition and transfer) to allow vaults to re-hash a new key to avoid collision. They will solve no other purpose. +The field `previous_owner_keys` will be filled only during alteration of existing owners (redunction, addition and transfer) to allow vaults to re-hash a new key to avoid collision. The overall effect will be to reduce collision of PUTs for Structured Data in Vaults by a good enough factor, as the identifier chosen by the user can be SHA512 of a string and user chosen strings may collide severly. ##What cases does it support? @@ -19,7 +19,7 @@ This change supports all use of non immutable data (structured data). This cover ##Expected outcome -Changing the purpose of field `previous_owner_keys` simplifies code and reduces logical complexity during Structured Data Updates and ownership-transfers. This Rfc shows the only purpose of this field in improving vault logic in future to avoid Structured Data Collisions even for the same `location` (64 byte network address for the data) as vaults will utilise this field to make the storage key unique even though `location` wasn't unique. +Changing the purpose of field `previous_owner_keys` simplifies code and reduces logical complexity during Structured Data Updates and ownership-transfers. During regular updates (POSTs which don't involve ownership transfers) this will reduce the size of StructuredData packet as `owners` field will not be needed to be duplicted and filled in the `previous-owners` field (which) in this case will be blank. Also, and farther-reaching, this Rfc shows the purpose of this field in improving vault logic in future to avoid Structured Data Collisions even for the same `location` (64 byte network address for the data) as vaults will utilise this field to make the storage key unique even though `location` wasn't unique. # Detailed design @@ -28,7 +28,7 @@ Changing the purpose of field `previous_owner_keys` simplifies code and reduces ``` struct StructuredData { tag_type : u64, - identifier : crypto::hash::sha512::Digest, + identifier : NameType, // struct NameType([u8; 64]); version : u64, // mutable - incrementing (deterministic) version number data : Vec, // mutable - in many cases this is encrypted owner_keys : vec // mutable - n * 32 Bytes (where n is number of owners) @@ -57,10 +57,10 @@ StructuredData { ``` **step 1:** -Logic: Since `previous_owner_keys` in incoming data contains nothing, use `key` = `(sha512(owner_keys), name)` for look-up. +Logic: Since `previous_owner_keys` in incoming data contains nothing, use `key` = `(sha512(owner_keys), Name)` for look-up. Vault receives for the first time. So Just Stores it: ``` -Key = (sha512(A-PublicKey), name) +Key = (sha512(A-PublicKey), Name) Value = StructuredData { other_fields: Value-00, owner_keys: A-PublicKey, @@ -81,10 +81,10 @@ StructuredData { ``` **step 3:** -Logic: Since `previous_owner_keys` in incoming data contains nothing, use `key` = `(sha512(owner_keys), name)` for look-up. +Logic: Since `previous_owner_keys` in incoming data contains nothing, use `key` = `(sha512(owner_keys), Name)` for look-up. Vault will check if new data is sent by valid owner. Use `owner_keys` from the stored data in step 1 to verify signature of data in step 2. If valid replace previous data and store new one: ``` -Key = (sha512(A-PublicKey), name) +Key = (sha512(A-PublicKey), Name) Value = StructuredData { other_fields: Value-11, owner_keys: A-PublicKey, @@ -105,10 +105,10 @@ StructuredData { ``` **step 5:** -Logic: Since `previous_owner_keys` in incoming data contains something, use `key` = `(sha512(previous_owner_keys), name)` for look-up. Calculate a new `key` = `(sha512(owner_keys), name)` if the update is legal as checked below (as usual). +Logic: Since `previous_owner_keys` in incoming data contains something, use `key` = `(sha512(previous_owner_keys), Name)` for look-up. Calculate a new `key` = `(sha512(owner_keys), Name)` if the update is legal as checked below (as usual). Vault will check if new data is sent by valid owner. Use `owner_keys` from the stored data in step 3 to verify signature of data in step 4. If valid replace previous data and store new one: ``` -Key = (sha512(B-PublicKey), name) +Key = (sha512(B-PublicKey), Name) Value = StructuredData { other_fields: Value-22, owner_keys: B-PublicKey, @@ -143,10 +143,10 @@ StructuredData { ``` **step 9:** -Logic: Since `previous_owner_keys` in incoming data contains nothing, use `key` = `(sha512(owner_keys), name)` for look-up. +Logic: Since `previous_owner_keys` in incoming data contains nothing, use `key` = `(sha512(owner_keys), Name)` for look-up. Vault will check if new data is sent by valid owner. Use `owner_keys` from the stored data in step 5 to verify signature of data in step 8. If valid replace previous data and store new one: ``` -Key = (sha512(B-PublicKey), name) +Key = (sha512(B-PublicKey), Name) Value = StructuredData { other_fields: Value-33, owner_keys: B-PublicKey, @@ -154,12 +154,24 @@ Value = StructuredData { signatures: Signed by B-PrivateKey, } ``` +## Change in the Definition of GETs +The above shows the cases for PUTs, POSTs and DELETEs. There will be a change in the signature of GETs to achieve the above no-collision scheme. GETs for StructuredData need to be changed from: +``` +GET(Name, DataRequest::StructuredData(u64)) +``` +to +``` +GET(Name, DataRequest::StructuredData(SHA512(PublicKeys))) +``` +For ordinary cases where `data-PUTers` themselves are fetching thier data (majority of clients) this does not mean much as the client engine will inject this silently as it already has the knowledge of user public-keys. The only time it does not have the knowledge is during the fetching of the session packet. The solution for this is easy as login packet has a dedicated maidasafe-type-tag and vaults can recognise it and make special allowance for it to be stored with `Key = Name` instead of `Key = (sha512(PublicKeys), Name)` as in above. + +#Drawbacks +For other cases where the retrieval is done for the data PUT by others, the GETer must know the PublicKey of the original PUTer. An example of this will be the fetching of Dns Packets by a safe-url-parser (could be a browser). This may be seen as an advantage instead of disadvantage though as explained thus. Since there is no retriction for taking a Dns name in the SAFE-network, a user can very easily obtain well known Dns names like `pepsico.com` preventing the legit organisation to take it later. However with the schema in thi rfc, the legit organisation can easily obtain the same Dns name for it because it will have got the uniqueness in the vaults due to `sha512` of its PublicKey. This PublicKey will be the one which is distributed to all browsers and thus safe-url-parser will land on the legitimate page instead of the pretender's. -# Drawbacks -None identified yet. +Since Dns Packets also have special type-tags, the vaults can recognise them. There could be ordinary ones (with TAG = X) where the storage is `Key = Name` for which there would be collisions and special ones (with TAG = Y) where the storage would be `Key = (sha512(PublicKey), Name)`. The safe-browser would land on the correct destination depending on whether TAG = X or TAG = Y was demanded. This is beyond the scope of this Rfc and can be discussed in a separate one. # Alternatives None yet. # Unresolved questions -None yet. +Working of safe-protocol for browsers as briefly discussed in Drawbacks section. From 7d1099eef303a540078f1c0e8f8b439b5071bf7d Mon Sep 17 00:00:00 2001 From: ustulation Date: Mon, 28 Sep 2015 14:09:32 +0530 Subject: [PATCH 9/9] Updated due to update in DataRequest format --- proposed/0006-unified-structured-data-imporvement.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/proposed/0006-unified-structured-data-imporvement.md b/proposed/0006-unified-structured-data-imporvement.md index 043cdcd..21473a4 100644 --- a/proposed/0006-unified-structured-data-imporvement.md +++ b/proposed/0006-unified-structured-data-imporvement.md @@ -157,11 +157,11 @@ Value = StructuredData { ## Change in the Definition of GETs The above shows the cases for PUTs, POSTs and DELETEs. There will be a change in the signature of GETs to achieve the above no-collision scheme. GETs for StructuredData need to be changed from: ``` -GET(Name, DataRequest::StructuredData(u64)) +GET(Name, DataRequest::StructuredData(NameType, u64)) ``` to ``` -GET(Name, DataRequest::StructuredData(SHA512(PublicKeys))) +GET(Name, DataRequest::StructuredData(NameType, u64, SHA512(PublicKeys))) ``` For ordinary cases where `data-PUTers` themselves are fetching thier data (majority of clients) this does not mean much as the client engine will inject this silently as it already has the knowledge of user public-keys. The only time it does not have the knowledge is during the fetching of the session packet. The solution for this is easy as login packet has a dedicated maidasafe-type-tag and vaults can recognise it and make special allowance for it to be stored with `Key = Name` instead of `Key = (sha512(PublicKeys), Name)` as in above.