pull down to refresh

Hello world, I'm a pleb. I am working on a DVM for the nostr-verse.
Nostr is JSON based and relatively easy to implement, so I'm a good test case.
I want to create a DVM chatbot that engages in conversation. Let's say you have an idea and you want another party to flesh it out, ask questions, challenge assumptions, play devil's advocate and otherwise assist in brainstorming. I'm building one of those - and it's great.
Now I want it to integrate with nostr. I also want to get paid in sats to recoup the cost of running my AI hardware.
I need help with understanding the mechanics of NIP-89 and NIP-90
Am I supposed to have a script that filters and requests events from relays in order to get these job requests? I'm wondering if latency plays a role here. I have so many questions and would really like a few examples in order to help me get started.
I've heard @nvk 's unleashed.chat is being configured to run as a DVM. I've had the same idea and watching him get up and running has been a huge inspiration! I'm FOMO'ing really hard right now.
Does PlebLab have a course on this? I'd really love a "hello world" example that gets me up and running. This Nostr thing has amazing potential and I'm here to add value and collect sats!
Meh. I'm abandoning this for now.
I'll get my bot online and eventually, as this gets fleshed out and built upon, I'm sure I'll figure it out...
Perhaps a conversational bot isn't the best use case for a DVM. More of "what's the weather in sf?" or "summarize top posts of SN for yesterday." Input request -> Data output. Not my use case of an open-ended conversation. Although, connecting a search engine / tools to AI and having it return "results" could be a good DVM, but I'm not sure how a continued back and forth would function... at least not yet.
reply
Am I supposed to have a script that filters and requests events from relays in order to get these job requests?
Yes, I think so.
I haven't looked much into NIP-89 and NIP-90 but that's at least how NWC works: for every payment request, you broadcast an encrypted event with the bolt11 payment request inside and the wallet listens for such events (kind 23194). When the wallet sees such an event, it pays it (or not) and then broadcasts another event with success or error. The client also listens for such responses (kind 23195). That's how the client and wallet communicate: by broadcasting events.
Ideally, the relay (that is defined by the wallet in the NWC connection string) would require authentication but the events are encrypted (even though NWC uses NIP-04 and not NIP-44 which was merged after NWC) so the spec only recommends authentication but it's not mandatory.
I'd really love a "hello world" example that gets me up and running.
You can look at the SN code if you want an example for a NWC client here.