Ok couple questions. 1. It says installers are implimented. Does that mean that we have installers that we can use now? If so can you please direct me to them so that I can install maidsafe. I’m currently using Fedora 21 and Windows 7. Either/or works.
Is this theoretical or practical yet? Meaning is there such a program in existence and does this mean that such a program could say sort through my music archive for example and get rid of all the odd duplicate songs for me that crop up over time? What exactly is this and what does this mean. Please clarify.
Sounds like they are merely testing installers and some network connections in house right now and the stuff in David’s repositories are prolly something you’d have to build but I don’t know that for certain
The installers are functionally complete, but not yet tested. Upon completion of successful testing we will roll these out. I appreciate you have been patient waiting for these, hopefully not too much longer to wait.
This program exists now, but is something better suited to developers used to running examples. What this library will do (quoting from the link): ‘This library will provide convergent encryption on file based data and produce a DataMap type and several chunks of data. Each chunk is max 1Mb in size and has a name. This name is the Sha512 of the content, this allows the chunks to be confirmed. If size and hash checks are utilised, a high degree of certainty in the validity of the data can be expected.’
So it will chunk up and encrypt files producing a data map, but will not deduplicate files, such as songs. I hope this gives you a better understanding of where we’re at.
Thanks @nicklambert, I’ve added the diagram and link to your blog.
I’m still trying to understand what is meant by the API.
So far I understand that it includes:
the RESTful API (POST/PUT/GET/DELETE key-value store), though I am not sure how this might provide more extensive NoSQL features (such as in the Redis API, which handles collections etc.)
the NFS API (retrieve a list of file descriptors via the Launcher, then manipulate files using the standard file system library)
access to a virtual drive (provided by Drive)
I’ve summarised this in the FAQ mentioned, but I’m wondering if there is more to the API than this, for beta, launch, or planned later (see my questions here). Any corrections or additional info you can provide would be helpful, though not urgent
Ok judging from your description there and the library description (which by the way makes me think we need to have a new set of descriptions and documentation written in English for the rest of us) it sounds like this “dedumplification” library doesn’t actually do deduplification at all but rather converts files into data chunks, encrypts them, and THEN deduplificates those encrypted chunks. Which is something entirely different than deduplicating actual data in a file system. (Which again is why I think we need better documentation: So that we have more effective communication as to what things actually do.)
Many folks miss this part. The chunk store in effect de-duplicates in real time as any same files will produce the same chunks. So in effect de-duplication is a natural side effect of such a convergent encryption scheme. So you can consider it real time as the data is encrypted, basically it means the store won’t grow in size if you encrypt data that has already been encrypted elsewhere. So in the network this ‘elsewhere’ is pretty large so for normal data that’s seen by many folks, there is an increasing chance it’s already encrypted/stored etc.
If I get this correctly, the de-duplication process checks for very similar small chunks coming from different original files.
Is it possible for these chunks to combine into a corrupted file during the merging (GET?) process ?
Do you measure how “duplicate” two chunks are? Is it always 0%(Not duplicate) or 100%(Fully duplicate) or sometimes with 98%-99% accuracy?
The chunks need to be an exact match for the algorithm to deduplicate, even minor differences in chunk contents will provide a completely different hash. It is possible for chunks to become corrupted for a variety of reasons, but the data managers look after and check the integrity of the data recreating chunks where required.
Yes, SHA512 of the chunk contents. This 512 bits also serve to determine their position in the XOR space. In this way the different managers know where to save in the PUT (or know that already exists) and where to look for in the GET.
If this was three weeks ago, and the answer was 3 weeks - a month then there’s no need to give this attitude. I can understand the impatience (we all are, but the dev updates tell you exactly why the delays are there and it’s all to make the network as good as possible and I think that’s also in your advantage), but please stay respectful and maybe you can help them out to launch faster?
lol gtfo fishy troll to bitcointalk and your shitty shitcoins…yes you posted a couple of weeks ago the same question and now because you think this is another shitcoin thread come here and ask the same thing without even checking the past 3-4 dev updates…God I would ban the heck out of you if I were admin here…this project will change the future of Internet and you think you have the right to question the team like it’s a pump and dump scam??
Moderation in all things, well on the forum at least please
@sfcoin no need to escalate this. Respond, but try to be respectful. I acknowledge @wulfcastle is testing our patience with his impatient attitude, but we can handle that! I don’t know what his concern is but don’t see this as trolling at this point.
@wulfcastle why are you concerned about the delay? Do you have an interest in SAFE? Do you support it? Are you allowing your frustration to get in the way of that support? Please be respectful.
This Dev update is promising and exciting IMO, things becoming ready, a test app for the technical amongst us to play with, progress now moving faster than expected. I’m surprised by your tone in the light of this.