zApps

Defining a zApp/
Zero Applications (zApps) enable developers to build and deploy custom applications that can be run by Nodes within the Zero Grid. zApps in zOS can be thought of as miniature programs that store and manage custom-defined information. 
zApps are defined with the specialized Message type 'zApp:[zAppId]:[ObjectType]:[PermissionHash]', with the associated application state residing in the 'content' parameter of the Message. '[ ]' indicates a Member-generated look-up value for a respective zApp and functionality set. The definitions of these parameters are as follows: 
zApp: This specifies that the Message is a custom defined zApp
[zAppId]: Similar to a zId, a zAppId is a unique and randomly generated hash to represent a specific zApp and version number. 
[ObjectType]: This specifies a custom defined Object Type that is used to break up application state into small chunks of data. Example ObjectTypes could be 'Posts', 'Tasks', or 'MarketItems'.
[PermissionHash]: This specifies a PermissionHash that is generated using a SHA256 hash of a 'permission object' by the Message signatory. Permission objects require the following format: { read: {zId_1, zId_2...}, write: {...}, delete: {...} }​​
Simplifying a zApp's application state into small chunks ensures that Messages remain reasonably sized and are efficiently propagated through the Zero Grid.
Given that zApps are defined purely at the level of state, clients are responsible for how to interpret this state, as well as ensuring that zAppIds are consistent between clients and relevant Messages. Adding a new zApp is as simple as signing a new Message to a zChain, which other zChains can then choose to interpret or not, depending on the application logic they have chosen to run. Given that zApps are just custom Messages, they can be added to any type of zChain, including an Identity, Account, or Network. 
zApp Store/
zApps require a corresponding interface to interpret and display state inside of a client. Zero intends to make a front-end component kit available to make it easy for developers to build visually consistent interfaces inside of the Zero Application. 
Zero plans to add an zApp Store (similar to the iOS store or Google Play) that enables the installation of zApps that exist in the Zero ecosystem. To prevent malware and malicious software, application Verification will be introduced and managed using a fully decentralized process by zDAO/. Pertinent details will be released in advance of the launch of the zApp Store.  
Dynos/
Nodes in Zero can choose to operate Dynos. Dynos are containerized virtual environments that make specific applications or services available to Nodes in the Zero Grid. Unlike peer-to-peer only systems like IPFS, BitTorrent or Ethereum, Dynos enable Nodes to run and deliver virtually any type of distributed environment to the Zero Grid, including cloud infrastructure.
Dynos are intended to be easily instantiated, configured, replicated, and non-persistent, meaning that they can be easily spawned or destroyed without consequence. Dynos exist to serve a particular service rather than act as long-term data stores. In this way, Dynos are analogous to dynamic application servers in traditional cloud architectures, that can scale up or down depending on network load. The main difference here being that any Node in the Zero Grid could choose to provide these services, rather than a centralized company. This enables the Zero Grid to use the speed, availability and scale of existing cloud providers for certain use-cases, without sacrificing decentralization. 
For instance, a Member could choose to run a set of Video Conferencing Dynos on AWS under their own name and credit card, and recieve Credits based on the Dynos usage. A Dynos binary code is open-source and verified with a cryptographic proof, so other Members would be able to ensure that no personal data is collected at the server-level, and the service is operating according to what it is advertising. 
In order for a Dyno to receive Credits its binary must be approved by the Member. Credits can then be issued in exchange for the operation and utilization of the Dyno, depending on Dyno performance, along with market supply and demand. This is outlined in more detail in Section 4.2.6. The Creditor. 
Dynos can be thought of as similar to AWS (Amazon Web Services) services, such as EC2 instances or s3 buckets, but at a higher level of abstraction. Dynos provide a new incentivization, security and decentralization model on top of existing cloud-architectures that is agnostic.This provides flexibility for pricing, the possibility for many service types, as well as enables the network to dynamically adjust the availability of different Dynos, based on the real-time needs of the Zero Grid. 
Example use-cases for Dynos include:
Messages Pub: A Node that increases the speed Message propagation for other Nodes on the Network.
Video Conferencing: A Node that routes encrypted peer-to-peer video traffic to reduce latency for multi-party video conferencing.
Live Streaming: A Node that manages connection speed and bandwidth capacity for individual live streams. 
Virtual Worlds: A Node that enables low-latency and persistent virtual worlds. 
Dynos are authorized and installed on a Node by signing a new Message to a Member's local zChain with type 'Dyno:[DynoId]:[binaryHash]:[filecoinAddress]': 
[dynoId]: A unique Id that represents the Dyno and container version on the Network.
dynoType: A valid dynoType as defined by the Dyno Matcher (e.g. videoConference, virtualWorld, etc.). 
[binaryHash]: A sha256 hash of the Dyno's container binary that is used to ensure version consistency and that the file has not been tampered with.
[filecoinAddress]: A static location to download the file from the Filecoin Network.
This process begins the remote installation process of the Dyno binary from the provided Filecoin address, and then performs a checksum on the file to ensure the binaryHash is valid. Once the Dyno has been verified, it is added to the zOS run-time environment and the Node begins to propagate Messages within the Grid, signaling that the Dyno is available to connect to. 
Compared to simply propagating Messages like a normal Node, Dynos are designed to provide services that require more dedicated, consistent, and low-latency connections on a single server. Given this fact, once a Node discovers a particular Dyno, its connection generally needs to stay persistent for the duration of the process provided by the Dyno. For instance, a two-hour video conference between ten network participants requires a fast, stable, and persistent connection. This is a significantly higher bar than routing a single small sized Message between chains.  
The Dyno Matcher describes the process of matching Nodes with Dynos and the stack-ranking that occurs to ensure that Nodes connect to the highest grade Dynos within the Grid.
Last modified 2yr ago