Nostr Web Client

More comments below. At this time I'm still unclear on what your specific issues are and what you think would be better.

> "was a good idea when I thought there could be a generic interface for interacting with DVMs"

We have a generic interface, there are 3 possible flows, per kind in the DVM Range:

1. the classic flow, both 5xxx and 6xxx

2. only 6xxx

3. only 5xxx

Each would use kind 7000 for any extra steps, including payment. The specific flow that a single DVM wants to use can be custom if needed. Good DVMs will publish documentation or you will be able to check DVMDash for the flow.

> "why DVMDash doesn't show details about each request and response"

The first version of DVMDash did this, I rewrote the whole backend and focused on the stats page for now - I expect to have the new version of what I call the debugging tool online soon, within a month or so, that not only shows event details, but also a graph like interface to see which DVMs responded, view them in time sorted order, etc.

> "why I tried to make a `nak dvm` command but failed"

What problem did you run into? I'd love to help you make this happen in a way that's consistent with other DVMs being built.

> "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 sounds like a "Who will build the roads" argument. Somehow... it's working nowadays? I think what you're really saying is that:

1. We need better spec / flow announcements per DVMs - maybe NIP-89 (kind 31990) is too limited. This is easily solved.

2. We need more clarity on NIP-90 to describe the possible flows and to tell users how they can ask relays for which DVMs have announced themselves to relays, how to interact with them, etc.

3. We need to make it more of a norm for DVMs to publish external documentation. Every API has this. New, serious DVM projects like Vertex is doing this.

If we were to do all 3, which is consistent with upgrading the spec, which hasn't changed much since it was first published, would that solve your issues? A bunch of folks have literally been working on all 3 recently.

> "wouldn't know if that was because you did something wrong or if the relay is broken or the DVM is broken."

This is a nostr-wide issue. DVMDash will run an oracle eventually that will publish events, and just recently don't believe the hype submitted a PR for heartbeats for DVMs. You can't know any npub or relay or anything is online until you try to interact with it or check some external source, etc.

> "hardcoded specs, one for each DVM, is already how it has to work, and will work better"

This does not need to be decided up front, ahead of time, in a prescriptive manner. NIP-89 + extensions solve this (or if we don't want to use NIP-89, we can do the same thing somewhere else). I think hardcoded specs was not in the original vision of Pablo's and I still agree we don't need complete hardcoded specs.

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

Can you say more here? Sure, the range is arbitrary, but what other forms of automated interaction are you talking about? Can they not fit into one of the 3 flow patterns I described above?

> "DVMs as a concept make no sense"

A lot of people disagree with this. They make a lot of sense - it's literally the best solution I've ever come across to realize a decentralized API marketplace, decentralized AI workflows, or building more interesting Nostr clients.

> "re the OpenAI pattern"

This might very well be what the kind 5050 LLM DVMs end up converging on. I'm planning to launch a new LLM DVM that supports the OpenAI pattern - this is mostly about which parameters to accept, which is already supported in the DVM patterns.

fiatjaf 8mo ago

So you don't like https://www.data-vending-machines.org/? 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.

Reply to this note

Please Login to reply.

Discussion

Dustin Dannenhauer 8mo ago

Haha - I think it might just be that a lot of people behind the scenes are really getting into DVMs and this PR caught everyone by surprise. Most of us would rather upgrade the existing NIP-90, than start over.

Yes, each DVM should publish their own documentation. If a DVM operator doesn’t keep theirs up to date, it's their loss. They are already responsible for keeping their DVM online and available.

Nip-89 is pretty neat. DVMs are mostly using Kind 31990 which says which job request kinds they accept. I recently added this to DVMDash, so that you can see which DVMs operate on which kinds. Most only operate on a single kind, but some DVMs like https://stats.dvmdash.live/dvm-stats/5fc48ac4765ff81e9c51014b9d2f2c91621370f4c6b5452a9c06456e4cccaeb4 support multiple kinds.

In the NIP-89 announcement, the 'content' field is stringified json, and then within that is a ‘nip90Params’ field that contains all the inputs that the DVM wants to receive in the 5xxx job request kinds. So for translation DVMs, you should give a ‘language’ param. Here’s a big analysis I just published covering which params are being used per 5xxx DVM kind: https://wikistr.com/dvm-announcement-analysis*da18e9860040f3bf493876fc16b1a912ae5a6f6fa8d5159c3de2b8233a0d9851

> re: nostr-data-vending-machines.org

I'm personally not the biggest fan. It requires manual effort to keep up to date. I'd rather have clients that pull wiki events or kind 31990 events (nip-89) and show the actual documentation that the DVM owners published themselves. This is how I approached adding documentation per DVM kinds on DVMDash - I collected all the events on each DVM kind, generate a wiki doc with a brief description of the input and output, and then I link to these notes (really, dvmdash frontend pulls the wiki notes and displays them). Right now, if a new DVM came online under a new kind, and that DVM owner published a wiki event with a 'd' tag for 'kind:5xxx' where 5xxx is the kind they used, it should show up on DVMDash automatically.

For each DVM on DVMDash, it pulls data from their NIP-89 kind 31990 announcements for their description, etc.

While DVM owners have been decently good about publishing NIP-89 announcements, they haven't been so good about other types of documentation (except Vertex). I want to encourage DVM owners to also publish a kind wiki if one doesn't exist, for how they expect it to operate if they are introducing it for the first time. We might also want to add a 3rd documentation page that's just about the DVM itself.

So really, every DVM operator should do the following:

1. publish a NIP-89 kind 31990 announcement about the params they expect and kinds they support

2. publish a wiki page about their DVM, including example inputs and outputs, a description, how much it costs, etc. AFAIK this hasn't really been done yet. data-vending-machines.org was a first attempt at a such a thing, but too centralized imo.

3. (optional; for people making DVMs under new kinds) - write a kind wiki spec like what I've done here: https://njump.me/naddr1qvzqqqrcvgpzpkscaxrqqs8nhaynsahuz6c6jy4wtfhkl2x4zkwrmc4cyvaqmxz3qqykk6twvsar2vesxq02d424 - this is what is shown on https://stats.dvmdash.live/kind-stats