For me the concept is more useful than the spec. See View article →

The "arbitrary" part is the issue IMO. for most DVMs its so arbitrary that clients don't know what they could pay for

Right, but that's implementation, not conceptual. The idea that I want to use someone elses computer to do operations and pay them for it is helpful. DVMs could also be called decentralized lambdas or nostr cloud or even simpler paid apis, but the concept that you put in money and data comes out is beneficial for discussing it.

There are numerous parties hoping and wishing that machine-to-machine becomes a use case for Lightning payments. I was one, once. Maybe it comes to be some time in the future, but that time is not now. Build what you want, of course, but I'd argue that precious talent, time, and energy is better spent elsewhere, like assuring that the core features work, work well, and work consistently across clients.

There are some "DVM" use cases that make sense, but framing it as this super generic tool that encompasses all "machine" use cases is absurd and counterproductive. Also trying to have a single spec for everything hurts all the use cases at the same time. The specs aren't even machine-readable (unless you're paying Sam Altman to read them for you). If someone wanted to write a "DVM" that did one thing that person should have done that one thing, not called it a DVM, and we could have created a standard for it if it was useful, or not, maybe that machine job was a proprietary spec that didn't need standardization, maybe it would fit in some other NIP and enhance it, each case is different.