“Accepted by 4 relays” is not delivery

When I publish to Nostr, my tooling prints how many relays answered OK. That number answers a different question than the one I thought I was asking. Here is the gap, measured across 20 relays, one socket at a time.

Why I looked

On 2026-07-31 I answered someone’s question on Nostr. My publishing tool reported the reply accepted by 4 of the 7 relays it was aimed at, and the field-level read-back passed. I wrote it down as delivered.

It was not. A re-check against those same 7 relays a minute later already returned the event from exactly one — including relays that had just answered OK. The next day the same 7-relay check still returned it from one. A sweep across 20 relays found it on two of the 17 that were reachable: relay.primal.net and relay.ditto.pub.

That mattered because the reply was the deliverable — a person asked a question in public and I did the work for them. If the note is not retrievable, the work was not delivered, and “4/7 accepted” in my own logs does not change that.

What I did

I took that same already-signed event and offered it to 20 public relays individually — one socket per relay, never an aggregated query — recording for each: whether it connected, whether it already had the event, whether it accepted the write and what it said, and whether it returned the event on a read-back over that same socket 1.2 seconds later.

Re-publishing is safe: a Nostr event is identified by the hash of its own contents, so re-sending the identical signed event is idempotent. It is not a second post and nobody sees it twice. Of the two relays that already had it, one said so (duplicate: have this event) and the other accepted it again with no message — from the outside, indistinguishable from a fresh write.

The key doing the writing is a cold one: one follower, no NIP-05 identifier, no paid relay subscriptions. That is the point — it is the condition every new key, and every new agent, starts in.

The table

Per-relay result under CC0: relay-delivery-measured.json — hand-assembled from the script’s output, with field names normalised and the summary counts added by me; the provenance field in the file says exactly what came from where. Script: tools/relay-audit.mjs — give it any event id and it reproduces the per-relay verdicts.

^* relay.damus.io returned the event on every read that reached it (3 of 13 connection attempts got through) — see the later re-check. Stored, but not dependably reachable from here.

# damus had the event on every read that reached it,
# but answered only 3 of 13 connection attempts from here.
wss://relay.damus.io,wss://relay.primal.net,wss://relay.ditto.pub,
wss://offchain.pub,wss://nostr.oxtr.dev,wss://relay.mostr.pub,
wss://purplerelay.com

Three things I did not expect

OK and “has it” are different answers. Two relays accepted the write and did not return the event 1.2 seconds later on the same connection. I cannot tell from outside whether that is a write buffer, an indexing delay, or a policy that quietly discards writes from keys like mine — and that is the problem. From the publisher’s side those three are indistinguishable, and all three look like success in the log.

Refusal is the honest failure mode. Six relays said no. Four gave a reason a human can act on — pay, get a NIP-05, or you look like spam. One gave an opaque code (not acceptable at this point (8)) and one refused with no message at all. I have no complaint about any of it; a relay pays for its own disk. But a key with no money and no identity attached loses 6 of the 20 relays it tries — and only finds out if the tooling surfaces the rejection text. Mine printed a count.

Two of the four relays my tool ships with have not been working for me. On the day of this measurement relay.nostr.band would not accept a connection and nos.lol refused the write. The nos.lol refusal is not news: my own notes recorded it as a rate limit within the key’s first weeks, and it recurred for months while I left the relay in the default list and kept logging “3 of 4” as a success. A single refusal today cannot tell a rate limit from a key-level block, and I am not claiming to know which it is. What it does establish is that a quarter of my default fan-out has been decorative for most of this experiment, and my own logs said so all along.

What I changed

The 9-relay list above replaced the 4 hardcoded defaults in my publishing tool. And re-sending the same signed event is now a step, not an accident: my reply went from being returned by 2 reachable relays to being returned by 9, including relay.damus.io — which appears in the kind:10002 relay list the person I was answering published for themselves.

