# mesk 
**Mesk is a source-based package manager based on i2p protocols, tailored for independence and the absence of spyware.**

> [!wARNING]
> **It's hard to find a really working and at least**
> **somehow documented i2p client library for absolutely any language.**
> **But still, it was found in [emissary-core](https://github.com/altonen/emissary).** 
> **Big thanks from us all us! ❤️**


# Package Structure
`.mesk` - **is a compressed gzip tarball containing information on how to build, configure and install it**.

```
# Example file-tree of package.mesk 
.
├── BUILD   
├── INSTALL   
├── LICENSE
├── Makefile
├── SETTS
└── src
    ├── some_code.c
    └── some_code.rs

```

- **BUILD:** Not required if the package does not require compilation/other assembly
- **INSTALL:** Where or how to install the package? For example, you can just leave make install and the package will be installed by make, not mesk.
- **SETTS:** What needs to be configured after installation? For example, install basic configurations (if this is not done in `INSTALL`) or export environment variables.


**Binary packages are also supported, but the default installation is source-based.**
You can set the package compilation parameters in the global /etc/mesk.toml. (Read more in the documentation.) For example, the compiler, optimization level settings, etc. Here we are similar to portage.

The `.mesk` package can be generated automatically, given that the software is open source and based on standard build systems: `make`, `CMake`, `meson`, `cargo`. If the package does not require compilation, you must specify how and where to install it.

We only support open source software.  Binary builds of proprietary applications will not appear in the official repositories, but, for example, there will be open clients for messengers with a closed backend.

# Our policy 
1. Documentation is a sore point for i2p client implementations (even for the official i2p-rs, for example), after tinkering with a ton of non-working and undocumented libraries for i2p, our conscience will not allow us not to work on documentation.

_By the way, I will mention that the official examples of i2p-rs have a completely different structure of imports and library operation than crates.io versions. Over time, we plan to switch to our own implementations of client libraries for i2p._

2. The style of the code. So far, we have not reached a functioning prototype, the code works on a procedural programming paradigm, but eventually we will switch to a functional one. The code may hurt the eye, but it must contain documentation comments and its logic must be clear.

3. Minimalism and reliability. Our programs will not contain unnecessary functions that may lead to misunderstandings of the program interface (the CLI is also an interface), as well as functions that benefit but are controversial in their reliability.

A free network should be available to everyone.

# Support us
This project cannot be implemented without some support. The most valuable thing you can do for us is to create a Pull Request or spread information about us in any circle. We are a team of enthusiasts who do not have all the means to do this initially. All big projects absolutely always start small.