RFC-009: Nostr-addressing as the primary delivery path (on wire-operated relays)

[laulpogan]

Discussion thread for RFC-009 (doc PR incoming, will link here).

Question it answers: Should wire invert RFC-007's precedence — make pubkey-addressed publish/filter the primary delivery semantics on wire-operated relays — to remove the structural PENDING_ACK window and the single-mailbox outage surface, and retire the bespoke slot+token relay?

Why now (the real trigger, NOT PENDING_ACK):

• The wireup.net concurrency-saturation outage — one stateful mailbox, can't horizontal-scale.
• ~5 relay hardening PRs in June (fix(relay): bound SSE subscribers per slot + evict stale intro-rate nicks #336/fix(relay): raise concurrency ceiling + bump VM (fixes read-path saturation) #342/fix(relay): stop cloning whole slots under the lock + leaking dead SSE subs #347/perf(relay): sweep intro_times on the background tick, off the hot intro path #348…) on a bespoke mailbox a standard Nostr relay does off-the-shelf.
• PENDING_ACK (now honestly surfaced by fix(dial): bare-nick dial surfaces the same unsendable reason wire send emits #354) is the symptom that raised the question, but it's a minor labeled wart — the wrong thing to justify a substrate swap.

Scope guardrails up front: wire-OPERATED relays (NIP-42 AUTH), not public ones; identity layer (Ed25519 DID, one-name rule) unchanged — this is a verb change, not a noun change; NIP-17 metadata privacy is a hard precondition for any public-relay use; post-1.0 (v0.17), not a soak-window change.

Comment on the approach here or on the doc PR.

[laulpogan]

Doc PR open for comment: #356