Habr•August 10, 2026•🇷🇺Translated from Russian

Why Distributed Mesh Architectures Resist IP Blocking Better Than Centralized Servers

One of the most frequent questions asked about distributed censorship-circumvention systems is why the architecture must be made so complex when a simple dedicated server could deliver access. The answer lies in the fundamental weakness of any finite set of static IP addresses when confronted with modern blocking techniques.

Single-server and small-server deployments are easy to develop and maintain, yet they share one critical vulnerability: once an address enters a blocklist, service through that address stops. Discovery does not require deep packet inspection of every packet; it is enough to recognize characteristic traffic patterns and record the destination. When the number of addresses is limited, they can be identified and blocked sequentially.

Maintaining many servers does not solve the problem by itself. If a significant portion of the infrastructure belongs to the same provider or ASN, a single block can affect numerous nodes simultaneously. Moreover, any fixed list of addresses can be gradually updated by the blocking party as long as the list changes slowly.

The decisive difference in the distributed model is that user devices themselves become transport nodes. Clients form a mesh and can relay traffic for one another in a P2P manner similar to the original Skype architecture. Consequently, data transfer no longer depends on every user connecting to one of a small number of dedicated servers. The resulting network lacks a stable, enumerable list of addresses; its composition changes with the set of active participants.

Individual client nodes can still be discovered and blocked, yet the detected set constantly becomes outdated. Address blocking therefore turns from the relatively simple task of maintaining a server list into the continuous task of discovering a dynamic participant set.

A separate backbone network continues to exist, but its role is limited to trust, coordination, and providing exit points. It helps clients determine which configurations and nodes to trust and is not intended to replace the client mesh for transport.

Mesh operation does not eliminate the need for anti-DPI measures. Techniques such as uTLS ClientHello rotation and decoy traffic remain essential to prevent individual connections from being easily classified. The two layers address different problems: anti-DPI mechanisms make single connections harder to fingerprint, while the distributed architecture prevents blocking from being reduced to maintenance of a small, stable server list.

The approach carries tangible costs. When a device relays transit traffic it consumes its own bandwidth and battery, an especially noticeable burden on mobile clients. Operational safeguards are also required to prevent abuse of the relay mechanism and to account for devices that cannot sustain server-level loads. The result is a deliberate engineering trade-off: added system complexity is accepted in exchange for turning a static blocking task into a continuously evolving discovery problem.

Related articles

Habr•Privacy & Surveillance

ONYX 2.0 Removes Central Servers for Fully Decentralized Tor-Based Messaging and Calls

ONYX 2.0-beta marks a major shift from its previously centralized design to a serverless architecture that relies entirely on Tor for all communications. Each user account is now represented solely by a cryptographic key pair generated on first launch, with recovery handled through a 12-word seed phrase. Devices connect directly via onion services, and the application bundles its own Tor daemon on desktop platforms while using tor-android on mobile devices. Voice calls are supported through an embedded local TURN server, delivering acceptable quality with 1-3 second latency despite the anonymity overhead. Message delivery now depends on recipient availability, with undelivered messages stored locally on the sender and retried automatically. The update deliberately removes features such as HTTP or SOCKS5 proxies and link previews to prevent IP leaks or external traffic. Developers released the beta to gather feedback on stability across network changes and multi-device scenarios.

Habr•Privacy & Surveillance

Privacy-Focused Browser Tool Compresses PDFs Locally Without Uploading Sensitive Documents

A developer created a PDF compression tool that runs entirely inside the browser to protect sensitive personal and professional documents from third-party servers. The solution addresses repeated situations where embassy submissions, financial presentations, contracts, and internal reports exceeded size limits, forcing users to choose between installing desktop software or risking data exposure through online services. The tool reduces scanned and photographic PDFs by 66 to 97 percent depending on quality settings while honestly reporting weaker performance on text-heavy files compared with Ghostscript. It works on both desktop and mobile platforms, including iPhone and Android, requires no installation, and continues functioning offline after the first page load. On mobile devices the application respects memory constraints by limiting images to four megapixels, preserving readability for A4 documents intended for printing. The project originated from a single evening script built around Ghostscript and evolved into a full web application after similar compression needs recurred across multiple devices and locations.

Habr•Privacy & Surveillance

Building Prizrak: How a Developer Created a Federated Messenger That Masks All Traffic as Legitimate HTTPS

A developer created Prizrak, a federated messenger with end-to-end encryption where all traffic, including calls, is indistinguishable from ordinary HTTPS connections. The project addresses three common limitations of existing messengers: centralized control points, mandatory phone numbers, and detectable encrypted traffic. It uses real TLS 1.3 handshakes to actual domains, multi-port listening, and a hidden token mechanism inside the encrypted channel. When servers cannot reach each other directly, messages are delivered through a network of storage nodes modeled after Ceph's RADOS system. Voice and video calls run on a native media stack with custom STUN-like functionality and careful UDP buffer sizing to avoid packet truncation. An integrated two-hop VPN reuses the same stealth transport while keeping messenger traffic outside the tunnel.

Habr•Privacy & Surveillance

GrapheneOS Setup Guide: Configuring Pixel Phones for Corporate Surveillance-Free Daily Use

This comprehensive engineering guide explains how to deploy GrapheneOS on supported Google Pixel devices to eliminate corporate telemetry collection. It follows three core principles: rejecting proprietary ecosystems, applying Zero Trust through cryptography and open-source audits, and enforcing strict compartmentalization via isolated user profiles. The tutorial covers official installation via the Web Installer, basic owner profile hardening with PIN shuffling and automatic reboot, and the use of Obtainium for direct FOSS app management from GitHub repositories. Detailed recommendations include privacy-focused tools such as KeePassDX, Aegis Authenticator, AmneziaVPN, Signal, and Fossify applications, along with VPN kill-switch configuration. Regional profiles are created for sandboxed Google Play, Aurora Store, RuStore, and Huawei AppGallery to safely run banking, marketplace, and social apps without cross-profile tracking.