Code Valley is bringing a multi trillion dollar industry into bitcoin. Safecoin should have a version itself.
http://codevalley.com/
4 Likes
That looks awesome kind of like a smart version of freelancer
1 Like
I picked this quote out from another topic, but it belonged in this discussion:
This is an interesting software design idea, but it seems to attempt to arrive at the very opposite of open-source software. All code with be non-reusable. All changes to the use of a third party components, require paying for additional service from that supplier. All code would be delivered in such a form that it could not be picked apart, inspected or re-configured, thus that means it cannot include any source code. It must be binary or something similar. I don’t see how code written in this way would be secure. As long as the code is passing positive requirements tests, it will not be known what else it is doing. It also sounds like the types of functionality for design specifications would have to be standardized.
It seems like a lot of political decisions would go into managing the system of design and that it would be consensus of experts? (or who?) that alter the rules of the system. I think this could introduce more problems than it is solving. It sounds like something big software firms might want to make the standard, and undercut the opening up of software through the open-source world, which it seems is a growing movement.
I wonder, why is this crisis in software the biggest right now? What about the security and privacy crises going on, that involve untrustworthy algorithms or software that is adopted without knowledge of its inner workings? This would certainly do nothing to provide transparency regarding software, it would just be spat out of a black box, with the consolation that it appears to do what is expected. This idea raises some red flags for me, but it is still interesting and I would be curious at how such a system would function. Maybe they have in fact made it transparent and have ways to verify that code you’ve contracted out for is not only doing the things it is supposed to, but is not doing anything that it was not supposed to. According to the authors that would require stealing someone’s intellectual property to know what the inner workings of the software are, so that is why I conclude that it would not be very secure if based on intellectual property and totally opaque sourcing of binary software components, even if built around a standardized design requirement system.
For instance, would anyone want to use a code-farmed safe network software for sensitive communications? Without having transparency as to what code is doing for those willing to look, it is anyone’s guess. A closed-source SAFE network developed by Microsoft would also be worthless as a security improvement, despite the fact that they might attract customers and gain the trust of some. The authors of this paper seem to be on a totally different page from that perspective.
Feel free to correct me if I have misread this proposal.
3 Likes
Yes but I envision a different open source version running on multiple computation backed coins.
2 Likes
Exactly! The problem now is that software development relies on intellectual property rights instead of payments from actual use, like what will be possible on the SAFE Network. By shifting how people get paid - you can shift the paradigm on how software can be developed.
3 Likes
We appreciate you taking the time to read the proposal. The concerns you raise are valid. In a nutshell, it seems to come down to; “How can one trust an application built by this system when nobody can inspect the code?”
There are three reasons;
(1) Acceptance testing – When a vendor is newly created, the developer will not publish that vendor to the Valley for all to see and contract until they have done their due diligence and tested that the vendor does what it should (and nothing that it shouldn’t). To do that, the developer will ‘tap into’ the supply-chain at the level of their newly created vendor and build a small program by contracting their own new vendor. Once built, they can run that program up and carry out acceptance testing to ensure that the program works (which confirms that not only the developer’s new vendor does its job, but it also confirms every single supplier beneath that vendor that went into the build also does its job). This is a powerful mechanism for assessing the validity of suppliers (and supplier’s suppliers etc.). Once the developer is satisfied, they can publish and begin trading. (You can see an example of this acceptance testing in action on our site in Docs (Exercises).)
(2) Contextual limitations – Firstly, to build a backdoor or the like into the application, the developer would have to build a vendor that sits in the only part of the supply-chain that knows what type of application is being built; the behaviour layer (and some of system). So the scope in which a malicious player can do intentional damage is limited to a smaller area. Secondly, the only vendors who actually ‘touch’ the code (and are therefore theoretically capable of ‘adding’ malicious code) are foundation vendors. But these vendors request space in the construction-site for mere bytes. So (a) a foundation vendors would have to request space for thousands upon millions of bytes (red flag to the client) and (b) the foundation vendor would also have to know what application is being built so they know how to add the necessary malicious code (in the form of binary CPU instructions). But foundation vendors are so contextually removed they never know what application they are contributing to (nor should they need any such knowledge).
(3) Reputation – There is strong accountability at every level of the supply-chain. Each vendor’s metrics and stats are recorded against them in the Valley (the directory where all vendors are advertised when they are published by their developer-owner). One of these metrics is the code/data/vars footprint. We can obviously not compare the footprint of a foundation vendor with that of a behaviour vendor. However, we can certainly compare the footprint of two vendors competing to provide the same feature. When there are many competitors filling each void, their footprints should be comparatively similar. Of course, the smaller footprints are indicative of a superior vendor, capable of negotiating at build-time to optimise their design and have a smaller footprint in the final executable. Any anomalies that tend towards the large side indicate one of two things; either the vendor is malicious and is returning much more ‘code’ than it should (i.e. its feature has ‘undesirable’ or malicious features incorporated into it) OR, the vendor is just plain ‘dumb,’ and has not tried to optimise its design in order to keep up with its competitors. Either way, it is highly unlikely a vendor will ever be contracted in either scenario, and doing so would reflect badly on the client vendor’s own footprint (and so on).
1 Like
I appreciate you responding to criticism and questions. Your answers show you have thought these issues out and have some confidence that they can be kept in check by other means than direct transparency. I would be interested to see this system in action. Thanks.
Even though I am not an expert developer I have signed up with Code Valley for their initial release and was acctepted. Just want to see if I can manage the process of producing software on there because if I can I have unlimited use for such an ability.
1 Like
Only 1 week still
