We wrote a comprehensive review of MaidSafe.
Always happy to get feedback.
23 Likes
Well laid out, nicely written and informative Chris. There is an inference - though no claim - this is blockchain related. The largest being comparison to storj. This should not be compared to anything blockchain related and in a world that is everything blockchain, a conspicuous reference to the fact that it is not built on the blockchain may be valuable.
3 Likes
A very decent article, some suggestions for revisionā¦
Terminology:
Not blocks, but chunks
Not SAFE coin, but Safecoin
Misleading:
Unfortunately, the lack of an API for dynamic data or calculations makes creating an interactive service on the SAFE network mind-bendingly difficult. [er, no, not at all!!! ] Building such a service involves the creation of an additional āserviceā protocol on top the existing protocol.[Nope] If you want do dig deeper into this, we recommend studying the progress of Project Decorum.[Well, not the best place to look, better to look at the proposed, close to implementation APIs]
An alternative to the native approach of solving the dynamic data problem would be to introduce a centralized instance, a regular server, for the management of the dynamic aspects of a service. [Definitely NOT. A terrible idea for security, and completely unnecessary] With this approach, we would be forcing an architecture similar to TOR, partially defying the purpose of the networkās architecture [exactly]. It is not entirely unlikely that such hybrid approaches, even the creation of TOR-style exit nodes could become necessary in the early stages of network establishment.[wrong]
There is already an API for dynamic data although not final or implemented, but being finalised and implemented right now. To see this and other areas that are imminent I suggest you dig into the RFCs on github. The RFCs on Immutable Data, Appendable Data and particularly Structured Data are what you need to look at, and use to revise the above which is incorrect and very misleading.
Essentially, dynamic data is already possible to an extent (see my porting of RS.js apps noted shortly) and very much more powerful and part of the public alpha shortly.
Also, your description of the alpha as centralised is misleading, because it is likely to read as if it does not yet involve any decentralised technology. You are technically correct in the sense that MaidSafe control the decentralised nodes that deliver it.
Your description of the Testnet as being about storage suggests that the Alpha doesnāt cover storage, which of course it does. Both do. What is different is that in Testnet8 end users can contribute storage (i.e. run vaults), whereas in the Alpha users cannot do this.
Also, like the Alpha, Testnet 8 is also open to the general public, not just selected developers as youāve incorrectly stated. The difference is that Testnet 8 is deliberately less stable due to testing, and so less suitable for developers or users who need something more stable to play with - for them, the Alpha network is provided.
weād certainly wish to know a bit more about the future of the SAFE coin, the project ownerās holdings and the use of the 24M coins still in the projectās possession.
This is all public knowledge. What you think you donāt know, please ask and someone will answer or point you to the relevant topic.
We are uncertain whether the elimination of this slight nuisance really warrants the effort of a custom browser implementation and all the obvious problems that come with such a project.
The SAFE Beaker Browser is being created primarily to ensure that the security of users is not compromised, rather than to make usage more convenient. SAFE Beaker Browser will become the preferred method of accessing the SAFE Web because a legacy browser that simultaneously accesses the CLEARNET, or from which cookies and other goodies are accessible, opens up a vast array of potential security vulnerabilities.
By default, the SAFE browser will not allow access to anything outside SAFEnetwork, and since SAFEnetwork websites will be far far more secure from being hacked, the level of security and privacy afforded by SAFE Beaker Browser can be unprecedented, which is of course one of the primary goals of SAFEnetwork.
Technologically, the barrier of entry to create interactive applications on the SAFE network is still very highā¦
While technically you can argue this at this precise moment, the point is far too strongly made IMO, and so does not justify the points made in the remainder of your paragraph.
This is because all this is changing very rapidly. Iām just learning JavaScript, and yet, currently have three applications running in local tests that are simple ports of dynamic web applications originally written to use remoteStorage.js.
I canāt show these yet because the alpha network imposed a couple of security restrictions that are over zealous, and exposed a vulnerability in remoteStorage.js which that project have been working to fix over the weekend. So very soon Iāll be able to show these three apps, each of which was ported in minutes, running on SAFEnetwork. 
Not sooooooo hard. And all that without the dynamic data API (Appendable Data and Structured Data) that is in the wings right now. And Iām not a decent programmer, Iām an ex professional who is now learning JavaScript. But I know there are several very decent programmers working on far more impressive apps right now too
So I think you could be a bit less negative about SAFEnetwork as an application platform, if not now, then check back in a month to see what a JavaScript novice like me can get going.
The SAFE Ecosystem
You have not mentioned how various incentives for different stakeholders make adoption by users and providers very different to past projects, or those youāve made comparisons with. I think this is an important omission. Please consider the effect of these on adoption:
- the attractiveness of a pay once stored forever secure private cloud compared to existing offerings, especially when the cost will be based on spare resources, rather than enormous costly data centres with enormous energy bills
- how storage providers are rewarded, how easy it is for any user to take part in both sides of the equation, and how little they need to invest (nothing) to earn Safecoin for sharing their unused, mostly already paid for, resources
- how app developers are rewarded based on the use and popularity of their applications
- how an App scales automatically, regardless of how many users it gains, without the developer having to rent a single server, or sell their souls to fund the growth of data centres serving it
- how the network automatically generates the funds to pay developers who maintain the core
- proposals to test mechanisms for rewarding the producers of popular content published on the network (i.e. pay the producer or PtP). Imagine the impact of this on the publishing world, or rewarding individual creativity etc.
Also, consider SAFEnetwork as an internet with own built in, highly scalable, micropayment ready, totally anonymous currency, as a platform for free exchange, trading, services etc
Thereās a lot to it!
Youāve written a decent article, better than many first attempts, but it takes some time to appreciate this project so I hope youāll be inspired to look in more depth and maybe explore the wider implications.
Thanks for sharing it here and inviting comment. I hope some of this is useful, and all taken in the positive feedback way I am not so good at conveying!
23 Likes
Great feedback but the idea he revises his article to the degree you suggest is unrealistic.
@thisischris hopefuly will do a followup article in the near future -and after some dust has settled and more progress- with some more depth. But for now this IMO this more than suffices.
@BIGbtc thanks for your feedback 
welcomeā¦ ā
No inference at all, especially because Storj too relies on Kademlia, not a blockchain. The factsheet at the end explicitly mentions that no blockchain is used except for the MAID token (which is not integrated with the network). But I perfectly understand what you are getting at , itās a bit sad that any distributed tech is subsumed under the āblockchainā meme right now.
8 Likes
Great style. Keep up the good work @thisischris
Thank you for the very detailed feedback. With this series, we aim for a broad coverage of promising projects, while remaining understandable at least to a somewhat crypto aware community.
If we get a chance to do so, we always check with the founders (in this case with Nick Lambert). But we remain limited on the amount of time that we can invest and on the level of detail that we can go into. Even with this āgeneralistā approach, our articles are barely understandable to many that we know (including people who have worked in IT on executive level for decades).
We also donāt want to be overly positive about possible future developments of the projects we look into because we know that new tech is always brutal and because we observed that an overly positive approach makes people suspicious very quickly (justified or not).
Right now, I can only do your feedback justice by linking back to this thread from the articleās comment section.
12 Likes
Youāre welcome Chris, though I donāt think I am just offering more depth and detail. That is there, but I think Iāve highlighted significant errors and unfair presentation of facts that you might would be very helpful to your readers in gaining a truer picture of the project.
But no worries @thisischris I provided feedback and it is for you to decide what if anything to do do in response. Rather than I link though, I think better for me to just post the feedback as is so people can see it in situ so Iāll do that.
5 Likes
Hoping to help you understand my (outsiderās) point of view by addressing the individual points you raise.
- Terminology: thank you, corrected
- Lack of dynamic data API: I do know that an API is in development and I mention right at the beginning of the article that a lot of good things are to be expected from the project in the near future. But for the sake of making projects comparable and understandable, I strictly write about things that exist here and now and that are accessible to a certain level, e.g. through a tutorial/getting started guide. The assumption that an outside developer will dig into RFCs and start implementing his software on an unfinished API is just not realistic.
- Centralized Alpha: I clearly write that the Alpha release does store its data in a set of controlled nodes and that decentralized storage does exist, but that the two parts are not yet working together. I donāt see how this can be perceived as negative, the project is in development, itās an Alpha, and thatās just fine.
- Testnet8: maidsafe.readme.io states āUsers canāt run their own vault.ā I know that Testnet8 exists and tried to gain access to it, but was not able to do so within a reasonable amount of time. As a tech worker of almost 30 years I must assume that others will have a similar experience, hence the statement that only a small number of devs will manage to access it. I know that everything is out there and that everything thatās out there can be made to work, but thatās not what I would call accessible to the general public. Again: this is perfectly fine, I donāt see why there is a need to suggest that everything is finished already.
- MAID ownership and Safecoin roadmap. Here, Iām talking about some kind of economic transparency paper or another kind of summary that would allow investors to understand their investment in a simple way. Thereās a lot of info out there, I know, but people who are merely investing in these projects (whatever anybody might think of that) wonāt go scouring forums and asking questions in the long run. An ICO/crowdsale is some kind of pseudo-public listing and I hope that in the future, there will be more transparency in these processes, also to prevent the authorities from feeling compelled to enforce that transparency the hard way. As I mentioned: my doubts in this regard are very small in the case of MaidSafe, but still, a nice summary somewhere would be helpful.
- Barriers of entry for devs: I know that these will be lowered soon. But again, right now, they are still high compared to the maybe 150 projects that Iāve worked with productively in the past 30 years. And again: I donāt see why this should be negative, the SAFE network could be the future of the Internet, so itās probably worth investing a bit of time to get it right?
- Incentives: In this article, I am referring to the Storj article where I discussed this kind of incentives (they are very similar in both networks). Pay once, store forever is not realistic because itās lopsided from an economic point of view: how can somebody pay once and somebody else (or the network) render a service forever? Storage providers do invest: time to get the software up and running and to keep it running and resources like bandwidth or electric power. Developer (or even user, producer, core maintainers) rewards are one of the fantastic advantages of this new kind of system that combines decentralized technology and micropayments. If we get this right, I am positive that it will literally change the world. However, to get it right, we also have to think about things that could possibly go wrong.
One of the reasons why we started this article project is that I personally believe that decentralized trust technologies, combined with micro-reward systems, will drive the next big wave of technological change. I feel that we are at a similar moment in tech-time to the early years of the Internet and I made ample reference to this throughout my article, I even call MaidSafe āthe next Internetā in the title. However, in the past 30 years in tech, Iāve also seen many things go horribly wrong, especially because we as technical people often fail to build reliable bridges to the social sphere. Pointing out the good things and those that still need improvement to make this workable for āthe general publicā is my way of laying maybe one single stone for this bridge. Iām sorry that my attempt at a differentiated view on the SAFE network project sounds negative to you, that was far from being the intention.
8 Likes
Thanks for responding Chris. I didnāt mean to suggest you were negative overall, but have pointed out specific instances where I believe you give your readers a misleading or factually incorrect picture. I think those points still stand (terminology excepted which you say has been updated - thanks).
For me it is not about negative or positive spin or attitude, but making statements that are consistent with the situation and the facts.
For example, you made some very strong statements, highly discouraging to any developers reading, about the difficulty of developing, and made no mention that these serious difficulties were being addressed as you published. I also explained to you that things - at this point in time - are not as difficult as you seem to believe them to be which is why I mentioned the already working dynamic web apps, written in JavaScript using the existing API, as well as the imminent improvements and extensions in this area.
I am not a MaidSafe developer BTW, Iām one of those āexternal developersā you were thinking of as you wrote, albeit one who is willing to dig around in the early stages of a project. Thatās how you gain commercial advantage after all.
You have now explained how your personal experience has been factored into your opinion in the article, but that experience was not presented in the article which prevents the project from responding to or address those issues.
Regarding the SAFE Ecosystem, which I pointed out is a major diferentiator of this project, you above take issue with one element that, with your current level of understanding, you deem impractical (pay once, store forever). Weāre not stupid here in this community, so we are aware that there are things about this project that appear implausible, or are hard to accept, and you are not the only person who wants to see this before believing it. Itās not even close to the most contentious such issue debated here
I have some scepticism about this too, but I do also understand the basis for this claim and can see that it could well work. So it should not be dismissed either, and even if you choose to do so, you could still allude to an ecosystem of rewards that the project has designed to encourage adoption by stakeholders: users, resource and storage providers, app developers, and core developers.
The project is revolutionary, and it has so much to it that nobody can be expected to understand or believe it all until it is working. Me too but I donāt think thatās a reason to dismiss that whole section especially if you are going to make comparisons with other projects.
As I said, itās up to you what you do with the feedback. I didnāt assume youād update your article, but I donāt think your reasoning for what you wrote stands up and I think you do your readers a disservice in key aspects. Particularly the situation that exists for interested developers, and ignoring key features that differentiate this project.
[Please be aware Iām a member of the community here, not part of MaidSafe and not a developer any more though I still tinker as mentioned. Iām a retired developer who has seen it and done it, and has dug deep into this project, and been continually impressed by it in all respects. This is why Iāve stuck around, and why Iāll take the time to give people feedback when they request it. Of course, people donāt always like my feedback or make immediate use of it, and thatās perfectly fine. I gave it willingly and in good faith, so please donāt take it personally, or assume that Iām expecting anything from you.]
13 Likes
Test8 is running with user Vault and try it, at least in most system, is extremely easy.
Vault (Only download and run)
Launcher (Create your account)
Demo App. (Create your ID, store data and pages)
3 Likes
Thanks for the hint, tested and updated the article accordingly. We started this review a few days before Testnet 8 was released.
8 Likes