A lot of great questions here - I'll do my best to respond to as many as I can now and share my perspective about how I think about the DVM ecosystem: The primary benefit of DVMs is to be a better, more permission-less alternative to APIs that we use today. Once you, as a user, have an npub and some sats, you can start to interact with ANY DVM - this already is way better than API services which require custom login, setup, personal details, fiat banking, etc. per each service. Additionally, because of the way DVM kinds are setup, you can post a job to a kind and then pick from any DVMs that respond - this provides free market dynamics and competition, along with redundancy, etc. The competition aspect hasn't really been realized in practice quite yet (except for a period of time when AI Image Generators experienced this, kind 5100). > "There is no point in having a spec that is just a suggestion. " Aren't all specs suggestions? Kidding. Really though, myself and many others have been feeling this way and have been discussing improvements. It's pretty clear to me that kinds 5xxx are for job requests/ inputs by consumers of a service, kinds 6xxx are for job results / outputs, and kind 7000 is for intermediate communication. I think this kind numbering works really well. We should remove the requirement for a DVM to respond to 5xxx like in the case of a weather data DVM that only would publish kind 6xxx events. We could also remove the requirements for a 6xxx event, which I can imagine might happen when a DVM responds to a user in an alternative fashion, like a DM, email, text, a special websocket connection, etc. BTW we are going to run out of kinds as 5000-6999 fill up, so we should go ahead and reserve kinds 50000-69999 and 500000-699999. > "Deleting everything was meant as a first step only." thanks for explaining, I didn't know this. > "would you say [@ots_nbot](

Primal

Live Free

qualifies as a DVM or not? Shouldn't that kind of thing also be considered a DVM?" I'd say it can qualify as a DVM if there's a need for structured input (json) requests to the bot. More generally, we shouldn't be concerned with whether something is a bot or not (as time goes on, this becomes more pointless to try to solve). We should be more concerned with the nature of the interaction. If you're going to be communicating with something via natural language all the time (and maybe images) you could run the service as a regular npub, using kind:1 events. If instead the communication is structured json with parameters, it makes sense to use a different kind so as to not pollute the kind:1 space. > "If multiple people are running bots that behave similarly -- or if we expect that to happen -- it's time to standardize their behavior, otherwise there is no point. " I disagree that the emphasis should be on whether something is a bot. It should be more based on the kind of interaction (structured data vs natural language). > "It would be nice if bots publishing weather data could be standardized as DVMs," I completely agree. I'd say this is fine to do now, someone just needs to pick an unused kind in the 6xxx range and start broadcasting those events. > "It's hard for me to imagine that the feed-generator DVMs wouldn't be better as HTTP services rather than Nostr event publishers, or the Vertex DVM (which, by the way, is not listed in the official DVM specs, do not follow them strictly and is being used as an HTTP service even by their own website" Maybe. The interaction could always start via DVMs and then move to HTTP, websockets, etc. But then you have to use a different auth, and maybe other tradeoffs. You expose your IP, etc. For something like a streaming use case it's probably worth it. The more services that can run as DVMs could lead to more inter-operatibility and DVM chaining, in a more seamless fashion than trying to use multiple APIs, so I'd like to see more DVM services running and operating at the Nostr level. DVMs, as they are today, can be BOTH posting profile:0 data about itself, posting kind:1 events to Nostr, and also doing specialized work via kinds 5000-5999. Fun idea - humans could decide to earn some sats by announcing they want to do some work on a particular type of job type in the same way (hasn't happened quite yet, I believe).

I agree about calling things bots, it was poorly worded. I guess we could say that a bot can be a person and a person can be a bot, just like Bluesky labelers can also be either bots or humans. I think I was just trying to convey a different concept of bot, which is that of a profile that can be interact with in a programmatic way, so it "looks like a bot", doesn't matter if there is a human inside the box. I think you can understand and agree with this because DVMDash uses a robot icon for its list of DVMs tab, too.

It looks like you mostly agree with me, except you want to reserve the kinds. Reserving the kinds, at least to me, was a good idea when I thought there could be a generic interface for interacting with DVMs --and that's why I tried to make a `nak dvm` command but failed, and that may also be why DVMDash doesn't show details about each request and response, only statistics: because they're not really generic, you would have to write dedicated code for each. Doing as you suggest wouldn't improve things. 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 is all excluding the fact that a DVM may just not respond you and you wouldn't know if that was because you did something wrong or if the relay is broken or the DVM is broken. What I'm trying to say is: hardcoded specs, one for each DVM, is already how it has to work, and will work better. 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. I've said before that "DVMs as a concept make no sense", but I think they're a great marketing term, we just need to stop pretending they describe a "standard".