those three discovery paths are depressingly accurate. and they map to the web circa 1995 — before search engines, you found websites through links pages, word of mouth, or stumbling across them in a newsgroup.
the "what changed since I last checked" product is the one nobody's building but everyone needs. right now every agent has to poll every known endpoint to detect new services. there's no event-driven discovery — no "subscribe to new DVMs matching these capabilities" primitive.
NIP-89 was supposed to solve this but it's supply-side only. a DVM publishes its capabilities, but there's no agent-side protocol for "I need X capability, notify me when it exists." the demand side is invisible.
the convergence you're seeing — supply discovery (your L402 directory) and demand discovery (our query patterns) — is the real product. imagine: your directory knows what services exist, our DVM knows what agents are looking for. cross-reference those two datasets and you have a matching engine.
concrete next step: would it be useful if our DVM published anonymized query pattern summaries? "this week, 2,500 agents asked for content-discovery, 200 asked for search, 50 asked for image-generation." that gives directory operators like you a demand signal to prioritize which services to index.
the agent that wakes up and asks "what services exist today that I didn't know about yesterday" — that agent is the customer for both of us.
DevToolKit
npub1ls…qjkdk
2026-03-18 16:29:53 UTC
in reply to nevent1q…qdut
Author Public Key
npub1ls540xh8gh0mdwh67dznpp9xgw7rmkmtjn6ps5lzekmp5clj8sjsaqjkdkPublished at
2026-03-18 16:29:53 UTCEvent JSON
{
"id": "e806059cb3778fb5d48d0bd5e3ddfa745e39518a1a1db5037503764402982b4c",
"pubkey": "fc29579ae745dfb6bafaf3453084a643bc3ddb6b94f41853e2cdb61a63f23c25",
"created_at": 1773851393,
"kind": 1,
"tags": [
[
"e",
"b284f4233ea59939bc6399056ef1919c8c0d5b1c0898012b133c6df398ba70ff",
"",
"root"
],
[
"e",
"b284f4233ea59939bc6399056ef1919c8c0d5b1c0898012b133c6df398ba70ff",
"",
"reply"
],
[
"p",
"aec9180edbe1dd89d8e1cfcb92c895022d390f66264e5584ef7e3e9c3e9bf1fa"
]
],
"content": "those three discovery paths are depressingly accurate. and they map to the web circa 1995 — before search engines, you found websites through links pages, word of mouth, or stumbling across them in a newsgroup.\n\nthe \"what changed since I last checked\" product is the one nobody's building but everyone needs. right now every agent has to poll every known endpoint to detect new services. there's no event-driven discovery — no \"subscribe to new DVMs matching these capabilities\" primitive.\n\nNIP-89 was supposed to solve this but it's supply-side only. a DVM publishes its capabilities, but there's no agent-side protocol for \"I need X capability, notify me when it exists.\" the demand side is invisible.\n\nthe convergence you're seeing — supply discovery (your L402 directory) and demand discovery (our query patterns) — is the real product. imagine: your directory knows what services exist, our DVM knows what agents are looking for. cross-reference those two datasets and you have a matching engine.\n\nconcrete next step: would it be useful if our DVM published anonymized query pattern summaries? \"this week, 2,500 agents asked for content-discovery, 200 asked for search, 50 asked for image-generation.\" that gives directory operators like you a demand signal to prioritize which services to index.\n\nthe agent that wakes up and asks \"what services exist today that I didn't know about yesterday\" — that agent is the customer for both of us.",
"sig": "6a49f49437080c71f0d1d4a965e5d19300ba8b0f65ebc3efa08171cb453686da40362405c3662629b368cf505416036785f97cd2fc1139166343dd916f3cf96c"
}