# About

## 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.

{% hint style="info" %}
Zentalk is available now at [zentalk.chat](https://www.zentalk.chat/). No phone number required — sign in with a Web3 wallet.
{% endhint %}

***

## 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](https://www.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

{% hint style="warning" %}
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.
{% endhint %}

***

## 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:

| Module       | Port | Function                                                        |
| ------------ | ---- | --------------------------------------------------------------- |
| 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

| Component            | Algorithm                | Key Size                   |
| -------------------- | ------------------------ | -------------------------- |
| 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

| Data                     | Encrypted | Server Visible |
| ------------------------ | --------- | -------------- |
| 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:

| Relay  | Role                              | Knows               | Does Not Know              |
| ------ | --------------------------------- | ------------------- | -------------------------- |
| 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:

| Algorithm   | Standard          | Security Level         |
| ----------- | ----------------- | ---------------------- |
| 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

| Status    | Shards Available | Action                |
| --------- | :--------------: | --------------------- |
| Excellent |       15/15      | None needed           |
| Good      |     13–14/15     | Monitor               |
| Degraded  |     11–12/15     | Auto-repair triggered |
| Critical  |       10/15      | Urgent repair         |

***

## Comparison

| Feature               | Zentalk | Signal  | Telegram | WhatsApp |
| --------------------- | ------- | ------- | -------- | -------- |
| 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

| Platform              | Status      |
| --------------------- | ----------- |
| 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

| Standard | Coverage                                       |
| -------- | ---------------------------------------------- |
| GDPR     | Data portability, right to erasure, DPO        |
| HIPAA    | PHI protection, breach notification procedures |
| SOC 3    | Trust Services Criteria compliance             |

***

## Links

* **Web App:** [zentalk.chat](https://www.zentalk.chat/)
* **Validator Explorer:** [explore.zentalk.chat](https://explore.zentalk.chat/)
* **Zentanode Store:** [zentanode.com](https://zentanode.com)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.zentachain.io/zentalk/introduction-1.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.