What the relay can see. What it can't.
Kant is designed around relay-assisted privacy rather than full central-server custody. Below is the actual data processing model and threat model — stated plainly, including the parts that are still open.
- ✓Message content
- ✓Message history
- ✓Contact lists
- ✓User identity keys (beyond the relay's own long-term seed)
- ✓Private user payloads
- •Public registry metadata (signed circuit addresses)
- •Connection and reservation metadata
- •Health, readiness, and metrics data
- •TLS/certificate data at the termination layer
Modeled threats and their mitigations.
Scoped to the active product surface: relay bootstrap, registry publishing, client identity and session handling, and the TLS termination layer in front of the public relay.
Message interception
Mitigated by end-to-end encryption at the client — the relay only ever forwards ciphertext frames it cannot decrypt.
Relay impersonation
Registry entries are signed by the registering peer's identity key, so a spoofed relay can't publish addresses on someone else's behalf.
Replay attacks
Every /register and /lookup call carries a nonce; duplicates are rejected outright.
Reservation abuse / resource exhaustion
Registry entries expire on TTL and are pruned on disconnect, bounding how much state a flood of reservations can accumulate.
Seed compromise
The relay's identity is recoverable through an authenticated backup flow — a compromised host doesn't mean the relay's identity is unrecoverable.
Public exposure of admin services
Admin reservation endpoints require a configured bearer token and are not reachable at all without one.