About
Zentalk is an end-to-end encrypted messenger on a decentralized mesh network. No central server, no phone number required, fully open source.
Speak Freely. Trust Math, Not Servers.
Zentalk is a next-generation messaging platform where no server can read your messages — because mathematically, they can't. Every message, call, file, and piece of metadata is encrypted on your device before it ever touches the network. Nodes store and relay data they are cryptographically unable to decrypt. Your keys never leave your device.
Zentalk is available now at zentalk.chat. No phone number required — sign in with a Web3 wallet.
Two Modes of Communication
Zentalk operates in two distinct modes. Both use end-to-end encryption — the difference is how messages travel between users.
Online Mode — Validator Network
For global communication over the internet. Messages are routed through a decentralized network of independent validator nodes — internet-connected Go servers that relay encrypted data they cannot read. This is the primary mode when using Zentalk Web at zentalk.chat.
Range: Global (via internet)
Infrastructure: Validator nodes (Go servers operated by independent participants)
Routing: 3-hop onion routing (RSA-4096 per layer)
Encryption: Signal Protocol (X3DH + Double Ratchet)
Requirements: Internet connection
Offline Mode — Zentanode Hardware Mesh
For local communication without internet. Messages are routed through Zentanode devices — physical hardware that creates a local radio mesh network using LoRa, Bluetooth, and WiFi. No internet required.
Range: Up to 6 km per Zentanode (extendable through multi-hop)
Infrastructure: Zentanode hardware devices (ARM-based, 5W power)
Routing: Local mesh relay (node-to-node, LoRa/BLE/WiFi)
Encryption: AES-256 end-to-end
Requirements: Zentanode device within range, no internet needed
These are two separate networks. Online mode uses internet-connected validator servers. Offline mode uses local Zentanode hardware. Both encrypt all data end-to-end — neither validators nor Zentanode devices can read your messages.
Why Zentalk
Traditional messengers rely on central servers controlled by a single company. Your messages pass through their infrastructure, your metadata is logged, and your privacy depends on their promise not to look.
Zentalk's Answer:
No Central Server — Messages are routed through independent validator nodes or local Zentanode hardware
Server-Blind Encryption — Nodes store and relay encrypted data they cannot decrypt
No Phone Number Required — Sign in with a Web3 wallet or phone — your choice
No Single Point of Failure — The network runs across hundreds of independent nodes
Works Offline — Communicate within 6 km of a Zentanode without internet
Open Source — Every line of code is auditable. Trust is verified, not assumed
Online Architecture
Zentalk's online mode runs on three components. All encryption happens on your device — the network only sees encrypted data.
1. Your Device (Client)
A Progressive Web App (PWA) built with Next.js. The Signal Protocol (X3DH + Double Ratchet) runs entirely in your browser. Keys are generated and stored on your device. The server never sees plaintext.
2. API Server (Metadata Broker)
A Go-based "Blind Metadata Broker" that orchestrates the network but cannot decrypt anything. It handles authentication, WebSocket connections, and profile management — all with encrypted blobs only.
3. Validator Node Network
Full Nodes operated by independent validators, written in Go (579 source files across 41 packages). Each node is a single binary running three modules:
Relay Module
9001
Routes encrypted messages, queues offline messages (30-day TTL)
Mesh Storage
8080
Stores encrypted chunks with Reed-Solomon erasure coding
DHT Node
9101
Kademlia peer discovery, GossipSub pub/sub, NAT traversal
End-to-End Encryption
Zentalk implements a production-grade Signal Protocol with modern security extensions.
Cryptographic Algorithms
Key Exchange
X25519 (Curve25519)
256-bit
Digital Signatures
Ed25519
256-bit
Symmetric Encryption
AES-256-GCM
256-bit + 128-bit auth tag
Key Derivation
HKDF-SHA256
Per RFC 5869
HMAC
HMAC-SHA256
256-bit
IV/Nonce
Cryptographically random
96-bit per message
What the Server Can Never See
Message content
Yes
Never
Media files
Yes
Never
Read receipts
Yes
Never
Typing indicators
Yes
Never
User profiles
Yes
Never
Contact lists
Yes
Never
Call signaling (SDP/ICE)
Yes
Never
Group membership
Yes
Never
Presence status
Yes
Never
Forward Secrecy & Recovery
Per-Message Forward Secrecy — Each message uses a unique key derived from the Double Ratchet. Keys are deleted after use. Compromising one message cannot reveal others.
Post-Compromise Recovery — The DH ratchet introduces fresh randomness with each exchange. Even if a session is compromised, security automatically recovers after one message round-trip.
Key Management
Identity Keys — Ed25519 + X25519 key pairs generated on device, never transmitted
Signed Prekeys — Rotated every 7 days or after 100 messages
One-Time Prekeys — Pool of 10 disposable keys, each used once, auto-replenished
Recovery — BIP-39 compatible 12/24-word mnemonic or wallet signature recovery
Automatic Backup — Keys backed up to mesh, encrypted with AES-256-GCM (PBKDF2, 600K iterations)
3-Hop Onion Routing
Every message passes through three independent relays, each peeling one encryption layer:
Guard
First hop (rotates every 60 days)
Sender IP
Recipient, content
Middle
Second hop (random)
Previous & next hop
Sender, recipient, content
Exit
Third hop (random)
Recipient address
Sender IP, content
Each layer uses RSA-4096 per-hop encryption wrapped around the E2EE payload. No single relay knows both sender and recipient.
Zero-Knowledge Proofs
Zentalk uses Rate-Limiting Nullifiers (RLN) with Groth16 proofs on BN254 elliptic curve:
Users prove network membership without revealing identity
Spammers mathematically lose anonymity if they violate rate limits (256 messages per epoch)
Proof generation: 90–150ms | Proof verification: 1.7–5ms per message
Supports up to 1M users (tree depth 20)
Post-Quantum Cryptography
Zentalk implements hybrid post-quantum key exchange to protect against future quantum computers:
Kyber-768
ML-KEM (FIPS 203)
~192-bit post-quantum
Dilithium-3
ML-DSA (FIPS 204)
~192-bit post-quantum
Defense-in-depth: Both classical (X25519/Ed25519) AND post-quantum algorithms must be broken to compromise a session. This protects against "harvest now, decrypt later" attacks.
Data Redundancy
Zentalk uses Reed-Solomon erasure coding to ensure data survives node failures:
10 data shards + 5 parity shards = 15 total
Can lose up to 5 shards and fully recover all data
Anti-entropy service checks every hour and auto-repairs degraded chunks
Excellent
15/15
None needed
Good
13–14/15
Monitor
Degraded
11–12/15
Auto-repair triggered
Critical
10/15
Urgent repair
Comparison
E2EE (Default)
Yes
Yes
No
Yes
Decentralized
Yes
No
No
No
No Phone Number
Yes
No
No
No
Web3 Wallet Login
Yes
No
No
No
Open Source (Client)
Yes
Yes
Yes
No
Open Source (Server)
Yes
Yes
No
No
Post-Quantum (Hybrid)
Yes
Yes
No
No
Zero-Knowledge Proofs
Yes
No
No
No
Server-Blind Metadata
Yes
Partial
No
No
3-Hop Onion Routing
Yes
No
No
No
Erasure-Coded Storage
Yes
No
No
No
Validator Network
Yes
No
No
No
Platforms
Web Application (PWA)
Available
macOS App
Coming Soon
iOS App
Coming Soon
Android App
Coming Soon
The web application is a full Progressive Web App — installable on any device, works offline with cached assets and queued messages.
Compliance
GDPR
Data portability, right to erasure, DPO
HIPAA
PHI protection, breach notification procedures
SOC 3
Trust Services Criteria compliance
Links
Web App: zentalk.chat
Validator Explorer: explore.zentalk.chat
Zentanode Store: zentanode.com
Last updated
Was this helpful?