We're happy to present you Apollo - our powerful CLI & UI tool to control your KLYNTAR infrastructure. With this tool you can do everything - use it as wallet, interact with decentralized services, control your Unobtanium sources, deep dive into Cryptoland-our amazing collection of crypto algorithms available on KLYNTAR.
As you've seen, KLYNTAR is in symbiotic relationship with other blockchains. By running different nodes of other projects, working with tools required by them, the most auful & irritating problem was problem with initial setup - misconfigs, old docs, semver mistakes, nightly versions and so on. That's why, we've prepared docker images to allow you to be sure that you'll have 100% succesful setup. So,let's start π
We assume that you have Docker on the board. You can install Docker for Linux & Windows & Mac here
klyntar@apollo:~# docker -v
Docker version 20.10.14, build a224086
We present you our first image klyntar/all_in_one. This is universal image with preinstalled Node.js, Go , Python and some tools like pnpm
, node-gyp
, git
and so on. We've created it to save your time and nervous system. This is the base layer for all our Dockerfiles(at least for core and Apollo). The aproximate compressed size is 606M. Also, in our repository KlyntarBaseImages you can find the sources of all base-layer Dockerfiles, so you can clone and build it yourself or find the bash build script and so through the process to install requirements to your host machine. But anyway,we recomend you to use containers.
docker pull klyntar/all_in_one@sha256:dff001a9cd3da6328c504b52ed8a5748c47d23219feae220930dac1c1981cfe7
We also recomend you to make port forwarding at least for default Apollo port 9691
This is the most default & simple way. If you need,you can manually do this with more advanced steps e.g. using volumes,set user and so on
docker run -dtp 9691:9691 --name test_kly klyntar/all_in_one@sha256:dff001a9cd3da6328c504b52ed8a5748c47d23219feae220930dac1c1981cfe7
Go into container to root dir
docker exec -ti test_kly bash
# Inside container
cd ~
Clone Apollo repository
git clone https://github.com/KLYN74R/Apollo.git
cd Apollo
Finally,run the only one command
pnpm run build
Now take a rest and see the building process. It may take some minutes,but you're free from self-install tons of libs,dependencies and walking among dirs
Working with different "hacking" tools,I've get the experience of so called 'best practises' of how to build real powerful tool. That's why, Apollo(as KLYNTAR) will be very modular. Just now,you have three ways to improve Apollo behaviour by loading modules to KLY_Modules, KLY_ServicesAPI and KLY_WorkflowsAPI
Directory for your external modules. This might be extra useful commands. Might be written by you or any other 3rd party. Must contain 2 directories cli(contains everything for commands in CLI) and ui(directory with everything for UI in browser). Soon we'll make a tutorial of HOWTO write modules for Apollo.
Each directory-is typically Git repository to allow you to easily update different modules independently if you need and swap versions. Moreover,soon you'll also have an amazing ability to verify authors cryptographically - via code signing. By having hash of repository you can verify authority and be sure that code is original using different crypto features like multisig or post-quantum cryptography,social staking and so on. We describe it in Basic Security in our MasteringKlyntar book.
- CLI part
In CLI extra modules looks like ordinary commands. To allow your users to differ them, please, give them original prefix or make a single command with repository name and hide commands to subcommands
- UI part
If module also has a UI part(which is often the case), then you'll have ability to visit:
http(s)://<your_interface>:<port>/modules
to find there the entry point to your module.
Apollo
β
β
ββββKLY_Modules
β β
β β
β β
β ββββinit(default module,the entry point for the other)
β β β
β β ββββcli(directory for files to improve CLI)
β β β β
β β β ββββinit.js
β β β
β β ββββui(directory for files to improve UI)
β β β
β β ββββroutes.js
β β ββββtemplates(.ejs files)
β β β ββ...
β β ββββconfigs.json
β β ββββ...
β β
β β
β ββββyour_custom_module
β β
β ββββcli(directory for files to improve CLI)
β β β
β β ββββinit.js
β β
β ββββui(directory for files to improve UI)
β β
β ββββroutes.js
β ββββtemplates(.ejs files)
β β ββ...
β ββββconfigs.json
β ββββ...
β
β
ββββKLY_ServicesAPI
ββββ...
To update the repository with module go to appropriate directory KLY_Modules/<your_module> and pull changes
ServiceAPI - directory with API repositories to interact with the scope of service runned on Klyntar. Imagine if all smart contracts on ETH will have a unique design in your wallet, separate page with all available features specific to contract. Since we have wider power, we also have so complicated way to improve abilities of your Apollo instance.
The same principle works for the services API. Each subdirectory - it's a repository. To check available services API go to
http(s)://<your_interface>:<port>/services
WorkflowsAPI - directory with API repositories to interact with symbiotes on Klyntar. Insofar as they can use different workflows(thanksfully to Mutations principle),we need to make possible to use appropriate algorithms,build right events to send to symbiotes and use other specific features like traffic over TOR or threshold signatures. Imagine if you'll have ability to control your Bitcoin, Solana, Avalanche, Cosmos assets(native coins,tokens,etc.), execute smart contracts, make delegations using only one instrument. Yes,this is what Apollo do.
The same principle as for services API. Each subdirectory - it's a repository in this directory. To check your symbiotes and how to interact with them go to
http(s)://<your_interface>:<port>/symbiotes
Follow us to get the news & updates ASAP. Discuss, share ideas, advices, help newbies to make our community more powerful.We're happy to involve new members to KLY community π
Read the docs here to find out more