Skip to content
This repository has been archived by the owner on Sep 12, 2024. It is now read-only.

Latest commit

 

History

History
106 lines (63 loc) · 6.19 KB

plugins.md

File metadata and controls

106 lines (63 loc) · 6.19 KB
description cover coverY
What makes KLYNTAR truly powerful
../.gitbook/assets/thumb-1920-1065736.jpg
260.31088082901556

🔌 Plugins

What's this?

Earlier we wrote that modularity and extensions are one of the pillars of KLYNTAR. It is convenient when the system is not oak, it is easily supplemented with new features, useful APIs, and all this thanks to the many developers who will permanently improve it.

In the documentation, you have already noticed this at the level of symbiote workflows, at the Apollo level, and so on. Now let's talk about top-level plugins that are more general. Let's give a simple definition

{% hint style="info" %} A KLYNTAR plugin is a separately downloadable repository for your node / infrastructure that allows you to extend and / or improve the behavior of KLYNTAR {% endhint %}

Usage

Speaking about the importance of plugins, it is enough to simply list the potential number of use cases for which they are suitable. Here are "just" "a few" examples:

For bots

Launch a server for a bot (Telegram, Discord) that will inform you about events on the symbiotes on which your nodes work, which will allow you to make payments in Telegram without leaving your favorite messenger. Well, or at all - give your bot more privileges for maximum opportunities

For custom logging mechanisms

Getting detailed information about what is happening is an extremely important element. With the help of plugins, you can flexibly and dynamically change and receive logs that will be necessary for you

To extend available APIs

Of course, we will also constantly improve and supplement the existing set, but here you will also get great opportunities for control

For dynamic removal of telemetry, launching your explorers, etc.

Convenient when you get the actual explorer out of the box

To run snapshot validation, compression, and transfer

We previously wrote about betting on fortunes. It can also be used for faster snapshot loading, various checks using cryptographic magic and much more.

To dynamically generate a list of connected nodes

Blockchains usually work in a P2P environment and each node has a list of other nodes connected to it. Through plugins, it will be possible to add logic for adding or removing them from your list

To set listeners for DB events

The first implementation of the KLYNTAR core uses LevelDB which supports handling of interaction events with the database

To install gateways in the TOR /** I2P /** ZeroNet network and others

Yes Yes Yes. KLYNTAR will keep in touch with them. Here we have indicated only the most used and popular. Using such bridges, you will be able to run KLYNTAR nodes in TOR (as a hidden service) or I2P and at the same time interact with them as if they were in a normal network.

You can also use this gateway as a SOCKS proxy for Apollo to interact with KLYNTAR through the mentioned TOR

For cache managers

Delete, add, rotate. Get creative, create efficient managers for faster performance

Directory level hierarchy

Everything is pretty simple here. Plugins are located in the directory

<YOUR_KLYNTAR_DIRECTORY>/KLY_Plugins

KlyntarCore
│     
└───KLY_Plugins
│  │
│  │───Bot
│  │───Logger
│  │───CacheManager
   └───...

Since you can run several daemons at the same time, it is convenient to have and update similar plugins in one place.

{% hint style="info" %} When starting, do not forget to make sure that the plugins do not conflict for a port, some directory, and so on. {% endhint %}

Plugins from developers

All plugins from the KlyntarTeam developers will have the dev_ prefix. Thus, it will be easy to find them when parsing directories or using grep for example. Plugins from KlyntarTeam do not mean that they are somehow better or cooler than from third-party developers - we appreciate the work and contribution of everyone. However, it is worth emphasizing that such plugins have an advantage, because members of the KlyntarTeam clearly have a deeper understanding of the principles of KLYNTAR, core features, and so on. It is to be expected that such plugins will have better support, fewer bugs and be better studied by the community, which is good from a security point of view.

For example, we have already added the dev_nets_gateway, dev_websocket, dev_proxy and others plugins. All of them are currently in development.

Also, in addition to installing third-party plugins, some plugins will be built into the core repository itself that will be the most popular among the community.

For developers + where to find plugins

For convenience, we have created a separate repository for plugins where developers can upload code, and those who want to improve their infrastructure can install whatever they like

{% embed url="https://github.com/KLYN74R/Plugins" %}

{% hint style="info" %} We will soon publish instructions on how and what to upload to this repository {% endhint %}

Conclusion

Plugins can also have compatibility levels - be universal or for a specific workflow. Soon we will tell you how to improve compatibility. Until then, keep creating!