wut?

trust us bro, send us your context, we're for sure 100% safe

we're going to literally hotmod your contrxt for you and not tell you how.

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 `, 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