feat: relay list and profile metadata publishing (CEP-6)

[harsh04044]

Part of CEP-6 implementation. #76

Adds relay list (kind 10002) and profile metadata (kind 0) publishing, both called unconditionally on start with guards inside the methods.

New config fields:

• relay_list_urls - explicit relay URLs to advertise in kind 10002 (falls back to connected relay URLs when not set)
• bootstrap_relay_urls - extra publication targets merged with advertised URLs
• publish_relay_list - opt-out flag, defaults to true
• profile_metadata - opt-in, not published unless configured

Smart bootstrap detection: skips default bootstrap relays when all advertised URLs are local and no explicit bootstrap URLs were set. Explicit bootstrap_relay_urls are always used regardless.

14 new tests, 262 passing.

[ContextVM-org]

I noticed that get_discoverability_publish_relay_urls() is implemented and well-tested, but it never actually drives publication.

Both publish_relay_list() and publish_profile_metadata() call self.relay_pool.publish(builder) directly, which publishes to the transport's connected relays only. The same happens in spawn_publish_discoverability(). The merged advertised-plus-bootstrap URL set that get_discoverability_publish_relay_urls() computes is never passed down to the publish call.

In the TS SDK, publishDiscoverabilityEvent() explicitly uses getDiscoverabilityPublishRelayUrls() to decide where to send the event, falling back to the generic publish path only when that set is empty or contains non-websocket targets. Because of this, the bootstrap_relay_urls config currently has no effect on where kind 0 and kind 10002 events are sent in the Rust implementation.

The #[allow(dead_code)] annotation on get_discoverability_publish_relay_urls() is a tell: the helper is isolated from the actual side-effecting path.

I think this needs a targeted-publish capability on RelayPoolTrait (or an equivalent mechanism) so the startup discoverability flow can honor the merged relay set. Until then, the bootstrap relay feature is effectively unconnected.

[harsh04044]

I noticed that get_discoverability_publish_relay_urls() is implemented and well-tested, but it never actually drives publication.

Both publish_relay_list() and publish_profile_metadata() call self.relay_pool.publish(builder) directly, which publishes to the transport's connected relays only. The same happens in spawn_publish_discoverability(). The merged advertised-plus-bootstrap URL set that get_discoverability_publish_relay_urls() computes is never passed down to the publish call.

In the TS SDK, publishDiscoverabilityEvent() explicitly uses getDiscoverabilityPublishRelayUrls() to decide where to send the event, falling back to the generic publish path only when that set is empty or contains non-websocket targets. Because of this, the bootstrap_relay_urls config currently has no effect on where kind 0 and kind 10002 events are sent in the Rust implementation.

The #[allow(dead_code)] annotation on get_discoverability_publish_relay_urls() is a tell: the helper is isolated from the actual side-effecting path.

I think this needs a targeted-publish capability on RelayPoolTrait (or an equivalent mechanism) so the startup discoverability flow can honor the merged relay set. Until then, the bootstrap relay feature is effectively unconnected.

fixed - added publish_to(&urls, builder) to RelayPoolTrait backed by nostr-sdk's send_event_builder_to(). both publish_relay_list() and publish_profile_metadata() now route through publish_to_discoverability_relays() which passes the merged relay set to publish_to(). removed all three #[allow(dead_code)] annotations. bootstrap_relay_urls now actually drives where kind 0 and kind 10002 events are sent.