Project Anthrill Mechanics.

What problem are we solving?

Centralized chokepoints vs. decentralized resilience.

Take something like DNS, for example — despite the decentralization built into caching DNS protocols, 16.4% of all domains are served by Cloudflare's authoritative DNS. Seriously, imagine that cluster going down, and in an instant, 16% of domains across the entire internet simply stop resolving.

Sure, that sounds esoteric. And sure, Cloudflare would throw all their resources into getting everything back up as fast as humanly possible. On top of that, Cloudflare runs a massive catalog of completely different, yet no less infrastructure-critical and ubiquitous services — including CDNs, DDoS protection, and much more. But alas, these kinds of outages (or similar incidents) happen regularly anyway.

In decentralized networks, this simply cannot happen. Anthrill's developers are, first and foremost, advocates of decentralization for privacy reasons — we already detailed what's wrong with today's internet in our manifesto. But bridging decentralized networks into the conventional network also brings other benefits that we don't really see a point in spelling out explicitly right now: anyone who has ever used anything like this before already knows why they need something like Anthrill Linux.

Anthrill Linux Architecture

Native overlay integration without sacrificing convenience.

The core essence of the project is to bring convenience, decentralization, and genuine independence into the everyday user experience of a standard Linux user, while making "anonymity" or "privacy" dramatically easier to attain (via the NSC clearnet killswitch). Below, I will describe how this is actually implemented.

Anthrill declares native support for the following networks:

How do you implement their native integration into everyday user workflows without sacrificing convenience along the way?

The answer: NSC. NSC is the central router inside your system that "sorts out" your requests (routing decisions are evaluated based on a combination of TLD from the HTTP host and TLS SNI) and dispatches them to the appropriate proxy for each overlay network.

NSC

Transparent overlay routing, policy enforcement, and killswitch.

In practical terms: with NSC, you can simply open http://reg.i2p in your browser, browse startpage.com concurrently in another tab, and immediately open a third tab with a page from, say, Yggdrasil. Meanwhile, NSC silently picks the right proxy for the destination network on your behalf.

NSC is also treated as a privacy engine: you can fine-tune traffic routing or leverage features like the network killswitch. The daemon follows an Xray-like routing logic and is compatible with its geo protobufs. You can construct rule chains like:

[[rule]]
action = "block"  # or "proxy" / "direct"
target = "geosite:category-ads-all"

[[rule]]
action = "block" 
target = "geosite:win-spy"

[[rule]]
action = "proxy"
proxy_name = "xray" 
target = "clearnet"


[[proxy]]
alias = "xray" 
url = "socks5://localhost:10808" # xray-core mixed port

[[proxy]]
alias = "i2p_outproxy" # i2p support built-in, but you can redefine it for rules
url = "http://localhost:4444" 


[policy]
clearnet = "killswitched"
killswitch_mode = "allow-proxy" # allow-proxy OR full

Here:

• Advertisements are blocked
• Microsoft telemetry and tracking are blocked
• All clearnet traffic is routed through a proxy
• A killswitch is enabled for clearnet, allowing network access only through the proxy (Crucially, the killswitch applies strictly to clearnet. Overlay networks operate as distinct transports and continue working directly with their local routers.)

We worked hard to keep the configuration as simple and clear as possible, even for someone seeing it for the very first time. NSC, coupled with an isolated IP stack, are the system's key components.

Mesk

Package management over unstable, multi-overlay environments.

Mesk is our package manager, designed to provide the fastest and most reliable package delivery possible over unstable connections. Working hand-in-hand with NSC, it can dynamically switch mirrors across different networks, and features its own package delivery protocol built on top of HTTP — MPTP.

The core mechanism of MPTP is concurrency — both across multiple packages and within an individual package. Mesk downloads a single package in multiple streams using small ranges whose sizes are determined dynamically based on EWMA and several auxiliary factors. At the same time, it concurrently pulls the package from another mirror in an adjacent overlay network in the exact same manner! You can configure limits for maximum download speed, maximum threads per package, or overall concurrency across multiple packages.

There isn't an awful lot more that needs to be said about it — it is interesting from an engineering standpoint rather than for the average user, since its CLI is hardly different from something like apt. We don't believe in overcomplicating simple, intuitive interfaces for base utilities. (Yeah, pacman, we see you). But leaving it unmentioned was simply not an option.

Vigil

A fast, simple, and rock-solid init system.

The distribution's init system, built with the goal of being as simple, fast, and stable as possible. Initially, we wanted to adopt an existing one, but systemd constantly forced us to wait several minutes while its next target reported readiness; its developers eventually acknowledged issues with disks being overwhelmed by binary logs years later; and runit just wasn't particularly convenient.

Because of this, we decided to bring together the best of all worlds:

• Fallback solutions for everything
• Clean logging in the style of OpenRC
• A service management interface similar to systemd
• Minimal bloat and zero excess

And with that, the core technical details are covered.