RE: MaidSafe Review - The Next Internet Will be Ours

[happybeing]

Cross posted as an alternative to the OP being updated, here is my feedback in response to the author's invitation to members of the SAFEnetwork forum...

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. :slight_smile: 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 :slight_smile:

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! :slight_smile:

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! :slight_smile:

Comments

[iainc]

And for the sake of keeping the discussion consistent, here is my answer from the SAFEnetwork forum:

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.

[happybeing]

And mine also from the SAFE forum :-) ...

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 :slight_smile:

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 :slight_smile: 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.]

[officialfuzzy]

Just to let you guys know. This thread updated me quite a bit on maidsafe. Id love to have them join our hangouts sometime to talk more about it. So if you think this little back and forth was negative in any way at least know I walked away with some good crypto value for my brain ;)

[iainc]

Happy to hear that we were able to provide some value (and hopefully a little bit of entertainment). I'm an avid listener of Beyond Bitcoin (whenever I'm in my car).