Goals of the feldmanchain

[GGAlanSmithee]

As mentioned in the Why not Use X discussion, we should formulate clear goals to help us make better informed decisions regarding technical and business related choices.

As I see it, the super high level goal of the feldmanchain is to:

facilitate a local¹ - and eventually a global - decentralized and distributed system for building source code.

As per private discussions, the problem we are attempting to solve is to guard against overreliance on build systems that are centralized and comes with potential risks of a lack of redundancy, single points of failure, congestion and energy efficiency concerns. With this in mind, we can derrive (a little bit more concrete) high level goals:

1. As a project author / end user, it should be possible to make a request to the system to carry out a build of a project
   • the system should guarantee the privacy of my source code
   • I should be able to affect how the system participants prioritises my build
   • the system should provide some guarantees to response times
   • I should be able to affect how the system participants prioritises my build
   • I should be able to predict, and limit, the cost of my build
2. As a system participant / node, It should be possible to accept and carry out a build of a project
   • I should be able to affect how and when I want to process builds

The idea behind implementing this as a bockchain is to take advantage of the decentralized nature of the blockchain, which could help to mitigate/solve some of the above-mentioned problems. However, there are some aspects of this project that is not well suited to be handled within the standard definition of a blockchain, such as the need for privacy. It is also need clear how a ledger would fit into a system like this, but I can see a clear upside of the applied game theory mechanics and self governaning nature of a well implemented blockchain. It is still unclear to me what / if the (monetary) insentives would be within this system, but done right, it could provide a nice model for auctioning and accepting build requests (transactions), hopefully resulting in a natural balance of sorts, but that is something to explore further.

It could be argued that there are coins with little to no intrinsic value that is still doing well, but that is often in the context of an established blockchain, and I don't think that is an avenue worth spending time pursuing, since we want to deliver something with real value, both technically and business wise.

This post is just to get the conversation started and in no way representative of the final goal(s) of it. Please contribute with any and all ideas.

¹ as within a company or organisation

[GGAlanSmithee]

Another thing that came up in conversation with @brokenprogrammer is how to prevent malicious behavior, such as code injection, by the builders in the network. We could do a soft prevention with something like a reputation system, but it would probably be a good idea to think about how (if) we can implement a hard prevention.

As previously mentioned, we have three different "levels" of application:

1. as a system for building internal projects (on-premise, in a trusted intranet)
2. as a system for building open-source projects
3. as a solution for building private source code in a global network

Each of these levels requires a different degree of diligence in regards to security, so we should probably talk about the scope of an initial version. Do we want to try and solve all of the above issues at once, or start small? I can see solving point 1 as being technically much easier, but it is not clear to me exactly how that would translate into point 2 and 3.

[GGAlanSmithee]

I think another point, which is implicitly stated, is that;

1. As a system participant, I do not want to have to rely on a trusted third party
   • The system should facilitate secure and fair execution of source code builds in a decentralized manner
   • The system should not have single points of failure
   • The system should be self-balanced and self-governant

This is kind of the whole idea of the concept, but we should spell it out for clarity. These a quite lofty goals, but let's aim high.

Also, another point which can make sense:

1. As a builder node and/or system validator/auctioneer I want to receive fair compensation for the work I carry out
   • The tokenomics within the system should be implemented such that the compensation is fair for all parties