Bring someone in. Share a thought or a file.
Your browsers carry the conversation.
Live direct connections from this browser. Dashed links are room bridges. Select a peer to inspect it.
A portable peer-to-peer communication demo. Chat, share files, and explore the machinery behind a browser-owned network.
At its core, Relay lets people communicate directly with each other using WebRTC DataChannels. Once peers are connected, messages and files move directly between browsers instead of being routed through a central server. The signaling server only helps peers find each other and establish the initial connection. After that, the server is mostly out of the picture.
Relay normally uses a lightweight signaling server for peer discovery and room coordination, but existing peer connections continue functioning during outages and new peers can still connect through fallback methods.
Everything runs directly in the browser from a single static page.
When you open Relay, you are assigned a per-tab browser identity. On supported secure origins, a signing key proves continuity of that identity; it does not verify a real person. A reload retains it, while a new tab gets its own identity. You can optionally choose a display name so other peers can recognize you more easily.
Relay will automatically place you into a room and begin connecting to nearby peers. Once connected, you can send chat messages, share files directly peer to peer, invite additional peers, browse active rooms, and monitor network and connection statistics in real time.
Relay organizes peers into automatically balanced rooms to avoid overcrowding or fragmentation. Each room forms a peer mesh where browsers connect directly to each other. Smaller rooms operate as a full mesh where everyone connects to everyone else. Larger rooms gradually shift into a partial mesh structure where coordinator peers help relay traffic between less directly connected nodes. Rooms automatically disappear after everyone leaves them.
Relay supports multiple connection paths so the network can survive disruptions.
Server-Assisted Mode is the normal operating mode. A lightweight join server helps peers discover each other and exchange WebRTC handshake information. The server is join-only: it brokers first contact (room placement, invite codes, join-time handshake relay, a small registry of landing coordinators) and then backs out entirely. Handshake relay is limited to a short join window, room state lives in the mesh itself, and the server never sees chat messages or files. If the join server disappears, nothing about the running mesh changes — only automatic joining for newcomers pauses until it returns.
Rooms belong to the browsers. Your page creates each room's id and name; the join server just honors it, so a server restart can never split or rename a room. Newcomers fill one room up to a handful of people, then the next newcomer starts a fresh one. Anyone can start a named room — it stays open while people are in it and is listed for others to join, but newcomers are never auto-placed there. Reloading (or coming back later) returns you to the room you were in, re-opening it if everyone left.
Meshnet Mode uses a rendezvous service, ntfy.sh by default. The browser creates a WebRTC offer locally, embeds it into a URL or QR code, and the answering peer responds through that service to establish a direct connection without relying on the Relay signaling server.
Manual Mode supports fully manual handshakes with no signaling or rendezvous service. One user generates an offer string and sends it however they want. The second user pastes it into Relay, generates an answer, and sends that back. Once both sides exchange the strings, the WebRTC connection completes.
Files are transferred directly between peers over WebRTC DataChannels. When you share a file, Relay creates a temporary file token and other peers see the available file. Downloads stream directly between browsers with chunking and backpressure protection. The server never stores or proxies the file contents.
Each room elects a coordinator peer automatically based on availability, reachability, capacity, and tenure. Coordinators help maintain room state, assist with peer recovery, relay traffic in partial mesh rooms, and participate in the larger HostMesh federation.
HostMesh is a coordinator-to-coordinator overlay network that allows rooms to discover each other without relying entirely on the server. Coordinators exchange lightweight manifests describing active rooms and their availability.
Relay exposes a large amount of live network information directly to the user. You can inspect ICE connection states, RTT and latency, candidate types, bytes and packets transferred, DTLS state, available bandwidth, peer counts, and DataChannel health. The goal is to make the network visible instead of hiding it behind opaque UI layers.
If the signaling server restarts, existing peer connections continue functioning, coordinators rebuild room state, and peers reassociate automatically. If direct peer paths fail, Relay can route through coordinators or relay peers. If centralized infrastructure disappears entirely, Manual and Meshnet modes still allow new connections.
Rooms are public and named rooms are listed. Signing identifies a browser key, not a person. Legacy peers are unverified. WebRTC encrypts each connection; room participants and peers forwarding room traffic can read that traffic. Direct peers can learn network address information. Clients keep a bounded 30-minute cache of recent room messages and replayable game events. Joining or returning peers can recover that recent traffic; there is no server archive. Clear chat clears your view, not other peers' copies. Files are offered to the room and downloaded only on request.
Save copy produces a clean, self-contained app without your messages, keys, or invitation state. Connection settings belong to this browser and are not included. Advanced view exposes diagnostics; the topology tool starts only while open and stops when closed or hidden.
Relay is built around a simple idea: communication systems should not collapse because one server, service, or provider disappears. It favors direct browser-to-browser networking, visible system state, recoverability, and layered fallback mechanisms over centralized control.
Share a link or short code; the other person joins automatically while the server is online.
Share the link; the other person's browser connects automatically via ntfy.sh. No Relay server required; ntfy.sh carries the answer.
Generate a code and send it to the other person. Works on a reachable local network without an internet signaling service.
Paste the offer or answer code from the other person.