| description | cover | coverY |
|---|---|---|
The detailed overview of our CLI & UI tool to control your KLY empire🪐 |
../../.gitbook/assets/wallpapersden.com_76925-2932x2932.jpg |
277 |
Since KLYNTAR is a project of "cosmic" scale, the tool for interacting with it must be appropriate. Many different projects or companies name their products/protocols after famous scientists, historical figures or events. In this aspect, we will also support a public flash mob and therefore decided to name the tool for interaction with KLYNTAR in honor of an important event in the field of astronautics and space exploration - the well-known Apollo program, the very one during which humanity first set foot on an extraterrestrial body, namely - on Moon.
We are pleased to introduce Apollo, our powerful command line and user interface tool for managing your KLYNTAR infrastructure. With Apollo, you can do everything - use it as a wallet, interact with decentralized services, control your Unobtanium sources, use the power of Cryptoland - our amazing collection of crypto algorithms available on KLYNTAR and much more!
Here you will learn how to get started with Apollo, some basic guidelines and help to get started with KLYNTAR faster. We plan to show you how to load modules, how to write modules (if you are a developer) to extend both the CLI and UI, how to control your node clusters, and so on.
Since this is a fairly powerful tool (and not just a CLI with a preliminary list of hardcoded commands), we will try to give you the most important thing - a basic understanding of how it works, how everything is interconnected. It is worth saying that Apollo differs from other similar tools like Metamask, Phantom and the like in that all kinds of service developers on KLYNTAR will be included in the work here to create personalized interfaces directly for each service, symbiote or group of services. This is equivalent to the fact that the developers of smart contracts of EVM-compatible chains that you use in the same Metamask would offer a unique interface for each smart contract.
So, for example, if this is a DeFi service operating in the KLY ecosystem, then in the interface you will see the necessary data, fields, the latest news from the Twitter feed of this project, and so on, if this is the main menu of Apollo, then you will also find ads in the running line on offers of staking your unobtanium to some new services where you can decide what is more profitable for you - stake your unobtanium mined by the BTC miner and get a place as a service validator or confirm the amount of reserved storage in Filecoin and leave unobtanium for future voting for the most useful plugins for KLYNTAR as part of the social consensus procedures, and by going to wikipedia.org or reading some article on Medium, you can thank the authors and get some exclusive content from them. And all this in one black box called Apollo. I think my mouth is already flowing, so let's go 🤤
It is better to show once than to say 100 times. With this attitude, we proceed to the launch. As you have probably read before, KLYNTAR is in a symbiotic relationship with other blockchains, both existing ones like Bitcoin, Avalanche, XRP, Solana, and those that will only be invented in the future.
Starting various nodes of other projects, working with the tools they needed, the most terrible and annoying problem was the initial setup problem - incorrect configurations, old documents or bad documentation from developers, versioning errors, nightly versions and so on. That's why we prepared Docker images so you can be sure that you will have a 100% successful installation. So let's get started 🚀
{% hint style="warning" %} NOTE
Before starting the installation, make sure you have Docker installed. If not, you can download it for Linux & Windows & Mac here {% endhint %}
To check if Docker is installed type
klyntar@apollo:~# docker -v
Docker version 20.10.14, build a224086We 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:dff001a9cd3da6328c504b52ed8a5748c47d23219feae220930dac1c1981cfe7We 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:dff001a9cd3da6328c504b52ed8a5748c47d23219feae220930dac1c1981cfe7Go 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 buildNow 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.
\
Summarizing this,your directories tree on these levels should look like this
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>/servicesKLY_WorkflowsAPI
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>/symbiotesFollow 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\
:flag_gb::
:flag_ru::
