Privex Architecture Atlas

Rebuilt from code, migrations, and PRIVEX_DOCS_V2

One deployable visual system for how Privex stores, moves, and refuses data.

The old output split large Mermaid graphs across separate pages and mixed implemented behavior with future design. This version keeps the diagrams stable, distinguishes current code from planned work, and maps each storage or transport layer to the privacy guarantee it provides.

Inspect storage View complete map

Corrections from the previous output

Facts that changed the shape of the visuals

Database and local storage

What exists, where it lives, and why it is safe to store

The cards below use the current migrations and IndexedDB schema. Sensitive values are called out by encryption boundary, retention, persistence, and what the server deliberately never records.

Browser IndexedDB + WebCrypto Plaintext never persisted. Sensitive rows use AES-GCM under a non-extractable master key.
Rust API Oblivious server Verifies signatures, routes ciphertext, signs time anchors, and rate-limits with HMAC Redis keys.
Backend stores Postgres, Redis, object store Public keys, sealed queues, encrypted backups, aggregate counters, and encrypted chunks only.

Retention and deletion

Data lifetime by layer

Privex does not depend on a human deleting logs later. Most sensitive server-side operational state is either Redis TTL-bound, UNLOGGED, or hard-deleted by protocol events.

How it runs

Current data flows and deferred paths

Each flow names what the server can observe, what it cannot observe, and where current code diverges from the broader V2 target.

Protection stack

What each layer provides to the next

This separates cryptographic protection, metadata protection, storage hardening, and operational guardrails.

Server seizure model

What an attacker finds versus what architecture withholds

What can be found

    What is absent by design

      Complete connected view

      From device secrets to no-log infrastructure

      The final map shows the current deployable shape and the planned metadata layer without pretending every V2 feature is live today.

      Client Web app, WASM crypto, WebCrypto master key, IndexedDB

      Generates keys, encrypts plaintext, stores local state encrypted, signs auth challenges.

      Transport Phase 1 direct WSS, cover traffic; Phase 2 Nym and bridges

      Phase 1 protects content and social graph; Phase 2 targets traffic analysis and censorship.

      Server Axum API, WebSocket, KT proofs, OPAQUE relay, PoW gate

      Routes, verifies, signs timestamps, and stores opaque state without receiving plaintext or IP logs.

      Storage Postgres, Redis, S3-compatible chunks

      Public keys, sealed queue, encrypted opt-in backup, Redis TTLs, and content-addressed encrypted chunks.

      Infra Caddy no access logs, Redis no persistence, WAL minimization, tmpfs logs

      Limits what survives disk imaging, service compromise, operator access, or legal seizure.