I still don't see it. I appreciate that you do and that you made a product to deal with it but I just think it's still a bad pattern.
332 karma · joined October 19, 2011
I still don't see it. I appreciate that you do and that you made a product to deal with it but I just think it's still a bad pattern.
Mcp is dead, gtf out of my context, progressive disclosure is a superior system, server connection bloat was a shittastic idea
i mean good luck, but you picked a narrow market
claude -p "summarize this code" < main.go
crush, opencode.. don't understand what this offers
IP?
it might be wtong but i wouldve had to invest significant time to understand your networking model without it.
-----
## Holesail Connection & Encryption Architecture
### Core Technology Stack
Holesail is built on top of *Holepunch’s Hyperswarm* ecosystem, specifically:
1. *HyperDHT* - Kademlia-based distributed hash table for peer discovery 1. *Hyperswarm* - High-level P2P networking abstraction 1. *@hyperswarm/secret-stream* - Noise Protocol + libsodium encryption layer 1. *UDX* - Custom UDP transport protocol
-----
### Connection Technique: UDP Holepunching
*How it works:*
1. *Peer Discovery via DHT*: When you run `holesail --live <port>`, the server generates an *Ed25519 keypair* and announces its public key to the HyperDHT. The connection string (`hs://...`) is essentially this public key encoded. 1. *NAT Traversal*: The DHT nodes themselves act as holepunch facilitators. Unlike traditional STUN/TURN servers, any peer in the DHT can help coordinate the holepunch between two NAT’d peers. This is what makes it “truly P2P” - no centralized relay infrastructure. 1. *Holepunch Mechanics*:
- Both peers send UDP packets to each other’s external IP:port (discovered via DHT) - The simultaneous outbound packets “punch” holes in both NATs - The DHT nodes relay timing/coordination metadata - Once holepunched, a direct UDP connection is established
1. *Transport*: Uses *UDX* (custom UDP protocol) for the data plane after holepunching. TCP fallback is available when UDP fails.
-----
### Encryption Management
*Two-layer encryption using Noise Protocol + libsodium secretstream:*
|Layer |Protocol |Purpose | |---------|--------------------------|------------------------------------| |Handshake|*Noise XX pattern* |Key exchange, mutual authentication | |Data |*libsodium secretstream*|Symmetric encryption of all payloads|
*Cryptographic Primitives:*
- *Key generation*: Ed25519 keypairs (identity/authentication) - *Key exchange*: Noise Protocol XX pattern (ephemeral DH) - *Symmetric encryption*: XChaCha20-Poly1305 (via libsodium secretstream) - *Handshake hash*: Unique per-session identifier (`socket.handshakeHash`) for crypto binding
*Secure vs Insecure Mode:*
- `hs://s000...` = *Secure* (prefix `s`) - Full Noise handshake with authentication - `hs://0000...` = *Insecure* - Presumably skips authentication (anonymous connections)
*The flow:*
``` 1. Peer A generates keypair → announces publicKey to DHT 2. Peer B looks up publicKey → initiates holepunch 3. After UDP connection established: a. Noise XX handshake begins (ephemeral keys exchanged) b. Both sides derive shared secret c. secretstream initialized with derived keys 4. All subsequent data encrypted with XChaCha20-Poly1305 ```
-----
### Key Properties
- *Identity-based routing*: Peers connect by public key, not IP address - works even if you move networks - *E2E encrypted by default*: No way for DHT nodes or relays to read your traffic - *No central servers*: Bootstrap nodes exist but only for DHT entry; traffic never routes through them - *Firewall support*: Optional `firewall()` callback to accept/reject connections by remotePublicKey
-----
### References
- Holesail: <https://github.com/holesail/holesail> - HyperDHT: <https://github.com/holepunchto/hyperdht> - Hyperswarm Secret Stream: <https://github.com/holepunchto/hyperswarm-secret-stream> - Holepunch docs: <https://docs.holepunch.to/building-blocks/hyperswarm> - Hypertele (predecessor): <https://github.com/bitfinexcom/hypertele>
ymmv
reading up on how crush, goose, and opencode handle this may be a good idea.
i've been trying to build a web native terminal assistant for a while (just a side project) and this is easily the thing that keeps me up at night.
### Primary Sources: - *Anthropic Engineering Blog: "Making Claude Code more secure and autonomous with sandboxing"* Detailed article on Claude Code's sandboxing features, including OS-level primitives (e.g., Linux Bubblewrap, macOS Seatbelt) for filesystem and network isolation. [Read here](https://www.anthropic.com/engineering/claude-code-sandboxing) (Published Oct 20, 2025).
- *Claude Code Documentation: Sandboxing* Official docs covering setup, configuration, security benefits (e.g., prompt injection protection), and limitations of filesystem/network isolation in Claude Code. [Read here](https://code.claude.com/docs/en/sandboxing).
- *Claude Blog: "Beyond permission prompts: making Claude Code more secure and autonomous"* Overview of sandboxing in Claude Code, emphasizing boundaries for safer agent execution. [Read here](https://claude.com/blog/beyond-permission-prompts-making-cla...) (Published Oct 31, 2025).
### Additional Resources: For broader context on sandboxing agentic AI: - *arXiv Paper: "Securing AI Agent Execution"* Research on isolation techniques for AI agents, including risk assessment. [Read here](https://arxiv.org/abs/2510.21236) (Published Oct 24, 2025). - *HopX Documentation* Practical guide to sandboxing for AI agents (e.g., using Firecracker micro-VMs). [Read here](https://hopx.ai/) (Open-source SDK available at [GitHub](https://github.com/hopx-ai/sdk)).
### Cursor Cursor uses local-first editing with optional sandboxing via Docker containers for isolated execution (no default vendor-owned sandboxes). It respects user-defined rules without overriding them.
- *Skywork AI Blog: Security in Cursor 2.0* Details Cursor's sandboxing for code execution, network protection, and isolation. [Read here](https://skywork.ai/blog/vibecoding/cursor-2-0-security-priva...) (Published Nov 1, 2025).
- *Skywork AI Blog: Cursor 2.0 vs Claude Code SDK* Compares isolation techniques, noting Cursor's local sandboxes vs. Claude's cloud-based ones. [Read here](https://skywork.ai/blog/vibecoding/cursor-2-0-vs-claude-code...) (Published Nov 1, 2025).
### OpenAI Codex Codex primarily relies on API-based execution with optional user-managed sandboxes (e.g., via Firecracker or custom proxies). It emphasizes provider retention policies but lacks built-in native sandboxing like Claude Code.
- *Render Blog: Testing AI Coding Agents (2025)* Benchmarks Codex's handling of isolation in production tasks, including Docker-based sandboxes. [Read here](https://render.com/blog/ai-coding-agents-benchmark) (Published Aug 12, 2025).
- *Medium: Claude Code vs Cursor* Indirect comparison noting Codex's API retention and sandbox limitations vs. Cursor/Claude. [Read here](https://open-data-analytics.medium.com/claude-code-vs-cursor...) (Published Aug 6, 2025).
### Goose AI (Codename Goose) Goose uses container-based isolation via tools like Container Use (built on Dagger) for git-branch-isolated environments, emphasizing safe experimentation without affecting the host.
- *Goose Blog: Isolated Dev Environments* Explains Goose's container-use for sandboxes, including lifecycle management and rollback. [Read here](https://block.github.io/goose/blog/2025/06/19/isolated-devel...) (Published Jun 19, 2025).
- *GitHub Discussion: Goose vs Claude Code* Community analysis comparing Goose's local isolation to Claude Code's cloud sandboxes. [Read here](https://github.com/block/goose/discussions/3133) (Ongoing, started Jun 27, 2025).
- *Slashdot: Compare Claude vs. Goose* High-level comparison including deployment isolation. [Read here](https://slashdot.org/software/comparison/Claude-vs-codename-...).
also: check out the open-source sandbox runtime from Anthropic: [GitHub Repo](https://github.com/anthropic-experimental/sandbox-runtime).
clearly i have a bias on this topic, lol
well thanks for the hype, wtf is that based on?