Russia’s recent messaging crackdown is the cleanest real-world stress test of decentralization in years, and it produced an awkward result.
Roskomnadzor began throttling Telegram on Feb. 10, citing “non-compliance.” Two days later, authorities fully blocked WhatsApp, removing its domains from Russia’s national registry and forcing users toward VPNs or MAX, a state-backed messenger that critics describe as surveillance infrastructure disguised as a chat app.
The Kremlin had already mandated the preinstallation of MAX on all devices sold in Russia, effective Sept. 1, 2025.
The move seemed tailor-made to vindicate decentralized messaging. Here was textbook censorship playing out in real time, consisting of DNS manipulation, registry disruption, and platform coercion against services with more than 4 billion combined users.
Yet the “censorship-resistant” alternatives built over the past decade remained marginal. Users didn’t flood into Session, Status, or XMTP-based inboxes.
They patched the problem with VPNs and complained on Twitter.
The decentralization thesis didn’t fail because the technology doesn’t work. It failed because the technology addresses a problem most users don’t recognize, and introduces trade-offs they’re unwilling to accept.
Three-layer mismatch
What people call “decentralized messaging” actually bundles three distinct properties that rarely align in practice.
Content privacy means end-to-end encryption by default. WhatsApp uses the Signal Protocol for all messages and calls. Telegram does not, as E2EE applies only to Secret Chats, which are device-bound and don’t sync across platforms like the service’s default cloud chats.
Most Telegram users don’t toggle Secret Chats on, which makes the service’s “private” reputation misleading under pressure.
Network resilience refers to blockability. Centralized services present predictable choke points, such as DNS records, IP ranges, and CDN infrastructure.
Russia’s WhatsApp action exploited exactly that. Peer-to-peer systems reduce reliance on a single endpoint, but they trade off reliability, battery life, and the delivery guarantees that mainstream users expect.
Platform resilience is the layer almost no one discusses. Even apps marketed as decentralized depend on Apple and Google’s push notification systems (APNs and FCM) to deliver messages instantly in the background.
Those push rails create quiet centralization and metadata exposure, as Apple and Google can be legally compelled to share push notification metadata in some jurisdictions.
The coordination problem no protocol can solve
Network effects operate as a mathematical lock-in.
WhatsApp reports more than 3 billion monthly active users. Telegram claims over 1 billion. Switching costs are coordination costs: the value of a messaging app scales with the number of your contacts who use it, and the transition penalty grows exponentially with network size.
Phone numbers make this both worse and better at the same time.
Signal still requires phone-number registration even after introducing usernames. The decision isn’t an oversight, as Signal’s own documentation argues that phone numbers enable discoverability and help resist spam.
Decentralized systems that eliminate phone numbers must replace that entire scaffolding with something else. Most haven’t.
Crypto-native messaging protocols such as XMTP take a different approach, building identity around wallet addresses.
This creates composability across apps and reduces platform lock-in. Still, it also inherits problems that destroy mainstream usability: key custody risks, recovery failures, and identity confusion when users juggle multiple wallets.
Spam as the adoption ceiling and the mobile OS trap
Open networks become spam magnets unless constrained by identity systems, rate limits, or economic costs. XMTP’s documentation explicitly states that permissionless networks will attract spam and that content-level moderation cannot occur at the protocol layer if messages are encrypted.
The burden shifts to consent lists managed by individual clients and apps.
Every mechanism that might curb spam, such as identity proofs, token staking, and reputation scores, risks re-centralizing power or undermining anonymity.
If you require proof of personhood to send a message, you’ve created a new registry and a new attack surface. If you charge a fee, you’ve excluded low-income users and created opportunities for rent-seeking.
Mainstream users expect instant delivery. On iOS and Android, that expectation depends on background push notifications routed through APNs and FCM.
Even apps that position themselves as decentralized, such as Briar, Status, and Session, either compromise on “instant” delivery or accept the centralization imposed by push systems.
Push infrastructure also exposes metadata: who messaged whom, when, and from where. Authorities can compel Apple and Google to share that data in many jurisdictions.
For high-threat users, this is a fatal flaw. For everyone else, it’s invisible, until it isn’t.
| Option | Layer 1: E2EE by default? | Layer 2: Block / throttle resistance | Layer 2: Primary choke points | Layer 3: Push (APNs / FCM) for “instant”? | Layer 3: App-store dependence | Adoption: Identity model | Adoption: Recovery | Adoption: Spam / abuse posture | Adoption: Mainstream UX gaps |
|---|---|---|---|---|---|---|---|---|---|
| ✅ Yes | ❌ Low | DNS / IP / CDN; centralized servers | ✅ Yes | ✅ High | Phone number | ✅ Simple | ⚠️ Centralized enforcement | ✅ Minimal (baseline feature-complete) | |
| Telegram (Default cloud chats) | ❌ No | ❌ Low | DNS / IP / CDN; centralized servers | ✅ Yes | ✅ High | Phone number | ✅ Simple | ⚠️ Centralized enforcement | ✅ Minimal (feature-complete) |
| Telegram (Secret Chats) | ⚠️ Optional | ❌ Low | Same as above (service still centralized) | ✅ Yes | ✅ High | Phone number | ✅ Simple | ⚠️ Centralized enforcement | ❌ Multi-device sync (device-bound); UX friction |
| Signal | ✅ Yes | ❌ Low–Med | Centralized servers; domain/IP | ✅ Yes | ✅ High | Phone number (usernames help, still phone-based) | ⚠️ Moderate | ⚠️ Centralized + rate limits | ⚠️ Network effects / “second messenger” |
| Matrix (Element) | ⚠️ Optional / depends on setup | ⚠️ Medium | Home servers; federation links; public servers | ✅ Yes | ✅ High | Username (server-based) | ⚠️ Moderate | ⚠️ Server / community moderation | ⚠️ Admin/UX complexity; inconsistent defaults |
| Briar | ✅ Yes | ✅ Higher | Device availability; Tor bridges; local connectivity | ❌ No (not “instant” like mainstream) | ⚠️ Medium | QR/peer add; no phone number | ❌ Hard | ⚠️ Limited surface; smaller networks | ❌ Reliability / always-on; battery; onboarding |
| Session | ✅ Yes | ⚠️ Medium–Higher | Relay network / routing layer; endpoints | ⚠️ Partial | ✅ High | Session ID (no phone) | ❌ Hard | ⚠️ Client-side + network rules | ⚠️ Delivery reliability; UX learning curve |
| Status / Waku | ✅ Yes | ⚠️ Medium | Waku relays; bootnodes; app infra | ⚠️ Partial | ✅ High | Wallet / keypair | ❌ Hard | ⚠️ Client-side consent + filters | ⚠️ Beta maturity; spam/identity friction |
| XMTP-based inboxes | ✅ Yes (message-level) | ⚠️ Medium | XMTP network nodes / relays; endpoints | ⚠️ Partial | ✅ High | Wallet address | ❌ Hard | ⚠️ Client-side consent; spam assumed | ⚠️ “Who am I messaging?”; key mgmt; history sync pitfalls |
Performance tax and feature regression
Multi-device sync, large group chats, media attachments, message search, and cloud backups are features users barely notice until they break.
Pure peer-to-peer architectures make it difficult or impossible to implement these features without introducing a relay or storage layer.
Telegram illustrates the trade-off directly. The service’s default cloud chats sync seamlessly across devices, but they don’t use end-to-end encryption. Secret Chats use E2EE, but they’re locked to a single device and cannot be synchronized.
That’s the cost of maintaining the privacy guarantee, not a compromise.
Matrix, the federated protocol behind Element and other clients, offers self-hostable infrastructure and avoids single-operator control.
However, federation shifts complexity to administrators and still leaves blockable server targets.
Why the alternatives stay niche
Signal has the best privacy defaults in the industry, but it remains a second messenger for most users. The phone-number requirement reduces anonymity, and the smaller network means it’s where activists go, not where everyone is.
Briar was designed explicitly for crises, as it operates over Tor, Bluetooth, and Wi-Fi Direct to circumvent shutdowns. That design is why it’s niche. Onboarding is more challenging, battery drain is greater, and always-on delivery doesn’t match WhatsApp’s responsiveness.
Status positions itself as a web3 super-app with decentralized messaging at the core, powered by the Waku peer-to-peer protocol. The project’s own documentation flags it as beta and acknowledges the reliance on unproven infrastructure.
XMTP offers the strongest composability narrative, with wallet-based identity and protocol-level consent features that work across different apps.
However, the documentation reveals real friction: spam is treated as inevitable, local database encryption can disrupt history sync if mishandled, and the entire model assumes users are comfortable managing cryptographic keys.
The trilemma that won’t resolve, and what happens next
It is possible to optimize for two of the following, but rarely all three: high privacy (both metadata and content), high usability (instant delivery, multi-device sync, big groups, search), and high decentralization (no single operator, minimal choke points).
Mainstream apps prioritize usability and scale. Privacy tools pick privacy and decentralization.
Crypto-native projects seek to offset usability losses with token incentives and protocol design, but they incur new complexity related to spam, identity, and regulatory exposure.
Russia’s WhatsApp block increased the pain of censorship, but it didn’t cross the switching threshold. Users will switch when the pain of censorship exceeds their tolerance, and the alternative offers near-zero onboarding friction, instant delivery, low spam, and sufficient contacts already using it. VPNs are easier.
The forcing functions won’t be ideological. They’ll be institutional: mandatory preinstalls such as MAX, public-sector adoption mandates, app store removals, and stricter VPN enforcement.
Freedom House documented the 15th consecutive year of declining global internet freedom in 2025.
Shutdowns and throttling remain standard tools of state control. Demand for censorship-resistant communication is growing. The supply side still can’t deliver the product that users will actually adopt.
The stack that solves this will need push-notification independence without battery drain, spam resistance without identity registries, and key management that doesn’t punish common errors.
Until then, decentralized messaging remains a hedge, not a replacement. It’s the app people install when things get bad, not the one they use every day.