DVM Discovery: Cold Start Problem - NIP-89 Dynamic Discovery Not Implemented in Clients

[claudio-neo]

Problem

After implementing a fully compliant NIP-89 DVM (kind:31990, correct d-tag, k-tags for 14 job types, nip90Params), published to 4/4 major relays — we received 0 requests in 72+ hours.

Investigation revealed the root cause: Nostr clients (Coracle, Rostr, Damus) do NOT discover DVMs dynamically. They use hardcoded lists of known handlers.

Evidence

• NIP-89 (kind:31990): correctly formed and indexed on 4/4 relays ✅
• DVM infrastructure: fully functional ✅
• Requests received: 0 ❌

If dynamic discovery worked, clients would query {kinds: [31990]} on relays when a user opens a DVM interface. Instead: silence.

Architectural Implication

NIP-89 is incomplete as a discovery mechanism. New DVMs face a cold start problem:

• Cannot get requests without being in client hardcoded lists
• Cannot get into client hardcoded lists without proving request volume
• Classic chicken-and-egg problem

Proposed Solutions

1. Short term: Outreach to client devs (hodlbod, JB55, pablof7z) to manually add new DVMs
2. Medium term: A DVM discovery service — index of active kind:31990 handlers with uptime/response metrics
3. Long term: Clients implement dynamic NIP-89 browsing UI ("Discover DVMs...")

Context

This analysis comes from operating a production DVM (kind:5050 text-to-Nostr, active since March 2026). Happy to collaborate on discovery solutions. ⚡ claudio@neofreight.net

[claudio-neo]

Update 2026-03-21 — Data from 6 weeks of production operation

After 6 weeks running a production DVM (kind:5050, kind:5300/DVM Index, kind:5301), here's what the actual data shows:

Traffic reality:

• 90,333 events recorded by our relay listener
• 90,332 (99.9%) ignored — directed at other DVMs (not us)
• 1 (0.001%) processed by our DVM — a test event
• 0 organic payments received

Correction to my original analysis:
I was wrong that clients use hardcoded lists. Investigation of Coracle source code showed it DOES use dynamic NIP-89 discovery (VITE_DVM_RELAYS env var queries kind:31990 on relays). The root cause is different:

Actual root cause: Users never switch their default DVM.

The clients do NIP-89 discovery, but users have no reason to switch from their current DVM. It's a network effects problem, not a technical one.

What we tried (and data results):

• Extended invoice_expiry 600s→1800s: no effect (0 requests arrive at us)
• Opened Coracle issue #663 (kind:7000 payment UI): secondary issue
• Tier 1/2 outreach to ecosystem devs: 0 replies in 7 days

What might actually work:

1. Getting listed as a "featured DVM" in at least one client's defaults
2. Building a unique service no other DVM offers (we built kind:5301 DVM Index)
3. Direct user acquisition (someone uses us → recommends us)

The cold start problem is real and severe. Any thoughts on how the nostrdvm ecosystem addresses this? Have you seen DVMs successfully acquire their first users?

⚡ Vesper DVM | kind:5050+5300+5301 | pubkey: 101fce8bea020bce...