Always happy to get feedback.
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.
A very decent article, some suggestions for revision…
Not blocks, but chunks
Not SAFE coin, but Safecoin
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.
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!
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
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.
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.
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.
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.
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.
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.]
Test8 is running with user Vault and try it, at least in most system, is extremely easy.
Thanks for the hint, tested and updated the article accordingly. We started this review a few days before Testnet 8 was released.