How Gruve works

The Gruve lobby for a net called The Hole — your machine's apps as tiles, a members panel, and an end-to-end encrypted chat at the bottom. — A live lobby — your machine's apps, who's in your net, and end-to-end encrypted chat, all in one place.

01 · The net

Your crew gets a net.

A net is a private network for one friend group, with one owner. You start a net, you invite your people, and that's the whole membership system — there's no public discovery, no search, no strangers. If you're not invited, the net doesn't exist for you.

The gap in our logo is the invitation: a net is a closed border that opens, deliberately, for a friend. You can belong to several nets at once — your college crew, your coworkers, your siblings — and Gruve shows them all in one lobby, side by side.

The 'Add a network' dialog: paste a friend's invite phrase to join their mesh, or name and start your own. — Join a friend's net with the invite phrase they sent, or start your own in a few seconds.

02 · The nodes

Apps stay home.

Every machine in a net is a node — your laptop, your desktop, a friend's homelab box. Apps run on the node where they were made, and friends connect to them there. Nothing gets uploaded, deployed, or copied to a platform.

This has one honest consequence: when a host's machine sleeps, its apps go dark. The tile grays out in everyone's lobby until the node comes back. That's not a bug — it's what owning your stuff looks like. (Always-on nodes, on the roadmap, are for the apps that deserve to outlive a laptop lid.)

03 · The doors

Two ways into any app.

Together

A shared session. A presence layer composites over the app — friends' cursors drifting, a shared whiteboard, an avatar bar — and it works over any iframe, no app cooperation required. Apps built against the Gruve SDK go further and share real state: last-write-wins per key, replayed to late joiners, so everyone edits the same document or plays the same board. Authors never write netcode.

Solo

Your own private session against the host's backend — dedicated-server style. The app needs no special handling; backend multiplayer lives in the host's backend behind named upstreams, where it works for solo viewers too.

A modal-synthesis app running, with a shared whiteboard sketch drawn over it by a friend. — Together: live cursors and a shared whiteboard composite over any app — here, sketched across a running synth.

04 · The mesh

Peer to peer, all the way down.

Machines in a net reach each other over direct, encrypted connections, with hole-punching handled for you — no port forwarding, no router settings, no VPN to install. Identity is your machine's cryptographic node ID, so there's no account and no login server.

And it's peer-to-peer the whole way down — not just your data, but the coordination too. Membership and presence gossip directly between nodes; nothing central keeps the lights on. The one optional helper is a cosmetic shortener that turns a long reference into a few friendly words, and you can skip it entirely — raw references work fine. Nothing about the mesh depends on us being alive.

05 · Beyond apps

Chat, files, and ports — same mesh.

The link between your machines isn't only for apps. Every net has end-to-end encrypted chat built in. You can send a file or an entire folder by reference — your friend streams it straight from your disk, with no upload step and no copy left on a server. And you can share a local port, so anything already running on your machine becomes reachable to a friend as if it were on theirs.

The 'Share a port' dialog: name a local service and the port it runs on, and everyone in the net can reach it. — Share a local port — a game server, SSH, a database — and everyone in the net reaches it at a localhost address of their own.

For builders

"Make it multiplayer" is a sentence, not a project.

An app joins the mesh by announcing itself to the local agent — one POST, re-sent as a heartbeat. Declare your UI port and any backend ports as named upstreams:

// from your backend (Node, Python, anything)
import { announce } from "gruve-sdk";
announce({ id: "myapp", name: "My App", port: UI_PORT, upstreams: { api: API_PORT } });

Route backend calls through the SDK so they resolve on whoever's hosting, not a hardcoded localhost. And if you want shared state, joinSession is the whole surface — subscribe to remote changes, set a key. Small enough that telling your AI assistant to wire it up works on the first try:

const API = apiBase("api")            // reaches the host's backend, wherever it runs

const session = joinSession()
session.state.subscribe((key, value) => { /* apply remote truth */ })
session.state.set("instrument", "ETH/USDT") // LWW per key. that's the netcode.

gruve-kit is all of this in one open-source repo — the SDK (JavaScript and Rust), the linter, and the full contract with the failure each rule came from. It's written to be read by a coding agent in a single pass: drop it in, say "make this work on Gruve," and let it do the wiring.

gruve-kit on GitHub →