Jami in Russia: P2P Messenger's Network Hurdles and Fixes
Decentralized messenger Jami hits major roadblocks in Russian networks due to CGNAT and blocks, making direct peer-to-peer connections unreliable. Despite its technical promise, the current ICE protocol setup and reliance on TURN servers can't handle today's network restrictions. This article breaks down the engineering issues and lays out concrete steps to overhaul the architecture for rock-solid performance.
P2P Connection Woes in Russian Networks
Jami's main instability stems from how Russian ISPs handle internet infrastructure. Carrier Grade NAT (CGNAT), common among mobile carriers, strips users of public IP addresses, blocking incoming connections. Symmetric NAT is especially tricky, where standard tricks like STUN and UDP hole punching often fail.
Key network roadblocks:
- No public IPs for mobile users.
- ICE protocol struggles behind CGNAT.
- TURN servers like turn.jami.net are inaccessible in Russia.
- DPI systems easily spot TURN traffic without DTLS/TLS support.
Flaws in the Current Architecture
Jami leans on centralized components, clashing with its decentralized ethos. DHT bootstrap nodes needed to join the network can get blocked, and TURN servers are single points of failure. TURN-routed traffic adds lag and is prime for blocks—critical under Russia's internet regs.
Comparison of relay approaches:
- Current TURN: Centralized server, easy to block, spikes latency.
- P2P Relay: User nodes with public IPs share the load, distributed.
- Mesh Networks: Dynamic routing via multiple nodes, ultimate resilience.
Technical Fixes to Modernize Jami
Beating these network limits calls for a full protocol and architecture upgrade. Top priority: ditch TURN dependency and boost direct connection setups.
Level 1: Boost P2P Connections
- Prioritize IPv6: Force IPv6 addresses in ICE candidates to sidestep NAT. Russian mobile networks already push IPv6, potentially enabling direct connects for up to 70% of users.
- Aggressive UPnP: Ramp up port mapping attempts and cut keepalive intervals to 15 seconds to keep NAT sessions alive.
- CGNAT-Optimized ICE: Add port inference to predict symmetric NAT behavior and forge direct links.
Level 2: Next-Gen Transport Protocols
Switch to QUIC over TCP/UDP for:
- Smoother NAT traversal with built-in keepalives and connection migration.
- Multiplexing without head-of-line blocking.
- DPI resistance via baked-in TLS 1.3 encryption.
- Seamless handoffs between Wi-Fi and mobile data.
Level 3: P2P Relaying via Relay Peers
Roll out a system where public-IP nodes relay for CGNAT users:
- New ICE candidate type: peer_relay.
- Publish relay availability in DHT.
- End-to-end encryption even through relays.
- Self-organizing network: more public-IP users, tougher the system.
Level 4: Supercharge DHT Usage
Integrate libtorrent for fully decentralized text and file transfers:
- DHT for data distribution, not just signaling.
- No centralized servers for non-media traffic.
- Beefed-up network resilience.
Level 5: Mesh Routing
Long-term: Build an overlay mesh with dynamic routing:
- Protocols like BATMAN or OLSR.
- Auto-optimal paths through multiple nodes.
- Network gets stronger with every new user.
Level 6: Purge TURN from the Codebase
Once prior levels are in, axe TURN entirely:
- Drop relay candidates from ICE.
- Remove TURN settings from the UI.
- Build PJSIP without TURN to shrink attack surface.
Optimization: Hole Punching with Coordinators
To cut relay traffic, use public-IP nodes just as coordinators for initial handshakes. Post-hole punch, the relay drops out, shifting to pure P2P. This blends relay reliability with direct efficiency.
Key Takeaways
- CGNAT in Russian mobile nets is the biggest P2P killer for Jami.
- TURN reliance breeds vulnerabilities and lag.
- IPv6 and QUIC can fix most NAT and block issues.
- P2P relaying via peers offers a decentralized TURN alternative.
- Fully purging TURN should be the project's endgame.
— Editorial Team
No comments yet.