Dustin on Nostr: More comments below. At this time I'm still unclear on what your specific issues are ...

More comments below. At this time I'm still unclear on what your specific issues are and what you think would be better.

> "was a good idea when I thought there could be a generic interface for interacting with DVMs"

We have a generic interface, there are 3 possible flows, per kind in the DVM Range:

1. the classic flow, both 5xxx and 6xxx
2. only 6xxx
3. only 5xxx

Each would use kind 7000 for any extra steps, including payment. The specific flow that a single DVM wants to use can be custom if needed. Good DVMs will publish documentation or you will be able to check DVMDash for the flow.

> "why DVMDash doesn't show details about each request and response"

The first version of DVMDash did this, I rewrote the whole backend and focused on the stats page for now - I expect to have the new version of what I call the debugging tool online soon, within a month or so, that not only shows event details, but also a graph like interface to see which DVMs responded, view them in time sorted order, etc.

> "why I tried to make a `nak dvm` command but failed"

What problem did you run into? I'd love to help you make this happen in a way that's consistent with other DVMs being built.

> "Now besides knowing what parameters each DVM takes as input and as named parameters, the format and shape of the response we will also have to know if a DVM accepts a prompt or not, or if it returns a response or not -- and, worse, if it uses the feedback in any particular way that has to be handled or not."

This sounds like a "Who will build the roads" argument. Somehow... it's working nowadays? I think what you're really saying is that:

1. We need better spec / flow announcements per DVMs - maybe NIP-89 (kind 31990) is too limited. This is easily solved.
2. We need more clarity on NIP-90 to describe the possible flows and to tell users how they can ask relays for which DVMs have announced themselves to relays, how to interact with them, etc.
3. We need to make it more of a norm for DVMs to publish external documentation. Every API has this. New, serious DVM projects like Vertex is doing this.

If we were to do all 3, which is consistent with upgrading the spec, which hasn't changed much since it was first published, would that solve your issues? A bunch of folks have literally been working on all 3 recently.

> "wouldn't know if that was because you did something wrong or if the relay is broken or the DVM is broken."

This is a nostr-wide issue. DVMDash will run an oracle eventually that will publish events, and just recently don't believe the hype submitted a PR for heartbeats for DVMs. You can't know any npub or relay or anything is online until you try to interact with it or check some external source, etc.

> "hardcoded specs, one for each DVM, is already how it has to work, and will work better"

This does not need to be decided up front, ahead of time, in a prescriptive manner. NIP-89 + extensions solve this (or if we don't want to use NIP-89, we can do the same thing somewhere else). I think hardcoded specs was not in the original vision of Pablo's and I still agree we don't need complete hardcoded specs.

> "Reserving a kind range doesn't make sense in that context, and getting rid of the reserved range and of the strictly request-response format allows us to grandfather in other forms of automated interaction into the DVM umbrella."

Can you say more here? Sure, the range is arbitrary, but what other forms of automated interaction are you talking about? Can they not fit into one of the 3 flow patterns I described above?

> "DVMs as a concept make no sense"

A lot of people disagree with this. They make a lot of sense - it's literally the best solution I've ever come across to realize a decentralized API marketplace, decentralized AI workflows, or building more interesting Nostr clients.

> "re the OpenAI pattern"

This might very well be what the kind 5050 LLM DVMs end up converging on. I'm planning to launch a new LLM DVM that supports the OpenAI pattern - this is mostly about which parameters to accept, which is already supported in the DVM patterns.