1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
|
# 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.
4. **We don't use AI in our code.** The entire project code is written by a human, with the exception of unit tests and other parts that will not be included in the final release.
**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.**
|
