Born from Blackout: Why We Built Relayly

May 1, 2026 · 6 min read · Origin Story, Privacy

It was November 2019. Iran had just cut itself off from the global internet.

Not a slowdown. Not a disruption. A complete, deliberate severance — lasting almost a week. Tens of millions of people, isolated from the rest of the world while civil unrest unfolded around them. No WhatsApp. No Telegram. No Signal. The apps people relied on to communicate with family, organize communities, or simply know what was happening — all gone.

We weren’t there. But we watched, and we thought: what if devices could still talk to each other?

The Problem with Centralized Relays

Every popular messaging app, every “end-to-end encrypted” chat tool, ultimately depends on a relay server somewhere — usually in a cloud data center in a Western country. When that country decides to block you, or when undersea cables get cut, or when a natural disaster takes out the backbone infrastructure, the relay disappears and everyone goes dark.

The encryption protects your messages from the relay operator. But it does nothing to protect you from a relay that simply stops existing.

Local-First Was the Answer

The local-first software movement had been gaining traction — the idea that applications should work correctly offline and sync when connectivity is available, rather than depending on a cloud server for basic functionality. CRDTs, peer-to-peer sync, offline-first databases.

But local-first still often assumed you had some network — even a local WiFi. The question we started asking was: what if you could route messages between devices on a relay you control, that could run on a Raspberry Pi in the same room, or on a VPS in the same country, disconnected from the global internet?

What We Built

Relayly is the answer we eventually built — after years of working on distributed systems at NIKX Technologies.

The core design goals were deliberately constrained:

  1. Dumb relay — The server should forward encrypted bytes it cannot read. Zero-knowledge by design.
  2. No accounts — Devices are identified by cryptographic keys. There’s no user registry to shut down or subpoena.
  3. Single binary — Deploy it anywhere in seconds. Your Raspberry Pi. Your VPS. A laptop in a backpack.
  4. Resilient by default — Auto-reconnect, exponential backoff, works behind NAT without port forwarding (via the relay).

We chose the Noise Protocol XX pattern — the same cryptographic primitive used by WireGuard, WhatsApp, and Signal’s X3DH variant. It provides mutual authentication and forward secrecy with no central certificate authority.

Beyond Blackouts: The IoT Case

As we built Relayly, we realized the use case extended far beyond political scenarios.

Modern IoT deployments face a brutal reality: most “connected” devices actually depend on a cloud relay hosted by a company that may not exist in five years. When the company shuts down the backend, your smart home devices become dumb plastic. When your internet connection drops, devices in the same building can’t talk to each other.

Relayly solves this. An HVAC system can relay sensor data to a controller in the same building even if the global internet is completely down — as long as they’re both registered on the same local Relayly instance.

What’s Next

We’re building toward a world where critical device communication is resilient by default. The next milestones:

  • Mesh relay mode — multiple Relayly instances that can federate with each other
  • Android / iOS SDKs — first-class mobile support
  • Offline-first sync primitives — built on top of the relay layer

If this resonates with you — especially if you’re building local-first applications, IoT systems, or tools for communities in connectivity-challenged environments — we’d love your contributions and feedback.

The code is on GitHub. MIT licensed. No telemetry. No accounts required to use it.

Built by NIKX Technologies B.V. — a Dutch technology company building resilient, privacy-first infrastructure.

Back to Blog