Glossary
Definitions of terms used across the Zentalk platform and this documentation. Cryptographic terms link to the corresponding security documentation.
Access token — Short-lived JWT presented as a Bearer credential on REST and WebSocket requests. Obtained and refreshed as described in Authentication.
CHAIN — The ZentaChain network token. Validator staking is planned but not live: the staking contract is not deployed (target Q3 2026), with a target design of a 5,000 CHAIN minimum stake.
Chunk — The unit of encrypted content stored on the mesh. Media and message payloads are encrypted client-side, split into chunks, and referenced by the server only through opaque chunk IDs.
DHT (Distributed Hash Table) — Kademlia-based peer-discovery layer, built on libp2p, that Zentalk nodes use to find peers for mesh storage (storing and retrieving encrypted shards). It is not used for call signaling.
Double Ratchet — The Signal-protocol algorithm that derives a fresh message key for every message, providing forward secrecy and post-compromise security for one-to-one chats. See Double Ratchet.
Epoch key — The symmetric group key in effect for one key epoch, distributed to members by the group owner. On rotation, the next epoch key is derived as HKDF(previousEpochKey || freshRandom), so past epochs cannot be recomputed from the owner’s long-term identity alone. See Group and channel encryption.
Erasure coding — Reed–Solomon encoding (10 data + 5 parity shards) applied to mesh-stored content so it can be reconstructed even when some storage nodes are unavailable.
Federation — Exchange of traffic between independently operated Zentalk servers, authenticated with a challenge/verify handshake and delivered through signed inbox/outbox message exchange. See Federation overview.
Hybrid key exchange (PQC) — Combination of X25519 with ML-KEM-768 (Kyber), so session secrets remain safe even if one of the two schemes is broken. See Post-quantum cryptography.
Identity key — A user’s long-term public key, bound to their wallet address. It anchors X3DH session setup and is the value published to the Key Transparency Log.
Key Transparency Log (KTL) — The public, append-only Merkle log binding each wallet address to its identity public keys; each leaf hashes seq || wallet || 0x00 || public_key || key_version || prev_leaf_hash, and the log publishes a signed root against which clients verify inclusion proofs. See Key transparency log.
libp2p — The peer-to-peer networking stack used by the Zentalk node binaries for DHT peer discovery and mesh communication.
Mesh — The decentralized storage network formed by operator-run nodes. Encrypted chunks are distributed across the mesh; the API server holds only metadata and chunk pointers.
Mesh-first — The client-side storage strategy, used by the TypeScript client, that prefers mesh storage and falls back to the central API only when explicitly allowed.
Mesh-only mode — The server storage mode (the default in production) in which all content lives on the mesh with no server fallback; the server sees chunk IDs, recipient hashes, and timestamps — never message content, media, or avatars. The other server modes are hybrid (mesh primary, server fallback) and disabled.
Node binaries — The three operator-run binaries that make up a Zentalk node deployment: relay (message routing, offline queue), mesh-api (chunk storage), and dht-bootstrap (peer discovery). See Node binaries and ports.
One-time prekey — A single-use public key uploaded in batches and claimed by a peer during X3DH session setup; using each key once strengthens forward secrecy for the initial message.
Prekey bundle — The set of public keys (identity key, signed prekey, and optionally a one-time prekey) a client fetches from the server to start an X3DH session with a peer who is offline. See X3DH key agreement.
Relay — The node binary that routes end-to-end-encrypted messages between peers and queues them for offline recipients; relays forward ciphertext only. Direct messages traverse a single onion-encrypted hop (the relay cannot see the final recipient), while group fan-out uses multi-hop routing over 3–5 hops.
Safety number — The human-comparable fingerprint of the keys in a conversation, shown in the client’s Safety Number dialog. Two users compare safety numbers to verify their session end-to-end. See Contact verification.
SAS (Short Authentication String) — The in-app short-string comparison flow used to verify a peer’s keys out of band. SAS verification is the primary defense against split-view (equivocation) attacks. See Contact verification.
Sealed sender — An envelope format that hides the sender’s identity from the relay: only the recipient ID is visible on the wire, while the sender’s identity travels encrypted inside the envelope and is revealed only to the recipient. See Sealed sender.
Sender certificate — The server-signed record (sender_addr, device_id, cert_expiry, issuer, Ed25519 server_sig) sealed inside a sealed-sender envelope. The recipient validates the expiry and signature before trusting the claimed sender address.
Signed root — A signed commitment to the Key Transparency Log’s current Merkle root and tree size. Two valid signed roots with conflicting root hashes at the same tree size are public proof that the log operator equivocated.
TOFU (Trust On First Use) — The fallback trust model used when the Key Transparency Log is disabled or unavailable: the client pins the first identity key it sees for a peer and warns if that key later changes.
Validator — An operator-run relay node distributed via the zentalk-validator installer. Staking (planned) will bond CHAIN to the operator. See Run a validator.
Wallet address — The Ethereum-style 0x-prefixed address (42 hex characters) that serves as a user’s account identifier. Authentication binds sessions to a wallet signature; see Authentication.
WebSocket — The persistent realtime connection used for message delivery, presence, typing indicators, and call signaling, subject to its own rate limits. See WebSocket connection.
X3DH (Extended Triple Diffie–Hellman) — The Signal-protocol key-agreement handshake that establishes a shared secret with a peer — even an offline one — using their prekey bundle; the resulting secret seeds the Double Ratchet. See X3DH key agreement.