SPORE in the browser

The same SPORE node that runs on a laptop or an ESP32 also runs in a web page. The Rust core is compiled to a small WebAssembly module, and a thin JavaScript layer turns whatever the browser can talk over — a WebSocket, a WebRTC data channel, a Nostr relay — into a SPORE link. A page becomes a full peer: it signs its own messages, relays other people's, and needs no server of its own.

import { loadSpore, Hub, ZERO_DEST } from './spore.mjs';
import { WebSocketTransport } from './transports/websocket.mjs';

const spore = await loadSpore(fetch('./spore.wasm'));
const hub = new Hub(spore.newNode());
hub.onDeliver = (env) => console.log('got:', new TextDecoder().decode(spore.payload(env)));

hub.addTransport(new WebSocketTransport('wss://relay.example/spore'));
hub.send(ZERO_DEST, new TextEncoder().encode('hello mesh'));

That's the whole surface: load the wasm, make a node, wrap it in a hub, and attach transports. The hub is the browser twin of the Rust daemon's bridge hub — a frame that arrives on one transport is fed to the router and its forwards are relayed onto all the others.

Transports

A transport is any object with a send(bytes) method that calls receive(bytes) when a frame arrives. Eleven are included; writing your own is a dozen lines. The standalone build inlines ten of them — Web NFC is left out because it needs Chrome on Android over HTTPS, which a file:// page is not.

The KISS framing shared by the serial and Bluetooth transports lives in transports/kiss.mjs and matches Rust's src/kiss.rs byte-for-byte, so a browser tab and a physical board speak the same wire. The Meshtastic and Reticulum transports are honest device drivers (Meshtastic protobuf / RNode host protocol) but are not hardware-verified in CI — treat them as templates to confirm against your firmware.

import { Transport } from './spore.mjs';
export class MyTransport extends Transport {
  send(bytes) { /* put bytes on the wire */ }
  // call this.receive(bytes) whenever a frame comes back
}

Run the tests

# build the wasm the JS loads
cargo build --release --lib --target wasm32-unknown-unknown

cd web
node test.mjs           # loopback: two hubs, one link, publish + verify
npm install             # pulls `ws` for the next one
node ws-test.mjs        # real WebSocket relay: A -> relay -> B

Both print an OK line. test.mjs needs nothing but Node (it runs the wasm); ws-test.mjs stands up a throwaway ws relay on a random port and sends a signed message through it.

One-file node

node build-standalone.mjs inlines the wasm and every transport into a single spore-standalone.html — a complete, functional node that runs from a file:// path, a USB stick, or an email attachment, making zero network requests until you add a bridge. It boots one live node, then lets you wire it at runtime to a WebSocket relay, a direct WebRTC peer, a Nostr relay, a Meshtastic or Reticulum LoRa radio (USB or Bluetooth), the speakers/mic (audio modem), or a WebTorrent swarm — signing, relaying, and delivering across all of them at once. Its identity and its bridges are remembered in the browser's local storage (the 32-byte signing seed via node.seed() / newNode(seed)), so it returns as the same node; network bridges reconnect on load, device bridges wait for a click. It's the smallest "a whole node in one file" seed; see docs/CONTINUITY.md.

This same file is the web node (the site's /demo/ page): the Pages workflow builds it once and serves it at /demo/ — one URL, not the same ~720 KB payload shipped twice under two paths. docs/APPS.md's "Download" button points at that same URL with an HTML download attribute, so opening it runs the node and downloading it saves the identical file. There is no separate demo page to keep in sync — the thing you download and the thing you run in the browser are one file.