Show HN: EphemeralNet – Secure C++ P2P infrastructure for hostile networks
Mood
informative
Sentiment
positive
Category
startup_launch
Key topics
P2p
Security
C++
Networking
Discussion Activity
Light discussionFirst comment
27s
Peak period
2
Hour 1
Avg / period
2
Based on 2 loaded comments
Key moments
- 01Story posted
Nov 24, 2025 at 4:48 AM EST
4h ago
Step 01 - 02First comment
Nov 24, 2025 at 4:48 AM EST
27s after posting
Step 02 - 03Peak activity
2 comments in Hour 1
Hottest window of the conversation
Step 03 - 04Latest activity
Nov 24, 2025 at 5:08 AM EST
4h ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
I built this because I wanted to tackle two deeply annoying problems in distributed systems simultaneously: getting P2P traffic through aggressive corporate firewalls/CGNATs reliably, and guaranteeing that shared data actually expires across a mesh without central coordination.
It’s a standalone infrastructure daemon written from scratch in C++20 (no Boost, minimal dependencies).
Some technical details for those interested:
The NAT Problem: It uses standard STUN, but falls back to a custom, high-performance asynchronous relay server I built using Linux epoll and macOS kqueue edge-triggered notification. It’s designed to handle high-throughput spikes efficiently.
The Expiration Problem: It implements a modified Kademlia DHT where TTL (Time-To-Live) is a first-class constraint enforced cryptographically across the network. Nodes actively reject and purge expired records.
Security: Handshake involves a proof-of-work puzzle to mitigate Sybil attacks. Transport is encrypted using ChaCha20-Poly1305 with rotating session keys.
It’s currently v1.0.0. The docs and architecture diagram are at the link. I’d love to hear your feedback on the design choices, especially around the relay architecture.
Thanks!
The decision to build a custom one using edge-triggered epoll was driven by the need to handle many short-lived connections efficiently without the overhead of a full STUN/TURN stack for every single handshake. I'm curious if anyone here has experience scaling similar custom relay architectures in production.
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.