How Venoly is built

This describes Venoly's architecture at the level needed to understand and trust it. It deliberately omits anything an attacker could use — versions, infrastructure topology, exact thresholds, internal data-model names, and secret-handling paths.

Shape of the system

Venoly is a real-time communication platform composed of a web/mobile/desktop client, a stateless API + realtime gateway, a dedicated media server for voice and video, a security virtual machine that evaluates policies on requests, and durable storage with encryption at rest. The security layers are on by default — they are not optional toggles.

Layers

LayerWhat it does
ClientsA React single-page web app, an Android app, and a desktop app. The same product surface across platforms.
EdgeTLS termination, static delivery, and edge rate-limiting in front of the API.
API & realtime gatewayA stateless HTTP API plus a realtime (WebSocket) gateway. Every realtime payload is validated before it reaches application logic.
Security VM (Venilator)Compiled, human-readable policies run deterministically on relevant requests, returning block / throttle / warn / captcha.
Realtime fan-outA pub/sub layer so events are delivered consistently across a clustered deployment.
Media serverA selective forwarding unit (SFU) carries voice, video, and screen-share separately from the API.
Data at restA relational database with sensitive columns behind a versioned encryption layer plus structural de-identification.
AI character layerA model runtime backs AI characters that appear as members; it degrades gracefully (characters go offline) if unavailable.

Defense in depth

Several independent, in-house subsystems run on every request rather than relying on a single gate. Each is described in detail (with safe, algorithmically-faithful excerpts) on the security deep-dive:

SubsystemRole
VenilatorAn inspectable security-policy language (.vnl) compiled to bytecode and run on a sandboxed stack VM. Deterministic — same input, same decision.
AegisBehavioral anti-abuse — a deterministic timing statistic separates automation from human jitter.
SentinelAccount-takeover defense — additive login risk scoring with step-up challenges.
CipherAn append-only, hash-chained audit ledger; an exported log can be recomputed independently.
WardenPer-message provenance so silent, out-of-band edits to stored messages are detectable.
TripwireHoneytokens planted across the API to flag scrapers and insider misuse.
Vault & SmushEncryption at rest for sensitive columns plus structural de-identification.
DGCA forensicsConsent-based device fingerprinting to catch abuse across IP rotation.

Design principles

  • Deterministic, inspectable security — decisions are reproducible, not the opaque output of a model.
  • Defense in depth — multiple independent layers, on by default.
  • Privacy as architecture — encryption at rest, de-identification, no third-party trackers, EU/GDPR-first.
  • Integrity you can verify — hash-chained logs and per-message provenance.
  • Graceful degradation — optional subsystems (e.g. AI) fail safe rather than taking the platform down.

What is intentionally not published

To keep this useful for understanding but useless for attack, Venoly does not publish exact software versions, infrastructure addresses or topology, precise rate-limit or risk-score thresholds, internal table/column names, secret-loading paths, or production policy constants. The security page explains the algorithms; the evasion-tunable numbers stay private by design.

Venoly
Venoly
Loading