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

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

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.

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?