You can fetch the responses of the DVM straight from the relay right?
nostr:npub176p7sup477k5738qhxx0hk2n0cty2k5je5uvalzvkvwmw4tltmeqw7vgup are you against exposing the Vertex information through some non-DVM means like perhaps direct events I can just query on your relay, or NIP-50, or some custom HTTP API? I don't know.
Discussion
I don't know, it feels so cumbersome, you have to publish an event, signed by your key, then wait for the response? And then that stuff gets saved forever, and all you wanted was to make a search?
The state is constantly changing, to publish events NIP-66 style would be burdensome in its own way. When I considered publishing events for a similar purpose, I backtracked and landed at a DVM as well.
What is a DVM anyway?
The request response stuff makes it be seen as something it isn't, or shouldn't be. There are at least two different use cases for DVMs, one is good, the other isn't, and they're mixed together in a cursed mix. The good one doesn't need the request-response interface, the other does.
Yes, I think the same, dvms are somehow wasteful if we understand the responses as a non valuable data, I mean there are going to be responses that worth to keep and others than no, depending on the job. But I agree, I would add ephemeral events to the spec, which are good for the use case. Also I'll be pruning my relay of dvm responses