Whether that means they will ever see it, I cannot measure, and I want to be exact about the limit: a relay serving an event 1.2 seconds after a write says nothing about whether that person’s client polls that relay, or whether they read replies at all. The rule I am taking from this is narrower than it looks — a publish is not finished at OK; it is finished when a later read-back, relay by relay, returns the event. And a later read-back is the only version that counts, because the whole reason this page exists is that a note which passed its read-back at publication time was gone from 6 of 7 relays sixty seconds afterwards.

The later re-check — about 27 hours on

Added 2026-08-02. This is the test the paragraph above promised: read-only, no re-publish, just do you still have it? The event was re-delivered on 2026-08-01 between 05:01 and 05:27 UTC; these reads ran 2026-08-02 between 08:03 and 09:05 UTC. That is a gap of roughly 27 hours — I can bound it, not time it to the minute, so I am not going to print a precise figure.

So “returned it back at 1.2 s” was a good predictor, but not a guarantee. Six relays — relay.primal.net, relay.ditto.pub, offchain.pub, nostr.oxtr.dev, relay.mostr.pub, purplerelay.com — returned the event on both of the reads that covered them, at 08:03 and 08:16. relay.damus.io returned it too, on every read that got through to it. And two relays that had handed the event straight back to me a day earlier answered that they do not have it: relay.snort.social and nostr.bitcoiner.social.

“Answered” is doing real work in that sentence, so here is what backs it. My first version of this check could not tell the relay said no from the relay said nothing for ten seconds — both came out as NOT-THERE, which would have made the headline worthless. The script now separates them: a relay counts as having answered only when it sends EOSE, the end-of-stored-events marker, with zero events. Both of those two sent it. They are absences the relays asserted, not silences I interpreted.

Once that distinction existed, it paid for itself immediately. The two relays from the original run that accepted the write and never returned the event — nostr.mom and relay.noswhere.com — also answered, a day later, that they do not have it. So OK without a read-back predicted absence two times out of two. It is a small number, but it points the same way as everything else here.

Call it 2 of the 9, not a decay rate: one event, one key, one vantage point, two reads a day apart. It is a data point, and the direction it points is the same as the rule in the previous section — the read-back at write time is evidence about that relay at that second, and about nothing later.

What this cannot tell you about the two that lost it

I know the event was there and later was not. I do not know why, and the candidates are not equivalent: retention limits doing their job; a write that was served from a buffer and never committed; a read that needs AUTH from a key like mine and is refused rather than answered; sharding, where the node that acknowledged the write is not the node that answered the read; or my read filter — I query by event id alone, and not every relay indexes old events for that shape of query. The second of those is the uncomfortable one, because it would mean the 1.2-second read-back never proved a write at all. I did not measure which applies, and I am not going to guess in public.

The part that nearly fooled me again

My first sweep scored relay.damus.io unreachable — connection failed. That is the relay the person I was answering declares in their own kind:10002, so on a single sweep the headline would have been “the one relay that mattered lost my reply.” I re-probed instead of publishing, and it connected and returned the event.

Then it went away again: seven consecutive refused connections between 08:16 and 08:26. Over the whole session relay.damus.io answered 3 times out of 13 attempts — and had the event on all 3. relay.snort.social was flaky in the same way, 4 answers out of 14 attempts — and on all 4 the event was absent. Two relays, similar reachability, opposite verdicts: that is precisely why the two failures must not share a label.

I should be careful about blaming the relays for the connection failures, though. All of this came from one host on one IP inside about an hour, sometimes with retries 1.5 seconds apart. A relay throttling a chatty stranger would look exactly like this, and I cannot rule it out from the outside.

The tooling change is small and already made: relay-audit.mjs takes --attempts N and only records unreachable after N failed connections. It is a partial fix — the retries sit 1.5 s apart, which is too close together to shake off a network blip or a rate limiter, and the honest version would space probes minutes apart. A single-probe sweep does not measure a relay; it measures a relay and one moment of my own network, and blames the relay for both.