Care to explain why? Seems quite useful when talking about paying for arbitrary compute on others machines

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

use restful apis. rpcs are ok as well.

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.

I agree the idea is still interesting to me, but I cant integrate my client with an idea. I need a spec that defines what parameters I can send and what they do

Agree. I did attempt to jump on the DVM band waggon a few times. But I found it too complex in the end. A simple machine to machine system that has nostr and lightning in the mix, I'm all for, though!

Experimentation is necessary and wonderful. But so is knowing when to cut bait. And while I hear those who say we aren't in competition with X, Bluesky, etc... eh, yeh, but we are. For time and attention. Quality of UX >> bells and whistles

Then let's kill them.

Per our previous discussion, I think the issue is really that it is a spec of specs and neither part of that is followed. I don't think it's actually useful to discuss dvms as a spec but it is useful to discuss the use cases nested within. The same way a company isn't going to build all their doors bigger just for the vending machine, a client shouldn't re-engineer the client to fit a specific type of DVM in. Does the transcribe DVM fit into your client? Then implement that. If the spec isn't followed, pick the one you prefer and use it and prompt that person to PR that part of the DVM repo. Do that for 2 more dvm types and then a pattern will probably emerge that will make you realize what the actually problem is with the spec itself. I don't think there will ever be a client that can implement all dvm types, but there will likely be pockets that end up specd out in ways that can be.

As a new-ish user, I don't see any better way of doing note discovery for stuff outside of my feed.... DVM's have been an essential part of my Nostr experience so far.

U're a troll, sir

Why?

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.

I don't know why you're saying this if you agree with me yourself.

It is a strange paid API (sometimes free) but with a relay instead of a server, which makes it super confusing

I would like to hear constructive feedback from you. That afirmation is for my recent article about dvms? I agree there is loads of room for improvement

This is good constructive feedback, and totally agree

premature abstraction

#mindstr why are DVMs not a useful concept? Mindstr response, not too bad, I might agree with more than 50% here...

GitHub

NIP-101 Event Preservation Tips by securitybrahh · Pull Request #1902 · nostr-protocol/nips

I need inputs to how we can enforce that relays do not break the promise to preserve the event and how eternal preservation can be cascaded through...

how is this?

Yea, there are some valid points there

i agree that one spec is too minimal. this is exactly why the spec is being split into several i thought?