Summary
Damus iOS does not deliver published notes to tagged users' NIP-65 read (inbox) relays. Events are only sent to the author's own configured relays. If a tagged user is not on any of those relays, they never see the note.
Real-world report
verbiricha reported that a note mentioning him was not delivered to his inbox relays:
"i read this by pure chance since it wasn't delivered to my inbox relays btw."
The note (event 033d898e9cbf982a8fd1346zu7wl0j0nxnsed0ptyzmc5fac4hju9t44) was only published to wss://relay.damus.io and wss://relay.primal.net — the author's own relays — and never to verbiricha's declared read relays from his kind:10002 list.
NIP-65 requirement
NIP-65 specifies that when publishing an event, clients SHOULD:
- Send the event to the write relays of the author
- Send the event to all read relays of each tagged user
- Send the author's
kind:10002 event to all relays the event was published to
Damus currently does (1) but does NOT do (2) or (3).
Current state in codebase
NostrNetworkManager.swift line 213 has an acknowledged TODO:
// TODO(tyiu) Ideally this list would be sorted by the event author's outbox relay preferences
// and reliability of relays to maximize chances of others finding this event.
NostrNetworkManager.send(event:) sends events to relaysForEvent() which returns only the user's own configured relays. There is no resolution of tagged users' kind:10002 read relays.
The infrastructure to fix this largely exists:
NIP65.swift — full kind:10002 parsing with RelayList, RelayItem, and RWConfiguration (read/write/readWrite)RelayPool.swift — ephemeral relay management with acquireEphemeralRelays() and lease trackingPostBox.swift — retry with backoff, per-relay tracking
What's missing is the routing logic: resolving each p-tagged pubkey's kind:10002 read relays and sending the event there.
Proposed fix
When send(event:) is called for an event with p-tags:
- Extract p-tagged pubkeys from the event
- For each pubkey, query NostrDB for their kind:10002 event
- Collect their read relays (these are their inbox relays)
- Send the event to those relays (in addition to the author's own write relays)
- Republish the author's kind:10002 to all target relays (per NIP-65 spec)
- Cap total fanout to prevent abuse (e.g., max 6 inbox relays per publish)
Related
Summary
Damus iOS does not deliver published notes to tagged users' NIP-65 read (inbox) relays. Events are only sent to the author's own configured relays. If a tagged user is not on any of those relays, they never see the note.
Real-world report
verbiricha reported that a note mentioning him was not delivered to his inbox relays:
The note (event
033d898e9cbf982a8fd1346zu7wl0j0nxnsed0ptyzmc5fac4hju9t44) was only published towss://relay.damus.ioandwss://relay.primal.net— the author's own relays — and never to verbiricha's declared read relays from his kind:10002 list.NIP-65 requirement
NIP-65 specifies that when publishing an event, clients SHOULD:
kind:10002event to all relays the event was published toDamus currently does (1) but does NOT do (2) or (3).
Current state in codebase
NostrNetworkManager.swiftline 213 has an acknowledged TODO:NostrNetworkManager.send(event:)sends events torelaysForEvent()which returns only the user's own configured relays. There is no resolution of tagged users' kind:10002 read relays.The infrastructure to fix this largely exists:
NIP65.swift— full kind:10002 parsing withRelayList,RelayItem, andRWConfiguration(read/write/readWrite)RelayPool.swift— ephemeral relay management withacquireEphemeralRelays()and lease trackingPostBox.swift— retry with backoff, per-relay trackingWhat's missing is the routing logic: resolving each p-tagged pubkey's kind:10002 read relays and sending the event there.
Proposed fix
When
send(event:)is called for an event with p-tags:Related