Day Two — The Invisible Hero Behind the Curtain

NodePulse was born from a deceptively simple need: an ultra-lightweight, self-installing client that works both from the open web and from localhost:8080 on the machine where it runs. Behind that single entry point sits a full suite of work tools — including a private cloud that belongs to no one but you.

The decentralized network wasn't planned. It grew out of a stubborn, unglamorous problem. We use Cloudflare Tunnel as our default relay — it's free, it's fast, and it gives any device a public URL in seconds. But every time the connection drops, Cloudflare hands you a brand-new random URL. Bookmark a server's page today, come back three months later, and that URL points to absolutely nothing. Your server is still there, humming in a drawer somewhere. But the address is gone.

This is where the real hero of the architecture steps in — and it's not a blockchain, not a consensus algorithm, not a token. It's a Service Worker.

When you first visit a NodePulse node, a Service Worker silently installs itself in your browser. It caches a small, self-contained Recovery Browser — a few kilobytes of HTML and JavaScript that can survive for up to a year in your browser's cache. The moment the tunnel URL dies and your browser gets a connection error, the Service Worker intercepts the failed request and serves the cached Recovery Browser instead of a blank error page.

What happens next is quietly remarkable. The Recovery Browser already knows the node's cryptographic identity — its node_id, derived from the SHA-256 hash of its RSA public key. It carries a list of seed nodes, enriched over time through background gossip. It begins querying those seeds: 'Have you seen this node_id recently? What's its current URL?' When a seed responds with a fresh, verified address, the Recovery Browser pings it to confirm the node is alive, then redirects you — transparently, automatically — to the new URL. Your original path is restored. You land exactly where you meant to be.

The beauty of this system is that it requires nothing from the user. No app to install, no extension, no account. The browser itself becomes the recovery mechanism. A visitor who came once, months ago, can still find their way back — even if every URL they ever knew has changed. The Service Worker is the silent thread connecting the visitor to a machine whose address is, by design, ephemeral.

Once recovery existed, the rest of the architecture fell into place like inevitable consequences. If nodes can relocate visitors, they need to prove they are who they claim to be — hence RSA-2048 key pairs and signed announcements. If announcements need to propagate without a central server, you need gossip. If gossip needs to bootstrap from nothing, you need seed nodes. If seed nodes should be decentralized too, you need domain-layer seeds that discover each other through the same protocol they serve. Every piece exists because the previous piece demanded it.

And then there's the relay question. Cloudflare Tunnel is our current default — zero cost, high speed, but ephemeral URLs. The architecture, however, is entirely relay-agnostic. We've already designed support for three additional relay types, and all of them coexist on the same network using the same gossip protocol.

First: Tor hidden services. A .onion address is derived from a cryptographic key and never changes. Once a node publishes its .onion, the URL is permanent. No more recovery needed — just heartbeat announcements for liveness. Full operator anonymity comes as a side effect.

Second: self-hosted VPS tunneling using open-source tools like frp (Fast Reverse Proxy) and rathole. The idea is simple — you rent a cheap VPS, run the server component, point a wildcard DNS to it (say, *.plexum.net), and every node gets a stable subdomain derived from the first six hex characters of its node_id. Something like 4a7f3c.plexum.net — human-readable, permanent, tied to the node's cryptographic identity. No more random URLs, no dependence on Cloudflare, and the cost is split across all nodes using that relay.

The point is this: Plexum doesn't care how your device reaches the internet. It cares that your device can prove it is itself, and that the network can find it again when the address changes. The relay is plumbing. The identity is the architecture.

If you think about what this adds up to, it's essentially a private-server alternative to the traditional internet. Every node is a full server. Every identity is cryptographic. No central authority required. And the quiet, invisible piece that holds it all together — the one that makes the whole thing feel like magic to the end user — is a few kilobytes of JavaScript cached in your browser, waiting patiently for the moment it's needed.