apollo

description	cover	coverY
The detailed overview of our CLI & UI tool to control your KLY empire🪐	../../.gitbook/assets/wallpapersden.com_76925-2932x2932.jpg	277

🌚 Apollo

👨‍🚀 Gratitude

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.

⚡Short intro

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 🤤

🏗️ How to build

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.

Running with Docker

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 a224086

Download the image

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

Run container

We also recomend you to make port forwarding at least for default Apollo port 9691

NOTE

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

Final

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

\

The signs that build was succesful are messages to console like this

...and this

Now try to run. You should see the following

⚙️ Modularity

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

\

KLY_Modules

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

KLY_ServicesAPI

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

KLY_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>/symbiotes

🤓 Advice

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 😊

📚Docs

Read the docs here to find out more\

:flag_gb::
:flag_ru::