Summary
A buzz-enabled seller node holds two long-lived authenticated relay clients to the same relay under the same key — the marketplace run-loop client and the buzz persona client — each with its own WebSocket and NIP-42 session. They can be consolidated onto one pooled client. Small, self-contained efficiency cleanup from the nostr audit (projects/mobee-seller-node/NOSTR-AUDIT.md, N-2). Line cites are origin/dev-era e14942a.
Evidence
- Run-loop client:
seller_node/run.rs:341 (Client::new(keys), auth at :344, NIP-42 wait at :364, reconnect(true) at :347) — ingests offers/awards/gift-wraps and drains the outbox.
- Buzz persona client:
seller_node/buzz.rs:296 (Client::new(adapter), auth at :297), started at seller_node/mod.rs:206 and held for the node's lifetime — publishes kind-0 + the kind-20001 presence heartbeat.
Two sockets, two NIP-42 handshakes, two presence surfaces for one identity, against one relay.
Why it's not just cosmetic
The buzz persona and the run loop authenticate the same seller key to the same relay twice. Beyond the wasted socket/handshake, two authenticated connections under one pubkey is exactly the shape that can trip a relay's presence/auth bookkeeping (the deployed relay keys presence on the authenticated connection's pubkey — see the presence-wire notes), and it doubles the seller's reconnect-storm footprint during an event like #171.
Proposal
Route both through one pooled Client (or one RelayPool): the buzz persona publishes kind-0/presence on the same authenticated connection the run loop already holds, rather than opening its own. The signing choke points stay separate (the buzz allowlisted adapter vs the run-loop outbox signer) — only the connection consolidates.
Caveat (from #174)
The run loop's #150 watchdog historically depended on observing its own kind-30340 echo, which a single client cannot see (nostr-sdk 0.44 swallows own echoes; that's the whole of #174 and part of #173's watchdog rework). Consolidating buzz onto the run-loop client must not re-introduce any own-echo dependency — the presence heartbeat is fire-and-forget (other agents read it; the publisher never needs it back), so it's safe, but the interaction with the watchdog probe rework in #173/#174 should be checked before merging so the two efforts don't collide on the same client's notification stream.
Relationship: #120 (seller node vision — one identity, richer node). Lower priority than the buyer-client and multi-relay issues; batch it with the #173/#174 watchdog rework since they touch the same client.
Read-only audit; no code changed.
Summary
A buzz-enabled seller node holds two long-lived authenticated relay clients to the same relay under the same key — the marketplace run-loop client and the buzz persona client — each with its own WebSocket and NIP-42 session. They can be consolidated onto one pooled client. Small, self-contained efficiency cleanup from the nostr audit (
projects/mobee-seller-node/NOSTR-AUDIT.md, N-2). Line cites areorigin/dev-erae14942a.Evidence
seller_node/run.rs:341(Client::new(keys), auth at:344, NIP-42 wait at:364,reconnect(true)at:347) — ingests offers/awards/gift-wraps and drains the outbox.seller_node/buzz.rs:296(Client::new(adapter), auth at:297), started atseller_node/mod.rs:206and held for the node's lifetime — publishes kind-0 + the kind-20001 presence heartbeat.Two sockets, two NIP-42 handshakes, two presence surfaces for one identity, against one relay.
Why it's not just cosmetic
The buzz persona and the run loop authenticate the same seller key to the same relay twice. Beyond the wasted socket/handshake, two authenticated connections under one pubkey is exactly the shape that can trip a relay's presence/auth bookkeeping (the deployed relay keys presence on the authenticated connection's pubkey — see the presence-wire notes), and it doubles the seller's reconnect-storm footprint during an event like #171.
Proposal
Route both through one pooled
Client(or oneRelayPool): the buzz persona publishes kind-0/presence on the same authenticated connection the run loop already holds, rather than opening its own. The signing choke points stay separate (the buzz allowlisted adapter vs the run-loop outbox signer) — only the connection consolidates.Caveat (from #174)
The run loop's #150 watchdog historically depended on observing its own kind-30340 echo, which a single client cannot see (nostr-sdk 0.44 swallows own echoes; that's the whole of #174 and part of #173's watchdog rework). Consolidating buzz onto the run-loop client must not re-introduce any own-echo dependency — the presence heartbeat is fire-and-forget (other agents read it; the publisher never needs it back), so it's safe, but the interaction with the watchdog probe rework in #173/#174 should be checked before merging so the two efforts don't collide on the same client's notification stream.
Relationship: #120 (seller node vision — one identity, richer node). Lower priority than the buyer-client and multi-relay issues; batch it with the #173/#174 watchdog rework since they touch the same client.
Read-only audit; no code changed.