Inside DictatorFlow: A Technical Deep Dive
DictatorFlow is built on three pillars: a Zig native audio engine for desktop, a Go API server for cloud transcription, and a React frontend for management. Here's how they fit together.
Why Zig for Audio
The desktop app is written in Zig. Not Rust, not C++, not Electron. Zig gives us manual memory control without a borrow checker fight, comptime generics for zero-cost abstractions, and cross-compilation to every target from a single codebase. One zig build produces macOS (arm64 + x86_64), Windows, and Linux binaries.
The audio pipeline runs entirely in Zig: capture from the system audio device, real-time VAD, Opus encoding, and streaming to our API over WebSockets. The GUI layer uses native platform APIs (Cocoa on Mac, Win32 on Windows, X11/Wayland on Linux) through Zig's C interop -- no wrapper libraries, no runtime overhead.
Audio Pipeline
Mic Input (48kHz stereo)
|
v
Resample (16kHz mono) ---- Polyphase FIR, SIMD-accelerated
|
v
VAD Gate ---- Energy + zero-crossing + spectral flux
|
v
Noise Suppression ---- Spectral gating, 500ms noise profile
|
v
Opus Encode ---- 32kbps VBR, 20ms frames
|
v
WebSocket Stream ---- Binary frames to dictatorflow.com
|
v
Model Inference ---- GPU cluster, batched
|
v
Text Response ---- JSON with word timestampsGo API Server
The cloud backend is Go. It handles authentication, billing, API key management, WebSocket connections, and request routing to the ML inference cluster. Go's goroutine model maps perfectly to our concurrent WebSocket workload -- each connection gets its own goroutine with minimal memory overhead.
Key design decisions:
- Stateless request handling -- Any API server can handle any request. Session state lives in PostgreSQL + Redis.
- Credit-based billing -- Usage is metered per-second of audio processed, deducted in real-time from a pre-paid balance.
- Rate limiting per API key -- Prevents abuse while allowing burst capacity for batch processing.
Local / Offline Mode
Pro and Lifetime users can run transcription entirely offline. The desktop app bundles a quantized ONNX model (~200MB) that runs on the user's GPU via ONNX Runtime. Quality is slightly lower than cloud (2.1% WER vs 1.2%) but latency is near-zero and no data leaves the machine.
Deployment
The React SPA is served by the Go binary itself -- no separate web server. Static assets are embedded at compile time using Go's embed package. One binary serves the API, WebSocket endpoints, and the marketing site. Deployed on bare metal with GPU access for inference, behind Cloudflare for TLS and DDoS protection.