reset the DVM spec #1903
reset the DVM spec #1903
Conversation
|
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? |
|
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? |
The issue with using a generic name is that devs expect that making a DVM automatically makes their stuff available in many clients. That is and will always be completely false. They only get any benefit if they make a DVM that re-uses an event kind with the exact same params as other DVMs of that kind, and even so, it only works on clients that support that specific kind. So, they do a lot of work and then get disappointed that their DVM is not compatible with anything. Reusing the name for other things (like HTTP/API calls) will only make the situation worse. We had seven experiences with HTTP/JSON API specs:
All seven are very different APIs from one another. I wouldn't call ANY of them DVMs. I wouldn't even group them into the same thing. From those, I think the Blossom documentation model is the one to be copied, not the DVM one. If Vertex wants to build one, it should focus on itself, release opensource reference implementations, and create "BUD"-like specs. Just don't make redirections like on NIP-96. There is no point in grouping things under the same name. |
Yes, but HTTP is the ideal request/response vehicle, while Nostr events aren't. When you send a Nostr event you have no idea if anyone is listening on the other side. You may fail to find the correct relays, you may fail to connect to the relays you want, you may fail to send the event to the relay, or you may succeed in sending the event and then get no feedback about whether your event was read by whoever you wanted to reach. |
It makes sense that you don't, because you are assuming that DVM is this request/response paradigm that happens with Nostr events being published forever on hardcoded relays. My entire point was to reframe that. But also these examples are not anywhere near the kind of thing I would think of calling "DVM" myself either. Here are some other examples that fit better:
The first 5 exist today (ots_nbot, Vertex, nostr.wine and nostr.band APIs, relays.land, algo.utxo.one), the other 3 exist partially but could easily be finished in the way they're described above. Anyway, I think these things all fit the general idea of a "DVM", but sure, if no one can see the possibility of a change like I'm proposing and wants to condemn the term "DVM" to only mean request/response via events then I guess we can have that too, except that now DVMs, instead of being something cool and automatic, will be synonymous with an unreliable inefficient API design that confuses everybody and is barely useful, not a great look for Nostr. |
I'm curious about this. What are you talking about here? What are the missing specs and what is that single implementation? |
Only if the connection is Sync. Many DVMs take a long time to run. Running Async and behind firewalls is what DVMs were about. Otherwise, the DVM framework wouldn't make any sense. The way you wrote "It's important to notice that such definition of DVM encompasses basically everything in the world" basically renders this NIP useless. I don't even know why we need a name for that. What are we gaining with this NIP? Or is it just extra mambo jumbo that no one will ever read? This is like defining the WebSocket protocol inside our NIPs. We don't gain anything with it. The new text doesn't add or specify anything to anyone.
There are no specs for opentimestamps. It's just one implementation replicated into many languages, with major differences depending on which blockchain they are committing to. The calendar server is just one implementation. |
This is a failure of documentation. We should update the spec to make this clear. DVMs do not encompass everything in the world. There's lots of use cases, which we are already seeing (https://stats.dvmdash.live/kind-stats) that fit nicely, especially for long running async jobs like @vitorpamplona mentioned. @fiatjaf why not make a separate spec for everything else you want to do? I don't see any conflict with having existing DVMs (we all agree we need better documentation and explanations of the tradeoffs) and something else that uses http, or websockets, or whatever you want. Maybe you just need to invent a new NIP, explain how people announce those services, and you're all set. No one working on DVMs expect them to solve everything, and people aren't using them for everything. |
|
If all you want to do is to specify something like nostr.wine HTTP translation services, just specify that as its own NIP. You don't need to call it a DVM to get an HTTP NIP in here. We don't even need to call the thing anything else but "translation API". The DVM spec is about how translations get to you (async via relays) and not about how the service itself runs or what it does. It is just the transport layer. For instance, the same nostr.wine HTTP translation service can also reply as a DVM or can be running automatically as a bot. Bots != DVMs != HTTP calls. |
Well said! |
We should move to ephemeral events or expired-at tags, as @gzuuus suggested before. "Being published forever" is not a requirement |
Each DVM type can make that choice. But IMO, we have made the opposite mistake on NIP-47 that everything is ephemeral, and because of that, some use cases of that specific DVM cannot be built. So, expired-at tags are preferred. And they can be added to any DVM that already exists today. |
|
@vitorpamplona you must decide if you're talking about things as they are or as they should be. If you keep switching it's impossible to have a conversation. -- let's paint our house blue, the current white color is bad |
|
Either way, since no one here seems to get my idea I won't insist. If you want to keep the existing NIP as it is then fine, but we'll need it to be rewritten. It cannot possibly stay in the current form because it is ridiculously misleading. Before opening this PR I didn't know half of what @dtdannen described about how DVMs work. What he calls DVMs is categorically different from what the current PR describes. Someone has to volunteer to rewrite this NIP taking into account all the NIP-89 shenanigans and "dynamic specs", and it must be simple and clear such that it is possible to implement a DVM after reading the NIP. If that rewrite doesn't happen then the next best course of action will be to clear the NIP text or write something like "if you want to learn how to do DVMs ask around". Agreed? |
|
My position here is simple.
Once we have "DVMs" clearly defined in their own NIPs, NIP-90 should be irrelevant and can be either deleted or just modified to serve as an Umbrella design pattern of the other NIPs, IF NEEDED (I don't think we will need it). |
|
That's almost reasonable, I just don't like the idea of having a ton of NIPs, one for each badly-thought DVM idea that will only ever be implemented by one guy once and abandoned after 6 months. That would be very confusing for everybody who ever lands on the NIPs repo and is trying to make something solid and interoperable. |
|
Also the current NIP doesn't serve any purpose at all, it doesn't even describe the currently existing DVMs. So we really don't lose anything by either deleting it or rewriting it to reflect the current practices. |
The same rules apply: Each DVM must have at least 2 implementations and 2 operators to be included.
Separating them all is better because nobody will ever implement all DVMs. Each client can only support a few types at most. So, making sure whoever is implementing them can read just that NIP and get it done is key. Right now, the DVM NIP is stuck because we have too many people doing too many different things, and just one text that must match them all. That's why everything is stuck. In that new world, @believethehype could have transitioned over to NIP-44 for his DVM kinds independent of everybody else, which might decide to stay in NIP-04. We are trying to hard to join everybody into just one NIP. |
|
@fiatjaf are you aware of this repo? Its one of 3 repos on the Nostr protocol. |
|
Myself and others are already working on a new NIP 90, that covers a lot of what is in this thread. Even if it doesn't become the new NIP, it can serve as a guide to the design pattern of DVMs. One of the initial ideas of NIP-90 was to be a marketplace of services. I like the idea of specifying a particular "DVM" announcement kind (like what is suggested here: #1728) so that folks who wish to advertise their DVMs with other DVMs, can do so. In that case, maybe the only specific kind numbers in the new NIP-90 would be the announcement kinds, and everything else is up to the DVM creators. I'd like to propose leaving this thread open until we share the new version. |
|
My recommendation is to send the NIP for a specific implementation first. And only if it gets traction with users, try to generalize to a design pattern for DVMs. We spent way too much time generalizing before any implementation is actually used. |
|
I think the problem with this NIP is the overgeneralisation of the concept of a DVM, simply because it's cool. Some people have an idea of what a DVM is, while others tend to overgeneralise, so everything is confusing and the conversation is unproductive. If we accept the term DVM as a generalisation of any interactive pattern between pubkeys, we should define subsets of DVM, such as DVM:RPC, DVM:HTTP, DVM:BOT, DVM:WHATNOT. This will at least clarify the pattern of interaction depending on the protocol/concept. If we don't like that, then we should narrow down and reach consensus on what a DVM is. If we deviate from the original idea of a marketplace of computational services, where each job type has a specific kind and uses an RPC-like interaction with requests and responses using a relay for coordination, then we should define that. I think this is the first question we should answer to move forward: are DVM anything or are DVM something specific? Then we can draft accordingly and see what people implement. Another thing that happens in Nostr is that we consciously leave some standards as open as possible because we don't want to limit use cases. This is great, but I think striking the right balance is quite challenging since a standard should define something and provide implementation guidelines, etc. instead of just confusing you by being half-defined in order to allow any use case that fits that pattern, while it hasn't even been created or demanded yet. I think it would be beneficial for NIPs to be more structured and well-defined, without fearing that this would limit other possible implementations. If there is an implementation that is not defined in the standard, and someone wants to develop it and implement it, nothing will stop them. Secondly, you can update the spec or create a new one. |
|
Here's a proposed solution to many of the problems mentioned above: PR1929 |
Is there some missing context here? Has the DVM spec been abandoned by its original author, and is that why someone new is taking on a rewrite? |
|
No. Instead of improving specific points of a working spec that was fine for two years, we have 8 different specs now, all doing the same thing. I really do not like how this discussion is happening, starting with "i just reset the thing" to "I just make something i like for the one thing I personally do". Nip90s Idea was to define a simple generic workflow for a multitude of tasks related to data processing. Every task has a kind with details and rough consensus about inputs/outputs/parameters. It is actively used by a majority of social clients and by specific dvm clients. Killing it or changing the very nature of it will take months for providers and clients to adapt, If they would at all. And this is the last thing i will add to the debatte. |
|
@believethehype no one is asking anyone to adapt, and getting rid of this spec should have zero effect to existing DVMs because they are already not following this spec. I don't know how that is so hard to understand. |
|
Because they are follwing the spec. I dont where the Idea that they don't comes from. |
|
Myself and some others are working on a new draft of the spec and plan to share soon, FWIW. |
|
A few of us have iterated on a new spec that tries to address most of the comments here: The major changes are:
|
No description provided.