"Assume the Server is Malicious."
This is the founding principle of Syncra. Every line of code in the client is written with the expectation that the relay server is being monitored by a third party.
Syncra is a high-performance, security-first messaging infrastructure designed for the modern era of privacy. Unlike traditional messaging platforms that rely on trusted central servers, Syncra operates on a Blind Relay model. This means the server lacks the cryptographic keys required to decrypt any conversational data, ensuring that even if the infrastructure is compromised, your messages remain sovereign and unreadable to third parties.
Built with Go, Syncra leverages advanced concurrency patterns to handle thousands of simultaneous WebSocket connections with minimal latency. It combines the speed of a distributed networking stack with the uncompromising security of Ed25519 digital signatures and AES-256-GCM encryption. Whether you're communicating across a local network or a global cluster, Syncra provides a seamless, real-time experience through its Redis-backed horizontal scaling.
- Absolute Privacy: True End-to-End Encryption (E2EE) where only the recipients hold the keys.
- Stateless Resilience: A relay architecture that stores zero history, mitigating long-term data breach risks.
- Developer-Centric: A modular codebase designed for extensibility, from the cryptographic pipelines to the reactive Terminal UI.
- Enterprise Ready: Designed to bypass restrictive firewalls and operate in high-security environments using standard WSS protocols.
About Syncra
Infrastructure & Scalability
Best-Practice Project Organization
Cryptographic Protocol Deep Dive
The Networking Stack
Terminal UI (TUI) Engineering
Storage & Local Sovereignty
Implementation Checklist
Security Threat Model
The project follows a Modular Monorepo approach, separating the high-concurrency relay logic from the cryptographic heavy-lifting of the client.
syncra/
βββ π cmd/ # Entry points (Source of Truth)
β βββ π server/ # The Stateless Blind Relay
β β βββ main.go
β βββ π cli/ # The Terminal CLI Suite
β βββ main.go
β
βββ π internal/ # Private Application Core
β βββ π server/ # Server-side Business Logic
β β βββ π websocket/ # Hub, Handler, & Socket Lifecycle
β β βββ π auth/ # JWT Proofs & Challenge-Response
β β βββ π database/ # PostgreSQL Repository Layer
β β βββ π redis/ # Real-time Pub/Sub Orchestrator
β β βββ π router/ # HTTP/WSS Routing Entry
β β βββ π service/ # Domain Logic & User Orchestration
β β
β βββ π client/ # Client-side Business Logic
β β βββ π websocket/ # Outbound Connection Lifecycle
β β βββ π crypto/ # AES-256-GCM & Ed25519 Pipelines
β β βββ π storage/ # Local-First Filesystem Engine
β β βββ π auth/ # Identity Proof Generation
β β βββ π ui/ # Bubble Tea Reactive Components
β β βββ π config/ # User Preference Management
β β
β βββ π shared/ # Agnostic Contracts & Models
β β βββ π models/ # Cross-boundary Structs
β β βββ π dto/ # Packet Transfer Objects
β β βββ π constants/ # Shared Event Definitions
β β
β βββ π pkg/ # Reusable Tooling
β βββ π logger/ # Structured Zero-Log
β βββ π utils/ # High-performance Helpers
β
βββ π deployments/ # Orchestration & Ingress
β βββ π docker/ # Multi-stage Docker Builds
β βββ π nginx/ # Reverse Proxy & SSL Config
β
βββ π scripts/ # Automation & CI/CD
βββ π configs/ # Environment Variable Schemas
Tip
Senior Mindset: By keeping the
shared/ folder minimal, we ensure that the client binary strictly contains zero server-side vulnerabilities, and the server strictly contains zero cryptographic keys.
The backend isn't just a single server; it's a stateless relay cluster.
ββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
PROJECT INFRASTRUCTURE TOPOLOGY
ββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
[ PUBLIC TIER ] [ INGRESS CONTROL ] [ BACKEND CLUSTER ]
ββββββββββββββ βββββββββββββββββββββ ββββββββββββββββββββββββ
β User App β βββββββββΆβ Nginx / Caddy β ββββββββΆβ Relay Nodes (xN) β
β (Go CLI) β :443/WSS β (SSL Terminate) β :50051 β (Stateless Go) β
ββββββββββββββ βββββββββββ¬ββββββββββ ββββββββββββ¬ββββββββββββ
β β
βΌ βΌ
ββββββββββββββββββββ ββββββββββββββββββββ
β Cloudflare/WAF β β Redis Pub/Sub β
β (DDoS Protect) β :6379 β (Real-time Bus) β
ββββββββββββββββββββ ββββββββββββ¬ββββββββ
β
ββββββββββββββββββββββββββββββββ
β
βΌ
ββββββββββββββββββββ ββββββββββββββββββββ
β PostgreSQL DB β :5432 β JWT / Auth API β
β (Handles/Public) βββββββββββΆβ (Identity Sync) β
ββββββββββββββββββββ ββββββββββββββββββββ
ββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
- WSS (WebSocket Secure): We use
:443to bypass 99% of corporate firewalls that block non-standard ports. - Redis Pub/Sub: Crucial for horizontal scaling. If
User Ais onNode 1andUser Bis onNode 2, Redis acts as the glue that routes the encrypted packet between nodes. - Statelessness: The relay nodes store zero conversational state.
- Neon Serverless Postgres: We utilize Neon for high-performance, scalable storage of user identities and metadata, separating concerns from the stateless message relay.
Upon the first boot, the client generates a permanent identity using Ed25519.
- Reasoning: Ed25519 provides 128-bit security with tiny 32-byte public keys and 64-byte private keys.
- Checklist:
Syncra uses a Sign-then-Encrypt approach for maximum security.
- Ephemeral Key Gen: Random 32-byte AES-256 key for every message.
- Signing: User A signs the plaintext hash using their Ed25519 Private Key.
- Symmetric Encryption (AEAD): Plaintext + signature encrypted using AES-256-GCM.
- Asymmetric Wrapping: AES key encrypted using User B's Public Key.
In Go, the server should run a central Hub goroutine that manages active clients.
type Hub struct {
clients map[string]*Client // map[UserID]*Client
broadcast chan []byte // Inbound packets
register chan *Client // New connections
unregister chan *Client // Dropped connections
}- Concurrency Tip: Use buffered channels for the
broadcastchannel to prevent a "slow consumer" blocking the relay.
Powered by Charmbracelet: Bubble Tea, Lip Gloss, and Bubbles.
- Model: Holds the application state.
- Update: Handles incoming Messages.
- View: Renders the state into a string.
Instead of a database, we use flat files for speed and portability.
- Path:
~/.syncra/chats/<contact_id>.log - Format: JSONL (JSON Lines).
While message content remains local and E2EE, user identities and authentication states are managed via Neon Serverless Postgres.
- Connection: Managed via
pgxpoolfor high-concurrency performance. - Role: Strictly stores non-conversational data (User IDs, Public Keys, Profiles) to maintain the "Blind Relay" promise.
Phase 1: The Secure Sandbox
- Initialize Go module:
go mod init github.com/username/syncra. - Implement
crypto/identity.go: Key generation. - Implement
crypto/aes_gcm.go: AES wrappers.
Phase 2: The Blind Messenger (Server)
- Setup
net/httpwithgorilla/websocket. - Create the
HubandClientstructures. - Implement Redis
PUBLISH/SUBSCRIBEloop.
Phase 3: The Terminal Experience (Client)
- Scaffold
Bubble Teaprogram. - Add an "Onboarding" screen.
- Implement the message history viewport.
| Threat | Prevention / Mitigation |
|---|---|
| Server Inspection | Messages are encrypted at the edge. Server only sees metadata. |
| Identity Forgery | All messages are signed with User A's Private Key. |
| Traffic Replay | Unique Nonce and Timestamp; old packets are discarded. |
| Server Compromise | Server is stateless and blind; attacker gains nothing but current metadata. |
"I architected a high-concurrency, Zero-Knowledge messaging system. The core innovation is the separation of the Identity Layer (Ed25519) from the Transport Layer (WebSockets/Redis). By offloading all decryption logic to the Go binary, I ensured that the backend serves only as a 'Blind Relay', maintaining absolute privacy even in the event of breaches."
Cryptography β’ Go Concurrency β’ TUI Design β’ Distributed Systems
.png)
.png)