About

Lan Party

Give an ordinary HTTP client a local URL for a development service in another agent environment. The prototype routes selected requests through a relay to a peer and service port that you explicitly configure.

Coming soon. Lan Party is a development prototype with no public installation or purchase option. Local fixture tests cover the bounded HTTP relay; cross-environment response streaming has not been verified.

How it works

Each environment opens an outbound connection to a configured relay. A local HTTP frontend accepts requests from tools such as curl or a browser and forwards them to the selected peer and configured service port. A target such as lanparty://peer:port is Lan Party notation, not a system URL handler or DNS name.

• Each peer is pinned to an identity and one permitted service port.
• Agents renew a five-second relay lease every second. A restarted relay or replaced agent gets a new session; replies from an old session are discarded.
• Relay and agents must be upgraded together: session-bound polls, replies, and unregisters reject older session-less agents. The session token prevents an old process from claiming work or changing tunnels after its replacement registers.
• The selected service must already listen on a wildcard address. Lan Party checks this before routing, then connects through that host's loopback address.
• The relay forwards ordinary HTTP requests. Request bodies are buffered before forwarding; response bodies stream incrementally within configured bounds.
• Local endpoints bind to loopback by default. A remote relay requires HTTPS and explicit authentication and remote-relay settings.
• The relay handles routed request and response bytes. Peer signatures authenticate requests but do not provide end-to-end encryption between peers.
• The current method allowlist is GET, HEAD, POST, PUT, PATCH, DELETE, and OPTIONS. WebSockets and arbitrary TCP or UDP are not supported.

Bounds and limits

• Request bodies: up to 1 MiB, buffered before forwarding.
• Response bodies: up to 4 MiB, streamed with a 30-second tunnel limit.
• Response backpressure: at most one response frame (up to 1 MiB) waits in each tunnel queue; the peer pauses while that queue is full.
• Request target: up to 8 KiB. Forwarded headers: up to 64 and 16 KiB combined.
• Connections, queued jobs, and concurrent tunnels are bounded.
• Hop-by-hop headers are removed, along with request Authorization, Cookie, and Proxy-Authorization headers. Only a small set of response headers is forwarded.

The prototype does not provide a VPN, TUN, SFTP, FTP, system DNS changes, WebSockets, resumable transfers, or automatic retry after an interrupted request. A peer that stops renewing its lease is removed from availability checks within five seconds; already-delivered requests fail without being replayed because the service may have executed them. A wildcard-bound service may already be reachable through the host's network interfaces; Lan Party does not manage that service's firewall or exposure.

Local development setup

The development source requires Node.js 20 or later, Python 3.10 or later, and Linux for service-listener checks. The relay's Python signing helper uses the cryptography package declared in requirements.txt. Its --help works before that package is installed; starting the relay without it prints the installation command instead of a Python traceback.

From the repository root, create an isolated Python environment and install the declared signing dependency before running the relay or tests:

~~~sh python3 -m venv .venv . .venv/bin/activate python -m pip install -r requirements.txt npm test ~~~

The test command runs Python unit tests, Node test scripts, and the local demo. It exercises the prototype and is not a public release installer. The source package has no published release license.

The local demo is also available on its own as node scripts/demo.mjs (or npm run demo) from the repository root. It starts same-host synthetic peers whose HTTP services bind to 0.0.0.0, with a loopback relay and local HTTP frontends, then prints and writes artifacts/demo-evidence.json. It replaces that tracked evidence file, so run it from a disposable checkout. The result covers same-host behavior only; it does not establish connectivity or response streaming across separate VMs.