So executable dapp code can run on a maximum of 16 full node servers, who then service X "lite" node runners who "log in" to use the dapp on the master nodes. Are these master nodes all Forging Delegates, all Standby delegates, or can they be a mixture of both? It sounds like the dapp author would want his side chain to be ALL on dedicated Standby Delegate servers and NOT on the Forging Delegate servers, because if ALL side chains are run by the 101 Club, they will get bogged down with running too many chains, right?
Does the custom side chain have to be running on the same 16 max master full node servers running the executable dapp code? The 16 master dapp nodes are processing possible changes / additions to the custom side chain and adding new blocks to it every 10 seconds, right?
Does this system mean that the owner of a dapp can send out a "contract closure" message to settle open contracts? If so, doesn't this mean a single server from the 101 club will have to settle all open dapp contracts within one blocktime upon receiving a closure trigger message? Isn't this really difficult, since the contracts can be scattered through many GB of the main blockchain? Will there be limits on the total number of open contracts or the time period over which they must be made and settled?
The process is the following:1.) Upload dappYou upload the dapp to Github or the 3rd party decentralized storage solution I mentioned earlier.
2.) Registering dapp X from account AWhen registering the dapp you have to specify some information, like name/category/source and so on. Account A can be a multi signature account with up to 15 other accounts. As the dapp X got registered within Cryptis main chain (for a fee in XCR) from account A it will be the "king of the master nodes". All multi signature accounts below account A, let's call them account A.1, A.2, ..., A.15, are the other master nodes of the dapp X.
Master nodes are independent of the main chain delegates. They can also be main chain delegates, but don't have to. You can simply imagine them as new delegates for the side chains. Taking care of the consensus there.
You can remove and add multi signature accounts, i.e. the master nodes are exchangeable at any time, of course only with enough confirmations from the other multi signature accounts.
3.) Install dapp XYou can now install the dapp, as it was registered on the main chain. The installation is only possible from the full clients. While the installation, the dapp source code will be downloaded from the source (Github or decentralized solution) and get copied into the Crypti directory, in a special folder for the dapp there.
You now see that the master nodes all have to be full nodes as well, and they all have to install the dapp. They also have to specify their passphrase in the dapp config, to be authorized as master nodes (only possible for multi signature accounts A.1, ...).
- The full clients are executing the dapp source code themselves, after the installation on their node of course.
- The lite clients are working via the API only. They need to pull the dapp informations from another node (both, master and full node possible). It's the same principle like pulling the regular Crypti data from full nodes today.
- The mobile clients are working the same like the lite clients.
4.) Starting / Stopping the dappFrom the full client you can now start and stop the dapp like a regular application. If it's running other users can access it, if it's allowed by the node owner.
The master nodes have to run the dapp all the time, same like delegates have to forge all the time. Because they also take care of the consensus of the side chain. The consensus is working very similar to the delegates on Cryptis main chain, i.e. the master nodes are creating blocks in the side chain. They also get the fees for the transactions within the side chain.
5.) Accessing the dappIf the node is running the dapp, you can access it with opening the following address: http://<IP>:<PORT>/dapps/<DAPPS ID>/
You can use your web browser, the Crypti Dapp Store or a electron/nw.js wrapper. The user interface can be similar to modern web apps, thanks to JavaScript. (If the dapp is well coded, it has the same user experience like Slack, Aether, Visual Studio Code, Crypti itself and many more..)
ConclusionSo optimally 16 master nodes are running the dapp, creating an untouchable base and providing the consensus (make new blocks). Additionally an unlimited number of full nodes are supporting the network of the dapp, for delivering a decentralized accessing option for the lite clients. To make a comparison again; the master nodes are the backbone of the whole system. The full nodes are acting like accessing servers, with the regular users accessing them with their lite and mobile clients. For now 16 master nodes are far more than enough, because they only have to take care of the consensus. It's not such a heavy task, at one point we might raise the number of possible master nodes.
I didn't understand all of your questions. I think you now have a much better image of the whole system and its functionality, if you still have questions you can probably much better describe them now.
I will include the above in the status update of this week, I think it helps other users to understand our vision as well.