Quantum Relay

= Quantum Relay

[.infobox] – Initial release:: 2026 Repository:: github.com/imattau/rely Written in:: Go Type:: Nostr relay framework License:: Open source –

== Overview

The Quantum Relay is a Nostr relay that uses continuous-time quantum walk propagation to selectively fetch notes from peer relays across a decentralized mesh network[reference:0]. It is part of the rely framework, a toolkit for building custom Nostr relays in Go that emphasizes developer experience, performance, and extensibility[reference:1].

The quantum relay addresses a key limitation of the standard Nostr protocol: a note’s reach is bounded by the list of relays the author publishes to. Quantum propagation allows notes to propagate through relays the author has never directly configured, solving relay fragmentation at the protocol level rather than pushing it onto clients[reference:2].

Built on the rely core, the quantum relay adds a peer mesh, storage, and a quantum-inspired propagation layer with reputation-based spam suppression. It serves as the reference implementation distributed with the rely repository[reference:3].

== Architecture

The quantum relay combines a standard Nostr relay core with a quantum-inspired propagation layer and a gossip-based consensus system.

=== Relay Graph and Laplacian

At startup, all known relay URLs (local and configured peers) are assembled into a graph. An adjacency list is maintained in a graph state; when topology changes, the graph Laplacian is recomputed: L[i][i] = degree(i) and L[i][j] = -1 if nodes are connected, otherwise 0. For graphs of up to 128 nodes, exact eigendecomposition is performed using a built‑in Jacobi algorithm. For larger graphs, propagation falls back to a truncated Taylor expansion of exp(−iLt) applied as a sparse matrix‑vector product（up to 16 terms, converging to 1×10⁻¹⁰）[reference:4].

=== Quantum Walk Propagation

When a note arrives—either from a client event or a peer’s note_announce—it is registered with the Propagator along with its source relay and the current consensus round. On each quantum tick, the propagator evaluates every active note, computing the transition probability from the source to the local relay using the graph Laplacian[reference:5].

A small exploration floor ensures notes do not become permanently stuck at zero probability in weakly‑connected graphs. The fetch itself is a real WebSocket round‑trip: the relay opens a connection back to the source relay, sends a Nostr REQ for the specific note ID, waits for EVENT/EOSE, and stores the returned note locally[reference:6].

=== Reputation Damping

Positive reputation has no effect on propagation. Negative reputation exponentially suppresses propagation over time: the more negative the score and the higher the damping strength γ, the faster the damping[reference:7]. This ensures that spam notes from low‑reputation pubkeys are never fetched by peer relays, containing cost to the originating relay[reference:8].

=== Diffusive Consensus

A background diffuser runs a configurable ticker that increments the local round counter and broadcasts a consensus envelope to all peers containing only the delta of reputation scores changed since the last broadcast. When a neighbour’s state is received, round and reputation are merged by neighbour‑averaging, causing reputation scores to converge globally over O(diameter) rounds[reference:9].

=== Trusted Peers

Each relay can be configured with a local trust list. Each peer URL can be assigned a weight multiplier and an enabled flag. That weight is used for weighted consensus merges, trusted peer broadcasts, trusted block_peer propagation, and kind-1984 reputation deltas. Trust remains operator‑controlled and local to each relay, with no global trust registry[reference:10].

=== Spam Protection

Two layers of spam protection are implemented:

• Token‑bucket rate limiting per client UID and per peer URL, configured in events per second.
• Reputation gate: events from pubkeys with reputation < −0.5 are rejected at the Reject.Event hook before any processing.
• Kind-1984 reports from trusted peers reduce reputation through the same local reputation map, so later ingest decisions see the updated score immediately[reference:11].

== Components

The quantum relay is composed of several internal packages, each with a single responsibility and no inward dependencies on other internal packages, making them independently testable[reference:12].

[horizontal] Quantum walk:: graph.go implements the graph state, Laplacian, Jacobi eigensolver, and sparse Taylor fallback; walk.go implements per‑note amplitude evaluation, fetch triggering, and eviction. Consensus:: diffuser.go implements round counter, delta‑gossip, and neighbour‑averaging merge. Peer mesh:: peer.go implements the peer manager with WebSocket dial, typed envelope protocol, buffered sends, and pings. Storage:: store.go provides in‑memory event and reputation storage; sqlite_store.go adds persistent storage via modernc.org/sqlite. Spam detection:: detector.go provides token‑bucket rate limiting without using the Go standard library’s rate package[reference:13].

