Most "secure" messengers today still rely on centralized infrastructure. Whether it’s for signaling, metadata storage, or push notifications, there is almost always a server sitting between you and your recipient.With Aether, I wanted to take a different route. The goal was to build a strictly local-first software architecture. If two devices are on the same network, they should be able to discover each other and communicate directly—no cloud, no central databases, and no intermediary nodes.Here is a technical breakdown of how I built an architectural MVP of a decentralized P2P messenger using Electron, React, and libp2p, and the engineering bottlenecks I had to solve along the way.\The Core Philosophy: Zero-Server by DesignBuilding a system without a backend forces a complete paradigm shift in how you handle state and routing. You can't rely on a REST API to authenticate users or fetch message history. Every client must act as an independent, self-sufficient network node capable of discovering peers, negotiating protocols, and encrypting streams locally.Phase 1: Cryptographic Identity (Secp256k1)We abandoned the traditional "login/password" concept entirely. In Aether, your identity is pure mathematics.The Tech Stack: I utilized ethers.js to generate a wallet based on the Secp256k1 elliptic curve.The Implementation: Upon the first launch, the Electron Main process generates a 32-byte private key.The User ID: We extract the wallet.address (the Ethereum address format) to serve as the public identifier. It is shorter than a raw public key and more familiar to users interacting with Web3 paradigms.Current Security Debt: Currently, the key is stored as plaintext in an identity.json file within app.getPath('userData'). Acknowledging this vulnerability is the first step; securing it is the immediate next milestone (detailed in the roadmap below). However, by design, this key never leaves the Main process.Phase 2: Isolating the Core (Strict IPC)A common vulnerability in Electron applications is frontend Cross-Site Scripting (XSS) leading to local data theft. To mitigate this, we implemented a strict "Isolating the Core" pattern:The Renderer (UI): Built with React, this is a completely "dumb" presentation layer. It has zero knowledge of where the cryptographic keys are stored and no direct access to the networking stack.The Preload Bridge: Using contextBridge, we exposed a strictly typed API. The frontend can only issue high-level commands like "send this string to this PeerID". It cannot inspect the encryption process or alter node configurations.The Main Process: This is the brain of the application. It safely houses the libp2p networking stack, manages the private keys, and handles all heavy cryptographic lifting.\Phase 3: Networking and the ESM Dependency HellSetting up a P2P node inside an Electron environment introduces a massive headache: the Pure ESM dependency hell. Modern Web3 libraries (libp2p included) are heavily reliant on ES Modules, which historically clash with Electron's CommonJS ecosystem. We solved this by creating a custom Vite configuration that bundles the @libp2p dependencies directly into the Main process.Once the environment was stable, the networking logic was structured as follows:Node Discovery (mDNS): We implemented Multicast DNS. The moment you open Aether, your node broadcasts its presence to the local network. Other local nodes catch this signal and automatically execute a dial().Transports: We spun up two transports simultaneously: TCP (for raw speed) and WebSockets (to ensure future compatibility with browser-based nodes).Muxing & Encryption: We use Yamux for stream multiplexing and the Noise protocol framework for channel encryption. This guarantees that any intercepted traffic between nodes appears as pure cryptographic noise.\Phase 4: Direct Stream Protocol (/aether/chat/1.0.0)Instead of sending standard HTTP requests, Aether nodes communicate via raw data streams.Protocol Negotiation: When you initiate a chat with a discovered peer, the nodes negotiate the use of our custom protocol /aether/chat/1.0.0.Stream Handling: We utilize it-pipe to pipe data through the connection. A text message is encoded into a Uint8Array, fired across the Noise-encrypted channel, and decoded back into a string on the receiving end. It is as close to the "metal" of the network as possible.What's Next? (The Architectural Roadmap)\Pushing this MVP to GitHub is just the baseline. Here are the next technical milestones required to turn this prototype into a production-ready autonomous node:Encryption at Rest (The Vault): To fix the plaintext identity.json issue, we will implement AES-256-GCM encryption for the key file. Users will input a master password, which will be passed through Scrypt (a Key Derivation Function) to safely decrypt the private key locally.Global Peer Discovery (Kademlia DHT): Currently, mDNS only works over LAN/Wi-Fi. To allow internet-wide communication without signaling servers, we will integrate a Distributed Hash Table (DHT). Your node will use bootstrap nodes to find peers globally, turning Aether into a true mesh network.Local Persistence (SQLite/LevelDB): Without a server, there is no cloud history. We plan to embed SQLite or LevelDB directly into the Main process. All messages will be stored locally, paving the way for a future "sync protocol" that allows nodes to exchange missed messages upon reconnection.End-to-End Encryption (Double Ratchet): While the Noise channel is secure, we need a second layer of defense. Integrating the Double Ratchet Algorithm (similar to Signal) will provide Perfect Forward Secrecy—ensuring that even if a session key is compromised, past communications remain locked.Rich Data Streams: Because the architecture is already stream-based, sharing files simply requires negotiating a new protocol (/aether/files/1.0.0) to handle large data chunks (Buffer) and reassemble them on the receiver's end.Aether isn't just a messenger; it's an exploration into autonomous network units.The full code for this architectural MVP is open-sourced on my GitHub