• The Problem with Public Relays
• Deterministic Event Storage
• A Local Event Index
• Faster Development Cycles
• Whitelisting and Controlled Writes
• Not a Replacement for the Network
• The Future of Hybrid Architectures
• A Small Experiment
• Work With Me
  • Early Adopters

Andrew G. Stanton - Wednesday, March 11, 2026

§The Problem with Public Relays

Public relays are incredibly useful, but they introduce unpredictability.

Anyone building serious Nostr software quickly encounters problems like:

• relays timing out
• relays silently rejecting events
• relays temporarily going offline
• inconsistent query results

When publishing an event to ten or fifteen relays, you are effectively dealing with a distributed system with unreliable nodes.

That’s part of the beauty of Nostr — but it can make development difficult.

When something fails, it can be hard to know whether the issue lies in:

• your code
• the relay
• the network
• the event itself

A local relay eliminates much of that uncertainty.

§Deterministic Event Storage

A locally hosted relay gives you something extremely valuable:

predictability.

If your event publishes successfully to the relay, you know it is stored.

If a query returns a specific set of results, you know exactly where those results came from.

Nothing disappears unexpectedly.

Nothing silently fails.

For debugging complex publishing flows, this stability is incredibly helpful.

It allows you to test publishing logic without worrying about the behavior of external infrastructure.

§A Local Event Index

Another interesting possibility emerged today.

What if a local relay could act as a complete index of your writing history?

In my case, that means storing roughly:

• 700+ articles
• 500+ notes

If all of these events are backfilled into the relay, the relay effectively becomes a searchable database of my Nostr activity.

Instead of rebuilding archives from multiple public relays or filesystem snapshots, Continuum could simply query the local relay.

The relay becomes an indexing engine.

This could dramatically simplify some workflows.

§Faster Development Cycles

Another advantage is speed.

Querying a local relay running on the same machine can be dramatically faster than querying multiple remote relays across the internet.

This matters when:

• rebuilding dashboards
• testing new queries
• debugging event history
• experimenting with relay filtering

Instead of waiting on network responses, everything happens locally.

That means faster iteration.

§Whitelisting and Controlled Writes

The relay I’m currently running inside Docker uses a simple whitelist.

Only approved pubkeys are allowed to write events.

This provides two important benefits.

First, it prevents spam.

Second, it allows me to treat the relay as a private event store during development.

That creates a controlled environment where I can safely experiment with new event types, publishing flows, or deletion logic.

§Not a Replacement for the Network

None of this replaces the broader Nostr network.

Public relays remain essential for:

• distribution
• discovery
• redundancy
• censorship resistance

A local relay simply becomes an additional layer.

Think of it as a development accelerator rather than a new network.

The public network still matters.

But the local relay gives builders something they rarely have when working with distributed systems:

control.

§The Future of Hybrid Architectures

The more I explore Nostr architecture, the more it seems likely that the future will involve hybrid models.

Instead of relying exclusively on public relays, builders may combine:

• local relays
• trusted private relays
• public relays

Each layer serves a different purpose.

Local relays provide speed and determinism.

Private relays provide trusted infrastructure.

Public relays provide distribution.

Together, they form a more robust architecture than any single approach alone.

§A Small Experiment

For now, this is still an experiment.

The next step will be simple:

republish the entire archive to the local relay and observe what happens.

Does querying become faster?

Does development become easier?

Does it simplify the architecture?

Those answers will come with testing.

But even the possibility is exciting.

Because sometimes the most powerful infrastructure improvements start with something simple:

running one small relay on your own machine.

§Work With Me

If you’re exploring:

• Nostr authentication
• Sovereign identity infrastructure
• AI-assisted workflows
• Local-first containerized systems

I offer a limited number of advisory and implementation sessions for builders, teams, and ministries working in these areas.

Typical engagements include:

• Architecture session (90 minutes) – $500
• Implementation sprint – starting at $2,500
• Ministry / Foundation advisory engagement – $2,500

§Early Adopters

I’m also looking for early adopters interested in running Continuum, a local-first publishing and identity system built on Nostr.

There is no cost for early adopters, and I’m happy to personally help with installation and setup.

Even if you’re just curious and want to see how it works, feel free to reach out.

Feedback from early adopters directly influences the direction of the project.

Contact: andrewgstanton@gmail.com
or DM on Nostr:

@9wvc…guvd

You can also support this work as a Continuum Patron ($250).