A brief introduction to ZelFlux. Briniging life to ZelNodes.

credits to David/All_systems_go

ZelFlux is an application that let’s you interact with both — a local ZelNode (referred as masternode, or simply server, vps) ZelFlux is running on and also with the Zel network as a whole. This means that one can monitor local ZelNode, execute local commands, use file sharing system, interact with local applications and also review the whole ZelFlux network — managing applications running on all other Flux solutions.

From a technical standpoint Flux is based on Mongo, Express, Vue, Node (modern MEVN stack) with a dockerized application system and thus Docker being the fifth crucial component finalizing our MEVND stack.

As above indicates, Flux is written in Javascript utilizing Node.js as the running engine. On the backend sits powerful combination of Express.js that gives flux extended 4 tiered rest API together with WebSocket and with the help of Mongo.db one can create nice database structure that can store data about connected users, system, application and more. Frontend is written in Vue.js framework being sort of a wrapper and easy way of interacting with the API backend of Flux in a user friendly way. Speaking of Docker, its container solution is used for third party applications to be run and managed by Flux. Any application, from a simple static website to some computational heavy weather calculation, that can be dockerized can be later deployed to Flux solution. That means that you can write an application in any language and just create a Dockerfile. *Here should be stated that in a first batch only self sustaining application with a single and reasonable hardware requirements are eligible to be ran. In the future we plan to extend this so if one docker app is dependent on another docker app, it won’t be an issue and Flux will handle it nicely.

So Flux consist of frontend and backend solution each running on specific port 16126, 16127 respectively and is using MEVND stack.

Let’s talk about the backend. This is where magic happens anyway right. Firstly we will talk about interflux communication. What it means is that Flux needs to be able to talk to other Flux instances. Verify that they are indeed part of the correct network and verify that messages that are being sent and received are not obsolete, are truly from a sender, can be trusted and so interacted with.

Flux uses websockets for its internal communication. Communication goes as follows:
1. Start peer discovery

  • This is where zelcash comes into place. Flux is communicating zelcash running on the same server. Asking for an uptodate deterministic zelnode list. It is a zelcash and zelbench daemon responsibility to make sure that the list is correct and it can be trusted. Obtaining the list essentially means obtaining the list of available IPs on which other Flux instances run.

2. Select pseudo random IP and try to establish websocket connection

3. Send messages

  • Every message that is flying across Flux instances is a a serialized data of following object containing: timestamp, type, public key, data of broadcast, signature of data
  • So other node know what type of message it is, if its an application type, heartbeat, just some message, simply how to treat the message. From timestamp we know when this original message was broadcasted, public key of zelnode that broadcasted the message first and a signature of the data attached
  • So Flux instances are only accepting messages if time is in accordance to expectation, type is a recognizable value, signature of data matches the public key and public key is a confirmed zelnode on zelcash network.
  • This states that any server can run zelflux but cannot join interflux communication as simply their messages will be rejected

4. Keep communication alive, sending heartbeats

5. Rebroadcasting of received messages to other connected peers

6. Keep track of connected peers, don’t connect to the same peers.

7. Ensure a minimum of X connected peers, try to add new peers every Y seconds otherwise

This sort of maps the early stage of our interflux communication

Flux API

As mentioned above, we can divide flux api to 4 tiers depending on privileges: public, user, zelteam, admin. Meaning some parts of api are publicly available and do not require you to firstly log into the zelflux and attaching zelauth headers. (you can read about authentication workflow on zelfluxdocs: https://zelcash.github.io/zelfluxdocs/#section/Authentication). Other api levels requires a login and grants more and more access to certain api calls up to an admin which has basically access to manage all server related stuff. Admin user is chosen by the ZelID entered with the ZelFlux installation. ZelTeam role is a special role for Zel Team granting higher privileges allowing Zel Team to for example update Flux running on a specific server. The Zel Team ZelID is hardcoded into ZelFlux.

API can be divided currently into 5 major groups depending on the interaction that is being done: ZelID, ZelFlux, ZelCash (that also means you can run any zelcash call via your browser), ZelNode and ZelApps with maybe more categories to come later. All API calls will be described on the zelfluxdocs.

Apart from traditional restful API, websocket option for certain calls is also possible expected to be expanded for all needed scenarios.

ZelFlux UI

The user interface is written with the help of Vue.js and provides a simple way of interaction with the Flux network. All calls that are available via API will be in the future implemented into the simple UI Flux provides. As Flux is basically just the Backend, we can expect a lot of variation of the UI built around those calls. UI also comes with a simple one click login option via zelcore desktop/mobile connecting zel platforms together with the help of ZelID.

Last words..

Flux is here and will stay. It is a game changer where traditional boring masternode is being transferred to run useful applications. It brings accessibility of a not only server interaction to masses via a website. The entire Zel network now serves a much higher purpose, purpose it was initially built for. Thank you for your community contributions.

TheTrunk. Just another dev.