Nostr Web Client

Replying to

fiatjaf

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

fiatjaf 8mo ago 💬 2

nostr:npub1mgvwnpsqgrem7jfcwm7pdvdfz2h95mm04r23t8pau2uzxwsdnpgs0gpdjc would you say nostr:npub1z4d47qqqafcfmnmmn6fy655fc2xfkstxkppe44vrl3steeafdwkswtj7rz qualifies as a DVM or not? Shouldn't that kind of thing also be considered a DVM?

What about a thing like https://bsky.app/profile/did:plc:bpkpvmwpd3nr2ry4btt55ack? 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.

Reply to this note

Please Login to reply.

Discussion

fiatjaf 8mo ago 💬 3

I forgot to say that nostr:npub1h49w8en79xty6j2pwgnpm3znjhyf767jua6xgt3kvyn3w80ms86s2z9kay 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 https://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).

Dustin Dannenhauer 8mo ago 💬 1

A lot of great questions here - I'll do my best to respond to as many as I can now and share my perspective about how I think about the DVM ecosystem:

The primary benefit of DVMs is to be a better, more permission-less alternative to APIs that we use today. Once you, as a user, have an npub and some sats, you can start to interact with ANY DVM - this already is way better than API services which require custom login, setup, personal details, fiat banking, etc. per each service. Additionally, because of the way DVM kinds are setup, you can post a job to a kind and then pick from any DVMs that respond - this provides free market dynamics and competition, along with redundancy, etc. The competition aspect hasn't really been realized in practice quite yet (except for a period of time when AI Image Generators experienced this, kind 5100).

> "There is no point in having a spec that is just a suggestion. "

Aren't all specs suggestions? Kidding. Really though, myself and many others have been feeling this way and have been discussing improvements. It's pretty clear to me that kinds 5xxx are for job requests/ inputs by consumers of a service, kinds 6xxx are for job results / outputs, and kind 7000 is for intermediate communication. I think this kind numbering works really well. We should remove the requirement for a DVM to respond to 5xxx like in the case of a weather data DVM that only would publish kind 6xxx events. We could also remove the requirements for a 6xxx event, which I can imagine might happen when a DVM responds to a user in an alternative fashion, like a DM, email, text, a special websocket connection, etc.

BTW we are going to run out of kinds as 5000-6999 fill up, so we should go ahead and reserve kinds 50000-69999 and 500000-699999.

> "Deleting everything was meant as a first step only."

thanks for explaining, I didn't know this.

> "would you say [@ots_nbot](https://primal.net/p/nprofile1qqsp2k6lqqqw5uyaeaaeayjd22yu9rymg9ntqsu66kplcc9uu75khtg5cplln) qualifies as a DVM or not? Shouldn't that kind of thing also be considered a DVM?"

I'd say it can qualify as a DVM if there's a need for structured input (json) requests to the bot. More generally, we shouldn't be concerned with whether something is a bot or not (as time goes on, this becomes more pointless to try to solve). We should be more concerned with the nature of the interaction. If you're going to be communicating with something via natural language all the time (and maybe images) you could run the service as a regular npub, using kind:1 events. If instead the communication is structured json with parameters, it makes sense to use a different kind so as to not pollute the kind:1 space.

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

I disagree that the emphasis should be on whether something is a bot. It should be more based on the kind of interaction (structured data vs natural language).

> "It would be nice if bots publishing weather data could be standardized as DVMs,"

I completely agree. I'd say this is fine to do now, someone just needs to pick an unused kind in the 6xxx range and start broadcasting those events.

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

Maybe. The interaction could always start via DVMs and then move to HTTP, websockets, etc. But then you have to use a different auth, and maybe other tradeoffs. You expose your IP, etc. For something like a streaming use case it's probably worth it.

The more services that can run as DVMs could lead to more inter-operatibility and DVM chaining, in a more seamless fashion than trying to use multiple APIs, so I'd like to see more DVM services running and operating at the Nostr level.

DVMs, as they are today, can be BOTH posting profile:0 data about itself, posting kind:1 events to Nostr, and also doing specialized work via kinds 5000-5999. Fun idea - humans could decide to earn some sats by announcing they want to do some work on a particular type of job type in the same way (hasn't happened quite yet, I believe).

fiatjaf 8mo ago 💬 1

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.

Dustin Dannenhauer 8mo ago

It would be nice if people would opt in to calling things bots, but you can't really know for sure. Even their labelers would just be guessing. Same problem with all the teachers in schools wanting to use an AI tool to say if something is written by AI - which has a miserable success rate, and fundamentally doesn't make any sense at all. How can a sequence of words be proven to come from a human or an AI? It's the same reason why software developers hate algorithm patents - multiple devs can discover the same algorithm using the building blocks of programming languages, but the first person to patent it gets some ownership over it.

fiatjaf 8mo ago 💬 2

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

Dustin Dannenhauer 8mo ago

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 💬 1

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.

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

Vincent 8mo ago 💬 30

DVM < bots

nevent1qqsxpzk9cw2w4kch3lxyd6m8f3q35ssz2umgcg546hng0zffrqq0mtspz3mhxue69uhhyetvv9ujuerpd46hxtnfduljdj62

fiatjaf 4mo ago

nostr:nevent1qqsxpzk9cw2w4kch3lxyd6m8f3q35ssz2umgcg546hng0zffrqq0mtspz3mhxue69uhhyetvv9ujuerpd46hxtnfduljdj62

I agree, and also subjectivity and hardcoded constants > self-described schemas.