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. Aether 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. libp2p The Core Philosophy: Zero-Server by Design Building 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. The Tech Stack: I utilized ethers.js to generate a wallet based on the Secp256k1 elliptic curve. The Tech Stack: ethers.js The Implementation: Upon the first launch, the Electron Main process generates a 32-byte private key. The Implementation: 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. The User ID: wallet.address 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. Current Security Debt: identity.json app.getPath('userData') 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. 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 Renderer (UI): 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 Preload Bridge: contextBridge "send this string to this PeerID" 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. The Main Process: libp2p Phase 3: Networking and the ESM Dependency Hell Setting 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. libp2p @libp2p 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. 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(). Node Discovery (mDNS): dial() Transports: We spun up two transports simultaneously: TCP (for raw speed) and WebSockets (to ensure future compatibility with browser-based nodes). Transports: 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. Muxing & Encryption: Yamux Noise Phase 4: Direct Stream Protocol (/aether/chat/1.0.0) /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. 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. Protocol Negotiation: /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. Stream Handling: it-pipe Uint8Array 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. 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. Encryption at Rest (The Vault): identity.json 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. Global Peer Discovery (Kademlia DHT): 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. Local Persistence (SQLite/LevelDB): 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. End-to-End Encryption (Double Ratchet): 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. Rich Data Streams: /aether/files/1.0.0 Buffer 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 The full code for this architectural MVP is open-sourced on my GitHub GitHub

This post provides insights into new product. 

The code in this story is for educational purposes. The readers are solely responsible for whatever they build with it.

This story contains AI-generated text. The author has used AI either for research, to generate outlines, or write the text itself. 

Huobi Token

Render

GitHub

Building Aether: Architectural Breakdown of a Local-First P2P Messenger

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Stop Summarizing - Start Shaping

102 Stories To Learn About Encryption

153 Stories To Learn About Cryptography

5 Books You Can Read to Boost Your Computer Science Knowledge

6 Not-so-obvious Tech Predictions

63 Stories To Learn About Quantum Computing

Stop Summarizing - Start Shaping

102 Stories To Learn About Encryption

153 Stories To Learn About Cryptography

5 Books You Can Read to Boost Your Computer Science Knowledge

6 Not-so-obvious Tech Predictions

63 Stories To Learn About Quantum Computing

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps