Very cool page

No it's not.

why not?

how would it be better? I have looked far and wide and can't find anything simpler than Nostr DVMs, so I am skeptical by what you mean by "better"

its known. any body can use it. there is 1000000 of libraries and developers using them. we can use them on nostr as well. we already have a lot or more experience with them. they rely on proper well-defined and battle tested protocols.

how would it work natively with Nostr? How would they advertise themselves? Could they communicate over Nostr events sent via relays, or is it a lower level protocol like https, websockets, etc? If the communication is not happening over Nostr (and instead relies on https, websockets, etc) why even user Nostr to begin with? I think that as soon as you start to try building any of those protocols on Nostr, you'll realize you either need to offload communication from Nostr events or it will be more complicated than some of the existing DVM flows. The DVM spec is flexible though, so if it is possible to do any of those, asynchronously, then maybe you could get it to work, but I bet it would be complicated than some of the ones we have now (like 5300 for example).

Okay I just dived into this a bit more and.... RPC looks a lot like what we already are doing, so I'd be curious what you feel is missing from DVMs that doesn't support this.

"Each DVM kind can have its own flow, NIP-90 flow is a suggestion, not a requirement." This is basically why. There is no point in having a spec that is just a suggestion. All I want is clarity, the current model is producing way too much confusion. Deleting everything was meant as a first step only.

@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 @Kayhan Sepanta 🪽 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

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.

Human vending machines

The same reason we should have deleted inscriptions despite their momentum 🙂 Like yeah we can do DVMs but is this really the spirit of the protocol?

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".

So you don't like

data-vending-machines.org - data vending machines Resources and Information.

data-vending-machines.org is your first and best source for information about data vending machines. Here you will also find topics relating to iss...

You think each DVM should publish their own documentation? I am not against that at, in fact that's kind of what I'm proposing: to let people do their stuff freely instead of trying to force them into a useless spec. I don't understand how these who NIP-89 shenanigans work at all, I would welcome an explanation, preferably with examples. What is the OPV (original Pablo vision) for DVMs? I think it was me who got him into the reserved kind range because in the beginning he wanted all DVMs to just one kind -- or something like that? I regret my decision, I thought having more structure would bring sanity to the thing, but it didn't. Now we have the worst of both worlds: a spec that no one follows, but people follow a little bit here and there and for no benefit to anyone, and then people are attached to that spec and get mad when I suggest deleting it. I think we should go back to the unstructured world, that will be better.