A thin coordinator only introduces two peers; the prompt and answer then flow directly between them, encrypted — never through a server. Here's the stack that does it, and why.
Speed — the prompt goes straight to the serving peer over a direct channel (no cloud hop), and the model runs locally.
Reliability — the Erlang VM supervises and self-heals; WebRTC punches through NATs so peers actually connect and stay connected.
Security — self-authenticating keypair IDs, an encrypted peer channel, and every job settled by a receipt both sides signed.
Privacy — the coordinator never sees a prompt; traffic is end-to-end encrypted and travels peer to peer.
Standards and battle-tested libraries — we add the credit layer, not a new protocol.
Each peer's WebSocket link to the coordinator — for discovery and signaling only.
Slipstream →The direct channel: ICE (NAT traversal) + DTLS (encryption) + SCTP (reliable data). Prompt/answer flow straight between peers.
ex_webrtc → WebRTC →Your peer ID is your public key — no accounts, no central authority. Auth + every receipt signed.
Ed25519 →The local app runtime: lightweight concurrency + OTP supervision, so it self-heals.
Elixir → BEAM/OTP →The small local UI it opens in your browser — no build step, no JS toolchain.
LiveView →The model runs on your own machine; LAPSUS just sits in front of whichever engine you run.
Ollama → LM Studio →