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.

HabrOctober 10, 2026Translated from Russian

Read at source

ONYX 2.0 has transitioned from a centralized model to a fully decentralized architecture that eliminates servers entirely. The update introduces a client-only design built around Tor, enabling direct peer-to-peer messaging and voice calls while preserving end-to-end encryption.

Account Model and Identity

Upon first launch, the application generates a cryptographic key pair that serves as the user account. Recovery on new devices is possible through a 12-word seed phrase. Each identity carries an Account ID and fingerprint that contacts can verify to confirm they are communicating with the intended party. Profile data remains local and syncs between a user’s own devices via WardLink.

Tor Integration and Network Design

The desktop versions bundle a Tor daemon, while Android uses tor-android. Every device receives its own onion address, and all traffic—including external groups and channels—routes exclusively through Tor. No fallback direct connections exist, preventing accidental IP exposure. A “View Circuit” screen displays the active Tor path for any conversation.

Contacts and Message Delivery

Contacts are added via QR code or onion address. Incoming requests may include a comment and can be accepted, rejected, or rejected with blocking. Until acceptance, the requester cannot view status or initiate calls. Without a central mailbox, undelivered messages stay on the sender’s device and retry automatically according to a configurable interval, with delivery status shown beneath each message.

Voice Calls

The standout feature is native voice calling that operates solely over Tor. A built-in local TURN server handles media relay without external infrastructure. Call quality remains acceptable despite 1–3 second latency, and call history is retained in the chat interface.

Trade-offs and Removed Features

Developers removed HTTP/SOCKS5 proxy support, link previews, and any server-dependent functions such as remote account deletion. Latency has increased due to Tor routing, and instant delivery is no longer guaranteed when recipients are offline. The changes represent a deliberate move toward decentralization.

The beta release aims to identify issues with unstable circuits, network switching, and multi-device behavior. The source and binaries are available on GitHub.

ONYX WardLink tor-android

ShareX Facebook LinkedIn Reddit

Meridian digestThe week's most consequential security stories, distilled into one briefing.See the digest

More in Privacy & Surveillance

Privacy & Surveillance

Maximizing iPhone Privacy: Essential Settings to Enable, Disable, and Verify Immediately

The article provides a detailed guide on strengthening iPhone privacy by limiting unauthorized access to messages, location data, photos, and cloud backups. It explains how to set a strong alphanumeric passcode, enable Stolen Device Protection, and restrict lock screen notifications and widgets. Users are advised to review Apple ID security, enable Advanced Data Protection for iCloud, and minimize app permissions for location, contacts, and camera. Additional steps include turning off cross-app tracking, using private Wi-Fi addresses, and activating Lockdown Mode for high-risk scenarios. The guide emphasizes regular updates, encrypted local backups, and periodic audits of shared access and active sessions to maintain long-term protection.

SecuritylabOct 28, 2026Translated from Russian

Privacy & Surveillance

Top 10 Secure DNS Servers for Privacy, Threat Blocking and Ad Filtering in 2026

Public DNS resolvers differ significantly in their ability to block malicious domains, filter advertising and tracking, respect user privacy, and support modern encryption protocols. The guide evaluates ten services including Quad9, Cloudflare, AdGuard DNS, NextDNS, Control D, CleanBrowsing, Mullvad DNS, DNS4EU, Google Public DNS and DNS.SB, providing IPv4 addresses, DoH and DoT endpoints, and recommended use cases. Key distinctions include Quad9’s focus on phishing and malware blocking without logging, Mullvad’s strict no-logs policy requiring encrypted protocols only, and DNS4EU’s EU-based infrastructure with mandatory court-ordered blocks. The article explains why DNSSEC and encryption alone are insufficient and outlines four practical selection criteria: threat filtering quality, data-handling practices, encryption support, and network stability. Detailed configuration instructions cover Windows 11, Android, iOS, and home routers, along with verification methods and warnings against mixing providers with conflicting policies.

SecuritylabOct 28, 2026Translated from Russian

Privacy & Surveillance

WebRTC IP Leaks Explained: Why Disabling the Protocol Harms Anonymity in Anti-Detect Browsers

The article from Aurorium details how WebRTC technology can leak real IP addresses even when users route traffic through proxies. It explains the peer-to-peer mechanics of WebRTC, the role of STUN servers in generating ICE candidates, and why standard TCP proxies fail to handle UDP traffic. Disabling WebRTC via flags or JavaScript extensions creates detectable anomalies that anti-fraud systems flag as non-standard environments. The recommended approach involves native emulation inside the browser kernel so that STUN requests return proxy IPs while preserving full API integrity across workers. Additional leaks through local network addresses, mDNS candidates, and IPv6 are also covered with practical verification methods using tools like BrowserLeaks and CreepJS.

HabrOct 26, 2026Translated from Russian