-
@ hzrd149
2025-04-15 06:58:14Its been a little over a year since NIP-90 was written and merged into the nips repo and its been a communication mess.
Every DVM implementation expects the inputs in slightly different formats, returns the results in mostly the same format and there are very few DVM actually running.
NIP-90 is overloaded
Why does a request for text translation and creating bitcoin OP_RETURNs share the same input
itag? and why is there anoutputtag on requests when only one of them will return an output?Each DVM request kind is for requesting completely different types of compute with diffrent input and output requirements, but they are all using the same spec that has 4 different types of inputs (
text,url,event,job) and an undefined number ofoutputtypes.Let me show a few random DVM requests and responses I found on
wss://relay.damus.ioto demonstrate what I mean:This is a request to translate an event to English
json { "kind": 5002, "content": "", "tags": [ // NIP-90 says there can be multiple inputs, so how would a DVM handle translatting multiple events at once? [ "i", "<event-id>", "event" ], [ "param", "language", "en" ], // What other type of output would text translations be? image/jpeg? [ "output", "text/plain" ], // Do we really need to define relays? cant the DVM respond on the relays it saw the request on? [ "relays", "wss://relay.unknown.cloud/", "wss://nos.lol/" ] ] }This is a request to generate text using an LLM model
json { "kind": 5050, // Why is the content empty? wouldn't it be better to have the prompt in the content? "content": "", "tags": [ // Why use an indexable tag? are we ever going to lookup prompts? // Also the type "prompt" isn't in NIP-90, this should probably be "text" [ "i", "What is the capital of France?", "prompt" ], [ "p", "c4878054cff877f694f5abecf18c7450f4b6fdf59e3e9cb3e6505a93c4577db2" ], [ "relays", "wss://relay.primal.net" ] ] }This is a request for content recommendation
json { "kind": 5300, "content": "", "tags": [ // Its fine ignoring this param, but what if the client actually needs exactly 200 "results" [ "param", "max_results", "200" ], // The spec never mentions requesting content for other users. // If a DVM didn't understand this and responded to this request it would provide bad data [ "param", "user", "b22b06b051fd5232966a9344a634d956c3dc33a7f5ecdcad9ed11ddc4120a7f2" ], [ "relays", "wss://relay.primal.net", ], [ "p", "ceb7e7d688e8a704794d5662acb6f18c2455df7481833dd6c384b65252455a95" ] ] }This is a request to create a OP_RETURN message on bitcoin
json { "kind": 5901, // Again why is the content empty when we are sending human readable text? "content": "", "tags": [ // and again, using an indexable tag on an input that will never need to be looked up ["i", "09/01/24 SEC Chairman on the brink of second ETF approval", "text"] ] }My point isn't that these event schema's aren't understandable but why are they using the same schema? each use-case is different but are they all required to use the same
itag format as input and could support all 4 types of inputs.Lack of libraries
With all these different types of inputs, params, and outputs its verify difficult if not impossible to build libraries for DVMs
If a simple text translation request can have an
eventortextas inputs, apayment-requiredstatus at any point in the flow, partial results, or responses from 10+ DVMs whats the best way to build a translation library for other nostr clients to use?And how do I build a DVM framework for the server side that can handle multiple inputs of all four types (
url,text,event,job) and clients are sending all the requests in slightly differently.Supporting payments is impossible
The way NIP-90 is written there isn't much details about payments. only a
payment-requiredstatus and a genericamounttagBut the way things are now every DVM is implementing payments differently. some send a bolt11 invoice, some expect the client to NIP-57 zap the request event (or maybe the status event), and some even ask for a subscription. and we haven't even started implementing NIP-61 nut zaps or cashu A few are even formatting the
amountnumber wrong or denominating it in sats and not mili-satsBuilding a client or a library that can understand and handle all of these payment methods is very difficult. for the DVM server side its worse. A DVM server presumably needs to support all 4+ types of payments if they want to get the most sats for their services and support the most clients.
All of this is made even more complicated by the fact that a DVM can ask for payment at any point during the job process. this makes sense for some types of compute, but for others like translations or user recommendation / search it just makes things even more complicated.
For example, If a client wanted to implement a timeline page that showed the notes of all the pubkeys on a recommended list. what would they do when the selected DVM asks for payment at the start of the job? or at the end? or worse, only provides half the pubkeys and asks for payment for the other half. building a UI that could handle even just two of these possibilities is complicated.
NIP-89 is being abused
NIP-89 is "Recommended Application Handlers" and the way its describe in the nips repo is
a way to discover applications that can handle unknown event-kinds
Not "a way to discover everything"
If I wanted to build an application discovery app to show all the apps that your contacts use and let you discover new apps then it would have to filter out ALL the DVM advertisement events. and that's not just for making requests from relays
If the app shows the user their list of "recommended applications" then it either has to understand that everything in the 5xxx kind range is a DVM and to show that is its own category or show a bunch of unknown "favorites" in the list which might be confusing for the user.
In conclusion
My point in writing this article isn't that the DVMs implementations so far don't work, but that they will never work well because the spec is too broad. even with only a few DVMs running we have already lost interoperability.
I don't want to be completely negative though because some things have worked. the "DVM feeds" work, although they are limited to a single page of results. text / event translations also work well and kind
5970Event PoW delegation could be cool. but if we want interoperability, we are going to need to change a few things with NIP-90I don't think we can (or should) abandon NIP-90 entirely but it would be good to break it up into small NIPs or specs. break each "kind" of DVM request out into its own spec with its own definitions for expected inputs, outputs and flow.
Then if we have simple, clean definitions for each kind of compute we want to distribute. we might actually see markets and services being built and used.