Dustin on Nostr: A lot of great questions here - I'll do my best to respond to as many as I can now ...

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](https://primal.net/p/nprofile1qqsp2k6lqqqw5uyaeaaeayjd22yu9rymg9ntqsu66kplcc9uu75khtg5cplln) 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).