The bytescript actors

In my previous post, I explained what the bytescript syntax looks like. In this post, I explain how the actors of that ecosystem interacts together in a decentralized manner.

The bytescript ecosystem is composed of decentralized actors where each entity delivers one (1) service in order to support the ecosystem.

The decentralized ecosystem we are building is composed of different kind of users that each provide different kind of value to the ecosystem. Each actor will use different client tools in order to interact with a series of inter-connected blockchain databases.

The customers

Customers consists of big and small enterprises that need to manipulate data using the bytescript software, but don’t want to write the recipes themselves. They need an interface to search the ecosystem and see if the recipe they need has already been written by someone. If yes, they need to be able to buy a license of that recipe and receive a copy of it. If not, they need to be able to request a recipe to be written by a developer and when available, buy a license of it.

The developers

Developers consists of anyone that can write bytescript recipes. They need to be able to search in the ecosystem for requests from customers and write a recipe that matches the request, then push it to the ecosystem. When they push a recipe to the ecosystem, they need to be able to select a custodian that will have a copy of their recipe and answer the customers when a search matches their recipe.

The custodians

Custodians are enterprises that are available to host recipes for their clients: the developers. When a developer pushes recipes to the ecosystem, he needs to select a custodian that will host his recipes for him, answer customer’s requests when a recipe matches a customer’s requests.

Developers are not always online in order to deliver recipes to customers. The custodians are and fullfill that hosting need in a decentralized manner.

The nodes

The nodes are the peers that hosts the decentralized software that hosts the logic of the ecosystem. When any other actor sends a request to the ecosystem, he actually sends the request to one of the nodes. Each node then sync together in order to create a state using a blockchain-based database.

The advertisers

The advertisers are people that can refer any actor to our ecosystem and profit from that referral, including other advertisers. If an advertiser refers a custodian, for example, he will make a percentage of that custodian’s revenue. If he refers a customer, he will receive a percentage of that customer’s expenses.

The moderators

When a custodian answers the request of a customer but the customer creates a complaint saying the recipe did not fullfill his request properly, moderators will manage the complaint, receive the recipe and the request and vote in order to decide if the request was fullfilled properly or not.

If a request was not fullfilled properly, a bad score will be given to the custodian that tried to cheat. Otherwise, the bad score will be given to the customer.

The repercussions of having bad scores will be explained in a later post.

Conclusion

Each of these actors needs to use different client tools in order to interact with a common inter-connected graph of blockchain-based databases. Each database contains its own software that fullfill a specific need. Each database can also interact with other databases in the ecosystem.

My next series of posts will build that ecosystem of blockchain-based inter-connected databases. It will also explains the different clients that I’ll build in order to interact with the ecosystem.

What’s next

The first database I’ll build is the referral system. I’ll show how advertisers will be able to refer actors to the ecosystem and the gamification behind it that gives a reason for people to follow the referral links.