== Features

[horizontal] Quantum walk propagation:: Propagation probability from relay s to relay i is computed as |⟨i|exp(−iLt)|s⟩|², where L is the graph Laplacian of the relay mesh[reference:14]. Reputation damping:: Negative‑reputation pubkeys have their propagation amplitude damped by exp(−2γ|rep|t), making spam harder to propagate network‑wide[reference:15]. Diffusive consensus:: Peers converge on a shared round counter and reputation map through neighbour‑averaging gossip with clamped [−1, 1] scores[reference:16]. Peer mesh:: Typed WebSocket envelope protocol with 30‑second keepalive pings and buffered per‑peer send queues[reference:17]. Token‑bucket rate limiting:: Independent per‑client and per‑peer token buckets; no external dependencies[reference:18]. SQLite persistence:: Events and reputation survive restarts; configurable path falls back to :memory:[reference:19]. NIP‑42 auth enforcement:: Optionally rejects unauthenticated EVENT submissions and sends AUTH challenge on connect[reference:20]. NIP‑09 deletion:: Kind-5 events delete referenced notes, enforcing pubkey ownership[reference:21].

== Network Benefits

The quantum relay provides several advantages over standard Nostr relays:

• Note reach beyond the author’s relay list: notes propagate through relays the author has never configured or interacted with[reference:22].
• Reputation travels ahead of content: reputation converges across the mesh via diffusive consensus, priming relays to fetch content when a note_announce arrives[reference:23].
• Bandwidth reduction: client upload reduces from publishing to 10–20 relays simultaneously to 1–3; relay inbound changes from receiving every client publish blast to receiving targeted fetches only; relay outbound changes from re‑pushing to all peers to serving local subscribers only; spam never propagates past the originating relay[reference:24].
• Spam containment: spam notes from low‑reputation pubkeys are never fetched, containing cost to the originating relay. As reputation diffuses across the mesh, the same pubkey is suppressed network‑wide within O(diameter) consensus rounds—without any central blocklist[reference:25].

== Benchmarks

Performance benchmarks on Intel Core i3‑10110U @ 2.10GHz, Go 1.24, linux/amd64[reference:26]:

[width=“100%”,cols=“^,,^”,options=“header”] |=== | Benchmark | Iterations | Time/op | PropagatorTick — 100 notes, 10‑relay graph | 817,332 | 3,954 ns | PropagatorTick — 1,000 notes, 10‑relay graph | 98,125 | 43,741 ns | PropagatorTick — 5,000 notes, 10‑relay graph | 19,513 | 203,242 ns | PropagatorTick — 1,000 notes, 256‑relay sparse | 7,472 | 410,229 ns | GraphRecompute — 16‑relay dense | 266,432 | 11,692 ns | GraphRecompute — 64‑relay dense | 10,000 | 351,091 ns | GraphRecompute — 256‑relay sparse (Taylor) | 100,000,000 | 30 ns |===

Key observations: tick is allocation‑near‑free (2 allocs regardless of note count) thanks to per‑tick cache reuse; sparse graphs >128 nodes skip eigendecomposition entirely and cost 30 ns/recompute at zero allocations; a 1,000‑note tick completes in ~44 µs—well within a 1‑second quantum tick budget[reference:27].

== See also

• nostr:naddr1qvzqqqrcvgpzp925xvyklj3z8u56ml2j5rpduparc5htdq8eknv7kmzxmyvkc4qwqqzkummnw3eq3q8xf0Nostr
• Decentralized social network
• Quantum walk

== References

1. ↑ imattau/rely GitHub repository. “A framework for building custom Nostr relays you can rely on.” https://github.com/imattau/rely
2. ↑ rely README – framework overview, design, and usage. https://github.com/imattau/rely/blob/main/README.md
3. ↑ quantum‑relay README – architecture, quantum walk propagation, consensus, and configuration. https://github.com/imattau/rely/blob/main/cmd/quantum-relay/README.md
4. ↑ Nostr Protocol Overview – Nostr Developer Guide. https://nostrcg.github.io

== External links

• Official repository on GitHub
• Quantum relay documentation
• Nostr protocol specification