# 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! ❤️**

Themes: 
- <a href="#support"> support us </a>
- <a href="#policy"> policy in writing software </a>

# 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.

<h1 id="policy"> Our policy </h1>

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.**

<h1 id="support"> Support us </h1>

**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.**