Can the clients interact with bots via events to be supplied with those services that dvm aim to provide? If so, why dvm are useful abstraction?
And what are the advantages of dvms over simple http endpoint?
Login to reply
Replies (2)
A bot can have any kind of arbitrary behavior, such as listening for and responding to kind 1 notes, or listening for and responding to any other type of event in they way they want. DVMS describes and tries to standardize how this interaction is done by defining requests, responses, and job feedback. Of course, you could do the same thing and call it a bot, but that is not the point, bots can use dvms to solve some of their features.
The differences between an http enpoint and a dvm is nostr
Hmm, I really think we shouldn’t call all those different things the same thing, that could get pretty confusing. They’re different enough to deserve separate standards. In a broad sense, you’re describing a relay, which is pretty much the only type of server on Nostr, aside from some more exotic experiments. They are servers and can have HTTP endpoints, as you mentioned. There’s even a relay management API now, so why not a service API? They can totally provide HTTP JSON APIs, which they’re already doing.
Now, as for bots and DVMs, from my point of view, they’re still different things. I see bots as some kind of autonomous agent that follows instructions or has simple behavior to listen, react, or do whatever they need to gather notes. They can publish notes based on certain conditions and can be as complex or simple as you want. They use DVMs to handle some functionality or access services, they both have in common that they do not need to manage or spin up a relay, they can listen and write to multiple relays.
Also, DVMs can have HTTP endpoints if you want, but I really think relays, bots, and DVMs are different stuff altogether.