Project status
Closed this issue · 3 comments
Some questions for the developer:
What is status of this project?
Where is development happening?
Why are some existing source code files hundreds of lines long?
Where can one find the specifications this software is being built from?
Hi, thank you for your interest in Flux.
a) Project is currently under active development with a minor release of 65.
- Currently you can completely manage all aspects of the node from flux api/ui.
- Entire communication with zelcash, zelbench daemons is established
- There is interflux communication, meaning fluxes communicate with each other via websockets and have correct messaging system
- It also functions as complete explorer for zel network
- There is application layer, with Folding at home being the POC, it is so possible ot launch and manage local apps
b) Currently to development focus of the project is being pushed towards launch of global applications.
- We have rewritten the block processing of zelcash blockchain as we discovered a bug on addresses containing around 150k+ transactions wont being stored properly. That is now all fixed and also comes with up to 3 times performance boost
-> So syncing entire flux on top of the zel node shall take around 10 hours on 4 core machine (super middle tier node) - That is the version 64, and 65 fixing reindexing/rescanninning where it was possible under certain scenarios to have more block processors running
Firstly I shall talk about how even apps (which essentially is a docker) are spawned on flux and why we need some further scanning of zel chain.
Spawning an application works in 3 steps.
- Register an application on any flux node
- You can already test this functionality on any flux node and fill the registration form. It is a simple form asking what is your app name, what port is being used, what env variables, what is the docker image, what are the hw specifications and so on filling all parameters needed for flux to know exactly how to launch the app.
- After this registration form is filled, several validation checks follow and if all goes well you will see an application hash. Fruthermore you will see a zel address and an amount of how much you have to pay for a 1 month of running such an application.
- Obtaining this application hash also means that all the app specification have been succefully broadcasted to other fluxes and so most of the network now have this so called temporary registration message.
-> This first step is all done, tested and working correctly
- In first step we got an app hash, zel address and amount. Now you need to perform a transaction on zelcash blockchain. To the obtained zel address, with that specific amount and the app hash as a message in op_return field. It is important to know that there is only 1 hour interval (from the initial registration in step 1) in which this transaction has to be mined on the network. If its not mined in time, the app data is lost and new registration and payment has to be made.
- Now comes the part of why flux needs a block processing (apart from being an explorer of zel blockchain). Previously we have sent a transaction containing a hash of app specifications. Since flux is continously scanning the zel chain an processing blocks, transactions. Flux now knows that the temporary broadcasted registration message is valid and can move this temporary message to permanent flux message storage.
- Further nodes that did not have this temporary message are beginning to request such a message from other flux peers as they noticed - oh this is a flux app message but I do not have it, lets ask my peer for it.
- Now all flux nodes have information about the flux application specification and can begin to proceed to step 3
-> This is all coded and is being tested
- Lastly flux needs to spawn the application.
- From app specifications we know all the requirements an app needs and so fluxes will try to spawn such an application if they have a capability to run it and if conditions of spawning (such as number of instances running it) are met.
- If all goes well, flux nodes know exactly where each application exists and can decide if and where to spawn another instance to satisfy the requirements.
-> This is like 80% coded.
Then there is the other stuff regarding application management post launch, such as modifying, updating, executing commands, extending and so on. That needs to be completed before public launch as well but is less time consuming
Project is actively developed in develpoment channel, master channel is for stable releases from which Flux nodes get their code.
I would say vast majority of a discussion is being done in our discord channel.
You can also check out portion of Flux documentation at https://github.com/zelcash/zelfluxdocs https://zelcash.github.io/zelfluxdocs/ or if you prefer swagger ui at https://zelcash.github.io/zelfluxdocs/swagger-ui/
-> Documentation si under development as well where most calls are documented with great resopnse, but many are still missing and several may be different
c) I think this touches style of coding. It surely can be improved and someone may prefer many small files, splitting it. I have set it up this way where one file touches one portion of flux. Eg. zelappsService touches all services of the applications which consist of services, some helping functions, some api functions. That all can be splitted. Most likely several functions will be rewritten later to better support test suite.
d) Such a document is not really in existence. Several specifications are documented in the code where living as live schemes before actually coding it or in zelflux docs. But since basically all work is done by me, I never really bothered to write publicly write some more robust specifications - eg. specifications messages between flux, zelapp registration specifications, signing of api calls, sequence of apps creation/ registration. Most of it can be deducted from the code and a sample UI included. But I agree that such a document is crucial for ongoing development and community participation
All three points described are now finalised, tested (even live publicly) and will be in production soon.
Global Apps registrations are still being disabled with simple parameter marking them inactive. So technically just by adjusting one parameter, you can create your global application and test it on your local network (nodes that have the parameter adjusted)
The focus is now on the application management.
#123
Flux v1.0.0 is now released and users can begin spawning their own applications very soon -> release notes :)