feat: Route DM gift wraps to recipient's inbox relays (NIP-17 kind 10050)

[alltheseas]

Summary

Closes #43

• Add inbox_relays module that fetches, caches (1h TTL / 60s on error), and publishes kind 10050 relay lists
• Route DM gift_wrap_to() to recipient's preferred inbox relays with automatic fallback to pool broadcast on failure
• Publish own kind 10050 on connect, advertising read-capable relays as DM inboxes
• Republish 10050 (debounced, 800ms) on every relay config change (add/remove/toggle/mode)
• Exclude write-only relays from 10050; publish empty event to clear stale lists when no readable relays exist

Changed files

File	Change
inbox_relays.rs	New — fetch, cache, publish, send helper + 9 unit tests
lib.rs	Register mod inbox_relays
message/sending.rs	DM send → inbox_relays::send_gift_wrap
message/mod.rs	Reaction & edit sends → inbox_relays::send_gift_wrap
pivx.rs	Payment & QR sends → inbox_relays::send_gift_wrap
commands/relays.rs	Publish 10050 on connect; republish on config changes

Test plan

• cargo check — no new warnings
• 9 unit tests pass (tag parsing, cache TTL/error, debounce coalescing)
• Manual: send DM to user with kind 10050 published — verify gift wrap routed to their inbox relays
• Manual: send DM to user without kind 10050 — verify fallback to pool broadcast
• Manual: change relay config — verify 10050 republished with updated relay list

🤖 Generated with Claude Code

[YuurinBee]

Thanks for taking the time to work and submit this PR! @JSKitty will review it in detail tomorrow.

[JSKitty]

Great work on this one! Kind 10050 is an excellent improvement to DM delivery for cross-Nostr-client compatibility. Absolutely welcome this PR.

I've manually tested all three unticked items from your test plan:

• Send DM to user with kind 10050 published — verified gift wrap routed to their inbox relays ✓
• Send DM to user without kind 10050 — verified fallback to pool broadcast ✓
• Change relay config — verified 10050 republished with updated relay list ✓

Tested between Vector and 0xChat, and confirmed by watching relays directly for kind 10050 events. All working correctly.

One improvement I'd like to see before merge — there's a cache stampede ("thundering herd") issue in get_or_fetch_inbox_relays. If a user sends multiple messages rapidly to the same recipient with a cold cache (think meme-spamming or rage-typing), each message independently fetches the same 10050 from relays in parallel. This wastes bandwidth and puts unnecessary pressure on relays.

Here's an explanation from my Claude on the why and how, with suggestions:

---

Thundering Herd Fix — Per-Key Fetch Serialization

The problem: get_or_fetch_inbox_relays drops the cache lock before starting the network fetch. During the ~5 second fetch window, every concurrent DM send to the same recipient sees a cache miss and spawns its own duplicate fetch. With N rapid messages, you get N identical relay queries.

Falling back to pool broadcast during the fetch window isn't ideal either — it defeats the purpose of inbox relay routing for those messages.

The fix: Double-checked locking with a per-key tokio::sync::Mutex. Cache hits remain lock-free (fast path unchanged), but cache misses for the same pubkey serialize through a per-key lock. The second caller waits for the first fetch to complete, then hits the cache on the double-check.

Scoped entirely to inbox_relays.rs — one new static, ~15 line refactor of get_or_fetch_inbox_relays, no signature changes, no new dependencies.

static FETCH_LOCKS: Lazy<std::sync::Mutex<HashMap<PublicKey, Arc<tokio::sync::Mutex<()>>>>> =
    Lazy::new(|| std::sync::Mutex::new(HashMap::new()));

async fn get_or_fetch_inbox_relays(client: &Client, pubkey: &PublicKey) -> Vec<String> {
    // Fast path: cache hit (no per-key lock needed)
    {
        let cache = INBOX_RELAY_CACHE.lock().unwrap();
        if let Some(entry) = cache.get(pubkey) {
            let ttl = if entry.fetch_ok { CACHE_TTL_SECS } else { CACHE_TTL_ERROR_SECS };
            if entry.fetched_at.elapsed().as_secs() < ttl {
                return entry.relays.clone();
            }
        }
    }

    // Per-key lock — serializes fetches for the same pubkey only
    let key_lock = {
        let mut locks = FETCH_LOCKS.lock().unwrap();
        locks.entry(*pubkey).or_default().clone()
    };
    let _guard = key_lock.lock().await;

    // Double-check: another task may have filled the cache while we waited
    {
        let cache = INBOX_RELAY_CACHE.lock().unwrap();
        if let Some(entry) = cache.get(pubkey) {
            let ttl = if entry.fetch_ok { CACHE_TTL_SECS } else { CACHE_TTL_ERROR_SECS };
            if entry.fetched_at.elapsed().as_secs() < ttl {
                return entry.relays.clone();
            }
        }
    }

    // We won the race — do the actual fetch
    let result = fetch_inbox_relays(client, pubkey).await;

    {
        let mut cache = INBOX_RELAY_CACHE.lock().unwrap();
        cache.insert(
            *pubkey,
            CachedRelays {
                relays: result.relays.clone(),
                fetched_at: Instant::now(),
                fetch_ok: result.fetch_ok,
            },
        );
    }

    result.relays
}

Behavior during a 10-message spam burst:

1. Message 1: cache miss → acquires per-key lock → starts fetch
2. Messages 2–10: cache miss → .lock().await on the same key (non-blocking for other pubkeys)
3. Fetch completes → result cached → lock released
4. Messages 2–10 wake up → double-check cache → hit → all use the real relay list

No duplicate fetches, no pool broadcast fallback, different pubkeys never block each other.

[alltheseas]

ccc13e2 👀

[JSKitty]

tACK ccc13e2

Massively appreciate this feature being added to Vector, a step closer to true Nostr portability. 🤟

I will include you in our release notes credits! 💚