Can he verify you are definitely the only person that could have created this though (and not trying to delete somebody else’s chunk, or a rogue DM) ? Also we need to make sure DM do not store lots of account data, it reduces the churn handling so increases minimum spec of farmer (I really try to make sure even a mobile phone on for a few mins can farm, well it’s my goal).
2 Likes
I think I will need someone to translate the first part but for phone I understand. For the rest I have a mixed feeling if it’s sarcasm, positive or negative answer.
Its not sarcasm, its a very straight answer. If there’s something you don’t understand please ask for clarification.
1 Like
The fact the data is encrypted and that you’ve effectively thrown away the key means that as far as is known it is no longer accessible. In fact, you’ve done a bit more than thrown away the key, you’ve also scattered all the pieces in a way that they can no longer be reassembled. This is about as good as it gets I think.
7 Likes
Like with bitcoin if you lose your private key you cannot spend your funds anymore (and no-one else can).
4 Likes
I’m not willing to waste your time @dirvine. I share my idea with everyone to make it clearer. I think I understand that there is no way to trace back. So we stick with when it is deleted the space is lost and we have to buy the space again. So still, with my idea it’s a huge advantage for farmer. There is even a lot more space that is going to be available and not storing useless chunk. Phone will be able to farm more useful data instead of one that are never going to be accessible.
I still have hard time with all of these manager and who do the consensus. (I base it from the current systemdocs) Before deleting the data PmidManager validate with the consensus and verify with all the other PmidNode that are olding the chunk. Rogue DM will already exist and be monitored and rejected from the PmidManager so there is not problem there. And if it’s fail the delete request well a response it’s returned back to the Client Managers and take care of the faulty client.
Or better (my brain never stop turning). The Client Manager consensus can verify the delete request first by looking at the corresponding chunk and verify the second pass key. Only the owner have access to these key. If it pass, the request is then passed to the PmidManager, which in turn, verify the request too. And the PmidNode have to verify the result of the consensus, the like 28/32 stuff signed authorization. Now the PmidNode can mark the data has deletable or it delete it.
I don’t know how it will affect the phone performance. I first tough a vault, when first started, will only cache data because it’s low level trust and more and more it keep online the trust increase from 0 to 1. But if I compare this, waste space or waste of CPU. Maybe it should be considered.
We can’t please to everyone, like me 
A question is not an answer to me. He give me a question and in my head it was full confusing trying to answer that and all. Well it’s not really a big deal. You are not here to frustrate others here. It’s the only thing I have to understand. Thanks anyway.
Again you are speaking without understanding how the system works - making tweaks that seem on the face of it to achieve a positive, without realising that you are changing other things.
You will either need to study, or to ask for clarification on these issues. I can’t explain it all, but I can see that your idea of having a key which only you hold breaks the deduplication mechanisms. Either that or we go back to an earlier design where each chunk is reference counted, and can be deleted when it reaches zero (all owners “let go”). But that was removed to simplify and make the network more robust. So your suggestions while they may be useful thought experiments, and not “wrong”, have impacts that you are not considering and which explain why the network is designed the way it is.
This is not to say it can’t be improved, but that it takes a great deal of study and exploring to get to that stage, so keep at it!
2 Likes
Yeah I understand, I try to reach every document I can find, I read everything. And even the source is not completed yet so it lack a lot I can’t reach or I miss something. I try to understand the entire system and to have a pretty good clear image in my head on how it work. The thing I can’t get it’s the technical advanced point on each detail that I try to find for the storage part. I’ll try to look farther before I give something again in the future.
For deduplication that can still be managed on the client level. Or he will pay for the duplication.
I am getting closer to finding people to work on my Java ChatBot - one of the first things to do is move from the Java Serialisation quick and dirty storage to something more conventional but of course something which leverages the SAFE network - so these were really interesting comments of yours!
Thanks!
Phil.
1 Like
I have a mixed feeling if it’s sarcasm, positive or negative answer.
Just want to clarify with you why I said that.
defiantly for me it’s a person deficient.
created this though Someone that created that thinking
So for me it was like: Can he verify that you are the only deficient person and you tough about it?
My English is not perfect and can cross over different word in my head thinking it’s really that he want to say.
Don’t worry you never will.We need to consider all ideas, none are daft really. So we try and consider everything, keep prodding, but in the office we treat everything as tho it belongs to nobody, so don’t feel persecuted. we revert to the logic we know (it may be wrong and we know that).
I don’t understand you point here, I am not always best to do that, so keep going, I would say the ClientManagers do not know if you already stored that chunk (we do not record that)
For that I know. I don’t know how the process when we request a chunk work. I presume the client ask the ClientManager. If it’s not the case, my idea is wrong. But if it is the case, the Client ask the ClientManager to delete the chunk the same way it ask for a chunk to get retreived. But the client give the chunk firstly encrypted to the ClientManager with the key for the second encryption and the location of the chunk for verification. The second key is not linked to the account but randomly generated each time and saved to the DataMap. But if ClientManager do not manage this request first, I’m totally wrong I guess.
Create several hundred of vm, with 1tb in each vm,
Create thousands of account,
Start pumping hundreds of gb of useless junk to the public,
Hopefully those coins would be generated in my hundreds of vm users,
IF so, transfer to new or existing account,
delete all of the accounts.
Now people are holding unneeded junk without knowing.
I think there should be an graph on much much useless junk that takes up the network.
The client will ask the DM for that chunk as he/she already knows the hash. There is no search capability on the network. So you get your directory and it tells you the chunks to retrieve. So if you can know the dir to get and decrypt it you are all set.
3 Likes
If nobody asks for that data you have a problem. If only you ask for it then you need to hope the network grants a farming request, so it’s a lottery for you. That makes it easy for the network to not care if you do this you paid for chunks nobody wants. Farmers will farm over this quantity though. Later archive nodes will make this in secondary storage. It’s a losers game of we get it right.
1 Like
Whoa, it’s getting complex. So the Client is surrounded with ClientManager and DM at the same time?
1 Like
It can be for sure. guaranteed ClientManagers the data is handled by DataManager who also speak to PmidManagers (nodes responsible for storage nodes)
1 Like
Great thanks, that clear things up. I’m looking forward for the next test network and having fun with it. And trying to mess with it 
. I let you go, I’m done for now. I hope the best success for MaidSafe.
1 Like
And David would not the issue of people giving another the datamap cause problems if you allowed the data to be physically deleted. Like the case a person enters data for one person, (say accounts book keeper) and gives the map to another (the accountant) and then finally to the client. In a small business situation the people could be in different cities, There would be a number of files created so all need to have the same data map.
If the book keeper could physically delete the files off SAFE and did so thinking that giving the data map was copying, the book keeper would end up deleting the files from the account & client’s view.
SAFE would have no way of knowing if the datamap for the file was given to another (maybe as part of paid work). If this was allowed then the system is no longer reliable, a contractor could delete the data they entered on behalf of another. Giving the datamap to another is so much more efficient all around. You need the datamap to copy the file so why not just use the datamap.
1 Like