Zentalk is a global telecom network that no company owns. Its infrastructure — relay and storage nodes — is run by independent operators around the world, and anyone can join it: as a user, as a developer, or by running a node.
What travels through it is private by construction. A message is encrypted on the sender’s device, routed through relays that cannot read it, and — when the recipient is offline — stored as erasure-coded encrypted chunks spread across the mesh. Readable content exists in exactly two places: the device that sent it and the device that receives it. No node, no server, and no operator can read what passes through the network.
Identity follows the same principle. A Zentalk account is a cryptographic key pair, not an entry in a company’s user database: you prove who you are by signing with your key, and everything tied to you — contacts, conversations, backups — is encrypted with keys that only your devices hold. The architecture places no intermediary in a position to read or disclose your communication.
These docs are for developers building against the Zentalk API, integrating a client, or running a node on the network.
End-to-end encryption
All communication is encrypted on the sending device and decrypted on the receiving device, using the protocol family Signal established — X3DH key agreement and the Double Ratchet — extended with a hybrid post-quantum layer (X25519 + Kyber-768) that is enabled by default. The protocol has no plaintext mode. The full stack is documented in the Security overview.
Key-based identity
An account is a cryptographic key pair, addressed by its Ethereum address. Authentication is a signature, so the platform never needs to collect a phone number, email address, or any other personal data. Registration by phone number exists as an alternative: the number is used once to deliver a verification SMS and is never stored — the account is bound to a one-way hash computed on the device. Both flows are described in Authentication.
Server-blind storage
In the standard production configuration, the backend handles message content only as encrypted blobs. A compromised server — or a legal order against its operator — can produce ciphertext, not conversations. Metadata (identifiers, timestamps, contact relationships) is addressed by a separate protection layer, described in the Security overview.
Distributed trust
Transport and storage are spread across relay and mesh nodes operated by independent parties, so no single machine or operator is in a position to observe the network as a whole. Relays route traffic they cannot read; sealed sender, onion-encrypted routing, and fixed-size padding limit what any single node can learn about who communicates with whom.
Open participation
Operating a relay node requires no approval; the infrastructure grows by independent operators adding capacity. User registration is currently in a closed beta; operator staking is planned. See Run a validator.
| Component | Role | Language / stack | Default endpoint |
|---|---|---|---|
zentalk-api |
REST API + WebSocket gateway; authentication, sessions, message fan-out | Go | http://localhost:3001 (local), https://api.zentalk.chat (production) |
zentalk-node |
P2P infrastructure: relay server, DHT bootstrap node, mesh storage with erasure coding | Go (libp2p) | Relay :9001, DHT bootstrap :9000, mesh storage :9100 (HTTP API :8080 in Docker) |
zentalk-validator |
Operator distribution of the relay binary — install script, prebuilt binaries per platform, staking/rewards documentation | Prebuilt Go binaries | Operator-run |
zentalk |
Web application (Next.js 16 + React 19) — the reference client | TypeScript | http://localhost:3000 |
Validator nodes are relays run by third-party operators; they route encrypted traffic but cannot read message contents. See Running a validator.
| Requirement | Details |
|---|---|
| Identity | An Ethereum wallet (for example MetaMask) to sign login messages, or a phone number for the SMS registration flow |
| HTTP client | Any client that can send JSON and set an Authorization: Bearer header |
| WebSocket client | Optional, for real-time events — see WebSocket |
| Base URL | http://localhost:3001 for local development, https://api.zentalk.chat for production — see Environments |
Authentication yields a JWT access token (15-minute lifetime) plus a refresh token (7 days). The full model, including phone auth, sessions, and MFA, is covered in Authentication.
