Actors and Roles based Systems

While studying the whitepapers of Steem, BitShares, Status or Icon, one repeating pattern becomes obvious: Decomposition. In my programming classes I had a professor teaching us the principle of divide and conquer: is one task top complex, just decompose it to smaller tasks that can be implemented separately. This is true for every industry. Consider car manufacturing for instance. Opel, BMW, Mercedes or Renault, they all come with parts that they buy from Bosch. On an abstract level car manufacturers are just marketing agencies that outsource the development of new models to sub-contractors who recombine the modules of third parties to ever new shapes. All this while the end customer perceives a car brand as a closed entity, it actually is a interface to the retail market for a complex network of companies. 

Many authors of whitepapers start by decomposing the underlying domain in roles that can contribute separately and go on by finding ways to incentivize them in their contribution. One of these roles often is the Referral who gets rewarded to add users to the system, just like the car brands sell cars.

One example: 

To receive push notifications in the social network Status, the user has to subscribe to a push service. This push service receives a fee. This seems odd but reminds me of the early days of the iPhone, when I had a app that helped other apps to send me notifications. I had to pay for notifications, since the push service had no other source of revenue but costs for hosting. Another service in Status is curating the content that flows through the users timeline. The curator also earns on fees. In a centralized social network, the same components are in place, but they sit next to each other in a data center and they are fixed and can't be switched to use a different service. This leads to different social networks that serve different purposes because the components can not be recombined according to the needs of the end user.

The decoupling employed by Status seems to be a disadvantage at first, because it requires the user to pay fees and introduces additional complexity for implementations. Composition systems in software development had a long way to go from the early CORBA over SOAP to RESTful web services. On the way a lot of concepts proved to be not practical, mostly because of the complexity they introduce, or lack of interoperability with different programming languages. But eventually everything got wrapped in components and stacked together, to keep up with the complexity that would otherwise arise from monolithic applications. So while it is obvious that things can be improved, the important take away is that there has to be a path for evolution.

One reason why software developers like components is because they define a interface and don't care about the implementation. This allows them to be switched to a better implementation. Progress accelerates by reducing the cost of variation. Faster progressing companies or projects have a competitive edge. So while the services on the current Status are barely able to keep up with Facebook, Status has the chance to progress faster than Facebook. Thanks to decentralization, different stakeholders work on the same product independently of each other by focussing on different aspects. Thanks to flexible composition, solution providers are in a competition with each other for the best solution to each particular problem separately, comparable to vendors of ad blockers.

Splitting up Facebook in its core parts starts by identifying the roles and actors, study their contributions and incentives and reward them accordingly. It goes on with defining rules that create a market which is specific to the target domain of social networking. Since the rules are implemented in software, the market can be adjusted trough governance. The associated smart contracts and the corresponding currency serves as the glue to integrate the system. 

Additionally, the same services are needed in other markets of the same kind, since they are dictated by the characteristic of the product and not by its implementation. A different decentralized social network like Steem will need a curator engine as well. This way markets are in competition with each other over the best environment for their stakeholders. 

Even the blockchain that serves as infrastructure to run the smart contracts and perform transactions is subject to evolution. Project Zeyphir foremost defines a governmental process to start with a simple general purpose blockchain and evolve to a tailored set by updating the core set of rules that make up a blockchain.

I strongly believe that every platform business can be decomposed in the same way. I emphasized the dimensions of flexibility that will allow the decentralized solutions to work trough their competitive disadvantages.