标签：#electrobun

Part 3 of the ERTH Architecture Series: Preventing port-scanning attacks and local socket hijacking in multi-process desktop apps. In the second part of this series , we built a self-healing Watchdog daemon in Bun to monitor and resurrect our Python sidecar backend (Robyn). Now, our desktop app is extremely stable. But it is also extremely insecure. You might think: "This is a desktop app running entirely on 127.0.0.1 (localhost). People from the internet can't access it, so why do I need security?" This is a classic cognitive blind spot in desktop app development. In reality, your local loopback interface is shared globally by the operating system. Any script running in the user’s web browser (e.g., a malicious website they happen to visit) can aggressively scan local ports (from 10000 to 65535). Once it hits your Robyn sidecar's dynamic port, it can send unauthenticated POST requests to delete databases, read private files, or trigger system actions. To prevent this, we must build a Zero-Trust Shield using Opaque Tokens to lock down all communication between the frontend WebView and the Python sidecar. The Zero-Trust Security Model To block unauthorized local traffic, the frontend and backend must share a cryptographically secure, short-lived token. Any request lacking this token will be instantly rejected by Robyn with a 403 Forbidden response. Here is how the defense line functions: Let's implement this architecture step-by-step. Step 1: Generating the Ephemeral Token in Bun Rather than saving credentials to a local config file (which could be read by malware on the system), we generate a random UUIDv4 in Bun’s process memory at startup. This token exists only during the application's runtime. // src-app/frontend/src/bun/index.ts // Generate a cryptographically secure, one-time Opaque Token in memory const agentSecretToken = crypto . randomUUID (); Next, we inject this token into the child process's environment variables when we spawn the Python sidecar: // Spaw

How the ERTH Architecture (ElectroBun + Robyn + Turso + HTMX) breaks the obesity of modern desktop app development. If you’ve tried to build a cross-platform desktop application recently, you’ve likely faced the classic developer’s dilemma: Electron makes developer velocity fast, but at the cost of dragging a bloated Chromium kernel and Node.js runtime into every build. A simple "Hello World" easily eats up 200MB+ of disk space and hundreds of megabytes of RAM. Tauri solves the footprint issue by using OS-native WebViews and Rust, but forces you onto Rust’s steep learning curve, sacrificing the agility of rapid prototyping. The Python Distribution Hell : With the rise of local LLMs and Edge AI, Python is the de facto language for AI orchestration. Yet, packaging Python, its heavy dependencies, and databases into a double-click-to-run package for non-technical users remains a nightmare. Faced with these shackles, I decided to take a step back and rewrite the physical laws of desktop development. Today, I’m introducing the ERTH Stack ( E lectroBun + R obyn + T urso + H TMX)—a heterogeneous, local-first, zero-JS desktop application architecture designed for independent full-stack creators. And yes, the entire bundle—including a browser shell, a high-performance Python sidecar, a local database, and local AI agent execution—packages into a single 128MB standalone binary. Our open-source implementation is live on GitHub: 👉 GitHub Repository: bnpysse/erth_assistant The Core Pillars of the ERTH Architecture To achieve a minimalist footprint without sacrificing developer velocity, we structured the architecture into four core layers: ERTH ARCHITECTURE [E]lectroBun (UI Shell) ───[HTMX]───► [H]TMX (Zero-JS Frontend) │ ▲ (IPC) (HTTP) ▼ │ [R]obyn (Python Sidecar) ───────────► [T]urso / libSQL (Local-First DB) 1. [E]lectroBun: The Lightweight Shell Instead of Electron’s heavy Chromium, ElectroBun binds directly to the OS-native WebKit engine (Cocoa WebKit on macOS, WebView2 on W