But this is not even true. The flow is always the same with the spec. Just different tasks (kinds) have different parameters.

@Dustin Dannenhauer would you say @ots_nbot qualifies as a DVM or not? Shouldn't that kind of thing also be considered a DVM? What about a thing like

Bluesky Social

Bluesky

I think the way Bluesky did this "labeler" stuff is interesting in a way: the DVM is just a "bot". The bot should have a kind:0 profile and it can even post notes sometimes, perhaps advertising their services. Some bots respond to kind:1 commands, others respond to kind:5001 commands, some send DMs, others publish content when prompted, others do it without being prompted. 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. There are tons of bots out there, I'd say some will never qualify as a DVM because they're just shitposting (which is good), but some are posting weather data, others are posting bitcoin data. It would be nice if bots publishing weather data could be standardized as DVMs, for example. I don't know bitcoin data, but what do I know? I don't have a very concrete plan.

I forgot to say that @Keyhan Alizadeh is right in the sense that HTTP services could also be considered DVMs. 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

npub.world

). In that sense every zap provider is a DVM: you call it via HTTP and it emits a kind:9735 event. But today apparently people feel they're not being nostric enough if they do not turn what could have been an HTTP service into a service that listens on a bunch of relays for events and responds with events. I think a new NIP with clearer recommendations would address that, by which I mean we should tell people that sometimes it's better to do an HTTP service, and we can even standardize those HTTP services if they call for it (again, like NIP-57 did).

workinonit

OK, found this

All NIPS are suggestions (except the required ones, which are rare)

This is not true, you're not forced to implement them, but once you decide to implement them you must follow the rules. Unless you're just saying "you can't force anyone to do anything", which is also true but then it also applies to the required ones.