Dustin Dannenhauer on Nostr: Let’s say you attach an npub to some computation. That’s 33% of what a DVM is. ...
Let’s say you attach an npub to some computation. That’s 33% of what a DVM is.
How will people find out about it? Will you post a kind 0 profile like humans do? Or do a kind 31990 announcement in NIP-89? Now you’re at 66% of what makes a DVM.
How will people or services use your computation? Maybe you decide you need a special kind of format for the input to the computation, so you pick, oh I don’t know, kind 5123 and a spec of how the input data should be laid out. Now you have 100% of what a DVM is.
DVMs are the natural extension to having paid computational services behind npubs. They aren’t unnecessarily complex, quite the opposite.
How will people find out about it? Will you post a kind 0 profile like humans do? Or do a kind 31990 announcement in NIP-89? Now you’re at 66% of what makes a DVM.
How will people or services use your computation? Maybe you decide you need a special kind of format for the input to the computation, so you pick, oh I don’t know, kind 5123 and a spec of how the input data should be laid out. Now you have 100% of what a DVM is.
DVMs are the natural extension to having paid computational services behind npubs. They aren’t unnecessarily complex, quite the opposite.
quoting note1wjm…cs4kYes that would be a plus. I think we might need a lighter version that is easier to get started with and do useful things.
Also I see it going in the direction of cashu integration, is my guess. And cashu want to charge on every tx. That's going to make workflows complex.
I see DVMs getting more complex, not less, and they are already very complex. Perhaps it's a good time to examine the most useful parts of it, and make a simple version. After all, nostr took off when the protocol was a simple 2 page spec. Even nostr core is a beast of complexity now which changes too frequently.
Getting back to simplicity I think is the path to success.