reset the DVM spec #1903
reset the DVM spec #1903
Conversation
90.md
Outdated
| ``` | ||
|
|
||
| Customers can use NIP-89 to see what service providers their follows use. | ||
| This NIP is a placeholder for kind and interface definitions of multiple small machine-provided services. |
There was a problem hiding this comment.
shouldn't we still point to https://github.com/nostr-protocol/data-vending-machines/tree/master/kinds?
There was a problem hiding this comment.
no, we should define the specs here.
There was a problem hiding this comment.
got it. so https://github.com/nostr-protocol/data-vending-machines is useless then?
|
Never delete, just deprecate. |
|
This NIP doesn't specify anything, so what am I deleting? None of the events supposedly covered by the NIP are even following their own spec anyway, so who cares? |
|
What is your thinking? When I first saw the DVM spec I thought it was atrocious. Then I settled into the reality, and recently I have been planning to build something kind of big with it even though it's ugly. Are you looking to rework the whole request->feedback->response flow, or to improve the data model, or what? |
|
My thinking is that the current spec isn't helping anyone. If you want to do something pick some kinds and do it in a way that you think makes sense. If more people implement it and it makes sense we write down the spec here -- or in another NIP, it depends, I don't know. I believe sometimes we don't need the "request" part (for example, a translator bot may react to every note under certain conditions, you don't need to call it manually, or a "trending feed" may be published every x minutes, without anyone asking for it); Other times we don't need the "response" -- or the respons may be a kind that already exists, doesn't have to be a new special kind (for example, my unfinished DVM that creates WARC files of webpages and saves them to Blossom, or that thing that downloads videos from YouTube and publishes them as a kind:22, or the DVM I have running -- which wasn't called a DVM before because it didn't fit the requirements here but under a more flexible definition it is -- that creates opentimestamps events of every note published to my relay); Other times we don't need a request nor a response, and so on. Also, forcing all these DVMs to adhere to a certain tag format that includes |
|
I am in favor of separately documenting each service that is to be open and implemented by multiple pieces of software, and that they don't have to be doing it in this DVM spec way which I concur didn't really bring about uniformity. But I'm also not sure how DVMs are better than REST APIs that use nostr auth, and can offer their own custom ways of payment as DVMs already have to (AFAIK). My opinion means little however because I've not done any DVM coding and I don't intend to. |
|
"You'll have to write custom code for each DVM anyway" - that's not what we're seeing, especially with kinds 5300, the first big use case of DVMs. DVMs can have custom specs but they converge around kinds. Have you seen https://stats.dvmdash.live/kind-stats ? |
|
Reasons why we should keep the DVM spec and reject this PR:
Why the DVM spec is good as it is:
TL;DR
|
|
as @dtdannen pointed about above I don't think throwing the baby out with the bath water is the right approach. Is DVM spec far from the greatest thing on earth? Yes, noone disagrees there. But there is a non trivial amount of work, clients and dvms out there following it (to various degrees of success) so just abandoning everything doesn't really accomplish anything since it is out there, it is being used etc. Given the fact that there is a decent amount of momentum with DVMs now (dvmcp, vertex, various feeds etc) it would make sense to improve on the spec or create a v2, not throw it away on a whim. There is a decent amount of people who have put effort into developing things around it that likely wouldn't want their efforts go to waste. also @vitorpamplona has a point:
there are things in the wild following this spec, lets take this opportunity to not make more of a mess in the nostr ecosystem but instead improve the protocol governance |
|
Every attempt in improving the spec got stalled in the PRs. At some Point, at least I stopped trying for that reason. Its wild that now you want to delete something that is used every day by a lot of people. At least for the content feeds, multiple people somehow managed to follow a spec that allegedly is not there. Just removing it without an alternative is not the way. |
|
Agree with @fiatjaf The core issue with DVMs is they try to be all things to all people, and that’s confusing devs. Every time a machine-to-machine use case comes up, the answer is “just use DVMs” — you had one problem. Now you have two problems. They’ve grown so broad they probably don’t belong in NIPs. And in reality, they already have their own site, spec, and PR process. I found with did-nostr that sometimes it’s better to decouple like this than keep tweaking NIPs. So while I’m not usually for deletion, this path might actually be healthier for both DVMs and nostr. |
|
Im going to be pragmatic here and write a starting point for a rewrite of this spec, from there we can shape it if we find it valuable, if not someone else would have to propose a different rewrite and so on until we find the spot. |
|
I agree that DVMs are too generic. But we don't need to delete this. Turn this one into deprecated guidance and let's start working on new NIPs that can replace it. It is a similar process that we navigated from NIP-94 to Picture, Long Video, and Short Video kinds, NIP-04 to NIP-44, NIP-59 and then NIP-17. Specialization in NIPs is good. But, we shouldn't rug pull existing devs by changing the definition of the NIP by this much. At the end of the transition, no DVM should implement NIP-90. They will all have their own NIPs to reference. |
|
I just wrote a draft spec to rewrite of the nip90, its a starting point #1904 |
|
I fail to see how this is a rugpull if the specs were already not in this NIP anyway. Also what about all the other people who are doing DVMs that aren't even in the DVM repo, are they rugpulling themselves? In fact this "reset" is a rugpush (what is the opposite of a rugpull?) because what we should actually do is to survey the ecosystem of DVMs that exist and write down the successful cases based on how they're being actually used. |
|
More context about what I'm thinking with this last commit: https://njump.me/nevent1qydhwumn8ghj7un9d3shjtnhv4ehgetjde38gcewvdhk6tcprfmhxue69uhhq7tjv9kkjepwve5kzar2v9nzucm0d5hszxnhwden5te0d3hkx6mzdauzuenfv96x5ctx9e3k7mf0qqsthtzf4akn8g3xr3dy5zcew7s4mt372nk023a6rsxtxamhu50yxmg6esl98 |
|
@fiatjaf your post mentions adding HTTP as DVMs, which was never here. If that's what you want to do (I still don't know what you want here), then this is changing the spec in some pretty massive ways. Why not just do the HTTP stuff as their own NIPs? Just copy NIP-96 or Blossom APIs for that matter. To me, our most successful DVM is NostrWalletConnect. Being spec'ed as a separate NIP helped all developers implement only this type of DVM. |
|
If we agree that the DVM spec could be improved, then let's make a DVM 2.0 spec. This is what we did with direct messages. Leave the original alone; let people migrate when ready and willing. |
Longer response to some of fiatjaf's comments here: https://njump.me/nevent1qvzqqqqqqypzpkscaxrqqs8nhaynsahuz6c6jy4wtfhkl2x4zkwrmc4cyvaqmxz3qyghwumn8ghj7mn0wd68ytnhd9hx2tcpzemhxue69uhkyetkduhxummnw3erztnrdakj7qg7waehxw309ahx7um5wgkhqatz9emk2mrvdaexgetj9ehx2ap0qqsvxj5tksmq7c5lkdmtqxc2qyu2rm0u70wrhjtv855d4je572w3cqgtarzs8 |
Most DVM specs will be super small and fit in one or two lines. We can have them directly here on NIP-90. That's how NIP-51 works: one NIP defines a bunch of list kinds because they're very simple.
Either we have a standard or we don't. If we want a specific DVM to be interoperable then it's obvious that we need the specs written somewhere otherwise we'll go totally insane. But for some use cases we don't want an interoperable standard, then it's fine to not have one. |
|
You didn't answer my question about NIP-89, and it's not that the specs aren't written anywhere, it's just they are dynamic and you have to fetch it from another place (relays). I agree that most DVMs will easily fall into one of the 3 protocol flows I mentioned and their specs can be described succinctly. Listing them in the NIP sounds fine. |
I was going to, but I forgot. My answer is that I have no idea of how NIP-89 works so I don't use it and I don't touch it. I read the spec once years ago, then people started using it in a ton of different unexpected unspecified ways, so yes, I think it is problematic.
Can you clarify this? You mean the spec is described in NIP-89 events? Or that the spec has to be inferred or reverse-engineered from event examples published somewhere? |
Sorry, something went wrong.
|
Yes, the spec is defined in NIP-89 events. It's the 'nip90Params' field in the top level 'content' field. Here's a big analysis I did over all NIP-89 announcements that DVMs have published (almost 13k now), that show the tags, parameters that the DVM takes, etc. Some of the smaller kinds don't use it. (I would have linked to njump here, but it doesn't work for me right now) |
|
This is all still too abstract for me and I'm not sure those reports should have been published as wiki articles. This is unrelated, but can you tell me why you decided to do that instead of publishing a normal article? Anyway, you can't possibly be telling me that there are actually 13k working DVMs on Nostr, right? If that was true then I would have to revise all my assumptions, but I'm pretty sure that isn't true otherwise for sure someone else would have at least mentioned them somewhere, right? It would be nice to see some more concrete examples of people who are using these DVMs and see their code. Anyway, you didn't answer me about that DVM website with specs. What is the point of such website if DVMs are publishing their own spec in NIP-89 events or websites? I think we are very close to agreeing here. |
|
Regarding the spec, I mean that yes the spec is defined in NIP-89 events. They aren't examples, it's exactly the parameters needed for the DVM, whether the parameter is optional, etc. What may not be currently in there is how the DVM flow works, like if the DVM wants payment first via kind 7000 with a lightning invoice or ecash, etc. I think we should add this into NIP-89 announcements, or at least a link to external documentation (like what Vertex provides). I don't think we should be reverse engineering the specs at all. It should be defined by the DVM's operators, just like anyone who makes an API available should provide docs about how to use it. If someone wants to use a DVM and they can't, they should complain to the DVM operator for not providing documentation.
If this is referring to my earlier comment, I really meant a website that's more a Nostr client and pulls the NIP-89 data from the relays, and displays it. By 13k, I meant 13k kind 31990 events that have been published over the last 2 years by 610 unique DVMs. But some of these haven't been online for a while. For example code, check out:
|
|
I tried to introduce examples for more concrete parameters in #1358 as a first step in July 24. The nip90 params themselves are defined in the dvm Kinds repo but its not trivial. The nip90 params also vastly depend on the Implementation. Its hard to define default ones when people use different tools in the background. Btw in your Suggestion you add primal http API Access as an example while primal actually provides nip90 dvm acess to their feeds because this is an established standard. Dvms are not Bots. Bots are Bots. Dvms are a very well defined generic Workflow in nip90 and more concrete in the dvm Kinds repo. Could this be improved? Yes. Is it all undefined and chaos and as bad as some people talk it down? |
|
Fun fact - when Pablo made NIP 90 he also released vendata.io and it supported reading the params of a DVM from nip 89 announcements. I tested it out by adding a custom param and his app showed it as a possible field I could enter when submitting a job request. I don't think it's being maintained, but you may find that code interesting, as a DVM client example. https://github.com/pablof7z/vendata.io |
|
So suppose I have this event: Does that mean that I can call this DVM with If it says |
|
Yes! If it requires payment, it should respond to your 5100 event with a kind 7000 event asking for payment (if lightning, it may give an invoice; for ecash I'm not exactly sure, don't believe the hype had an ecash example working but I haven't played with that yet). Once payment is accepted you may or may not get another kind 7000 event telling you the job is processing, and then when it's done, you get a kind 6100 event with the result. If no payment is required, you may get a kind 7000 event with a "processing" status. Otherwise you may just get the final result when it's done in a 6100 event. For the cashuAccepted flag, I'm not sure. Operationally, it only matters if it asks for payment before doing the work (returning a kind 6100 event). I think there may be a flag others are using to simply say paymentRequired. |
|
I wish all of that was in the NIP-90 text. |
|
I also made this diagram way back: https://github.com/dtdannen/dvmdash/blob/main/v1/docs/DVM_Process_Flow.png It's not necessarily the most intuitive, but it helped me figure out the flow |
|
Just to put my oar in here, DVMs should be a pattern for individual NIPs, not a comprehensive spec. See #1796 for a DVM-like thing which uses replaceable events to represent subscriptions and subscription statuses. Shoehorning this into DVMs didn't make sense, and pretty much every DVM out there suffers more or less from the same sort of contortions. Some DVMs might not have requests, monetization might work differently, different ones want different parameters, etc. The specs both in this NIP and at data-vending-machines.org are basically useless, already; in my experience you already have to reverse engineer DVMs and hand code each case anyway. Separating out the specs into their own NIPs (or NUDs) would just reflect that reality. I support eviscerating the DVM spec and update the specs on data-vending-machines.org to include whatever is relevant to each DVM type, and match the actual implementation. Of course, someone would have to actually do that work. But it would allow us to keep DVMs as they currently are, but relax the uniform specification that overly constrains actual DVM implementations. Additionally, if we're going to think about a v2, I think DVMs should have a dedicated pubkey, something along the lines of what I proposed in #1728 (at some point I'll rewrite the PR to reflect the comments there). We should just use kind 10002 for relay selections, kind 0 for profiles, kind 1s for tweets, etc. A new kind similar to 31990 should be added (again, see #1728) which represents a DVM, since they work very differently from clients, and the current listings are a little wacky. Like fiatjaf said, a DVM is just a bot that adheres to behavior defined in such a way that the implementation can be swapped out. There is value to the DVM architecture, which is also used by NIP 46 and 47, but there's no reason it should be impossible to advertise HTTP endpoints or whatever too (although maybe it would be worthwhile to have a separate listing kind to advertise those). |
Agree. The current spec is too loose, clients end up reverse‑engineering each DVM How about the folks who maintain https://data‑vending‑machines.org could come up with 10000 a v2, and once it stabilises, it could be added as a NIP |
|
We don't need a v2, we need to decouple all the v1s and design future DVMs to fit the use case, rather than the overly rigid spec. |
|
How about basing a future design on the Agent‑to‑Agent (A2A) protocol Google released recently? A2A sits on top of MCP and already handles task submission, status events, and discovery, so borrowing its patterns might spare some time and refactoring, down the line. https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/ |
|
A2A relies on DNS/HTTP for discovery and notifications. The artifact stuff looks a lot like the original DVM spec, which is what we're talking about being too restrictive. Publishing nostr kinds are much richer than returning a bunch of files. |
|
@staab could you elaborate on what you mean by this?
I looked through the issue you referenced but wasn't sure exactly what you meant. Right now, DVMs are running behind a single npub (you can browse them here https://stats.dvmdash.live/dvm-stats)
I agree with this, and I believe this is what most people who have been building DVMs, have been doing. I also think this was the original intent (not that we have to keep it; just pointing it out) by the fact that the spec allowed DVMs to issue any number of custom kind 7000 events. |
|
@dtdannen right now NIP 89 uses kind 3xxxx events, which means a single pubkey can advertise multiple handlers. Since handlers are overloaded with DVMs right now (which is how discovery works), that means that multiple DVMs can be run with a single pubkey. In practice I don't know how often that happens, but that also illustrates my point: p-tagging a DVM request should result in only one DVM being p-tagged. |
|
@staab sorry for being super verbose, but could you elaborate what you mean by multiple handlers? Do you mean right now there could be a single pubkey that publishes multiple, different 31990 events, and then users would have the issue of how to call the DVM per each 31990 announcement?
Agree. When I get 31990 events in DVMDash, I've only been treating the latest one as valid and ignoring all past ones. |
Exactly, kind 3xxxx range are parameterized replaceable events, so the |
|
I believe there is value in reputation for DVM providers, which would be more challenging to establish if we agree that there should be one public key per DVM |
Could you elaborate? |
No description provided.