Skip to content

madhav9757/Syncra

Folders and files

NameName
Last commit message
Last commit date

Latest commit

Β 

History

9 Commits
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 

Repository files navigation

Syncra Logo Syncra Sub Logo

The Definitive Technical Blueprint for High-Performance E2EE Communication

Go Version Security: E2EE Architecture: Zero--Knowledge Database: Neon Status: Blueprint


"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.

About Syncra

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.

Core Pillars:

  • 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.

Table of Contents


Infrastructure & Scalability

Codebase Lifecycle & Project Anatomy

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.


High-Level Topology

The backend isn't just a single server; it's a stateless relay cluster.

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)  β”‚
                                β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜          β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜

══════════════════════════════════════════════════════════════════════════════════════

πŸ› οΈ Infra Decisions:

  • WSS (WebSocket Secure): We use :443 to bypass 99% of corporate firewalls that block non-standard ports.
  • Redis Pub/Sub: Crucial for horizontal scaling. If User A is on Node 1 and User B is on Node 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.

Cryptographic Protocol Deep Dive

1. Identity Generation

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:
    • Use crypto/ed25519 to generate Seed, PublicKey, and PrivateKey.
    • Encrypt the PrivateKey locally using AES-256-KWP.

2. The Hybrid Encryption Pipeline (E2EE)

Syncra uses a Sign-then-Encrypt approach for maximum security.

  1. Ephemeral Key Gen: Random 32-byte AES-256 key for every message.
  2. Signing: User A signs the plaintext hash using their Ed25519 Private Key.
  3. Symmetric Encryption (AEAD): Plaintext + signature encrypted using AES-256-GCM.
  4. Asymmetric Wrapping: AES key encrypted using User B's Public Key.

The Networking Stack (WebSocket + Redis)

1. The Relay "Hub" Pattern

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 broadcast channel to prevent a "slow consumer" blocking the relay.

Terminal UI (TUI) Engineering

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.

Storage & Local Sovereignty

1. Append-Only Chat Logs

Instead of a database, we use flat files for speed and portability.

  • Path: ~/.syncra/chats/<contact_id>.log
  • Format: JSONL (JSON Lines).

2. Identity & Metadata (Neon DB)

While message content remains local and E2EE, user identities and authentication states are managed via Neon Serverless Postgres.

  • Connection: Managed via pgxpool for high-concurrency performance.
  • Role: Strictly stores non-conversational data (User IDs, Public Keys, Profiles) to maintain the "Blind Relay" promise.

Implementation Checklist (Step-by-Step)

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/http with gorilla/websocket.
  • Create the Hub and Client structures.
  • Implement Redis PUBLISH/SUBSCRIBE loop.
Phase 3: The Terminal Experience (Client)
  • Scaffold Bubble Tea program.
  • Add an "Onboarding" screen.
  • Implement the message history viewport.

Security Threat Model

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.

Professional Engineering Narrative

"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."


Deep Learning Links

Cryptography β€’ Go Concurrency β€’ TUI Design β€’ Distributed Systems

About

Syncra is a terminal-native, end-to-end encrypted messaging platform built for secure real-time communication. It combines modern cryptography with a lightweight relay architecture to deliver private, synchronized conversations over the command line.

Topics

Resources

Stars

Watchers

Forks

Contributors