It looks like you mostly agree with me, except you want to reserve the kinds. Reserving the kinds, at least to me, was a good idea when I thought there could be a generic interface for interacting with DVMs --and that's why I tried to make a `nak dvm` command but failed, and that may also be why DVMDash doesn't show details about each request and response, only statistics: because they're not really generic, you would have to write dedicated code for each.
Doing as you suggest wouldn't improve things. Now besides knowing what parameters each DVM takes as input and as named parameters, the format and shape of the response we will also have to know if a DVM accepts a prompt or not, or if it returns a response or not -- and, worse, if it uses the feedback in any particular way that has to be handled or not. This is all excluding the fact that a DVM may just not respond you and you wouldn't know if that was because you did something wrong or if the relay is broken or the DVM is broken.
What I'm trying to say is: hardcoded specs, one for each DVM, is already how it has to work, and will work better. Reserving a kind range doesn't make sense in that context, and getting rid of the reserved range and of the strictly request-response format allows us to grandfather in other forms of automated interaction into the DVM umbrella.
I've said before that "DVMs as a concept make no sense", but I think they're a great marketing term, we just need to stop pretending they describe a "standard".
fiatjaf /
npub180…jh6w6
2025-05-02 14:51:52
in reply to nevent1q…0na8
Author Public Key
npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6Seen on
wss://pyramid.fiatjaf.comwss://theforest.nostr1.comwss://relay.damus.iowss://relay.westernbtc.comPublished at
2025-05-02 14:51:52Event JSON
{
"id": "d480bdb601a7d735cdd0cd9a4ea8cc6cbbee0dab2aa8d32bbca2fc970f652c71",
"pubkey": "3bf0c63fcb93463407af97a5e5ee64fa883d107ef9e558472c4eb9aaaefa459d",
"created_at": 1746197512,
"kind": 1,
"tags": [
[
"p",
"da18e9860040f3bf493876fc16b1a912ae5a6f6fa8d5159c3de2b8233a0d9851",
"wss://23.182.128.33/",
"Dustin"
],
[
"p",
"155b5f0000ea709dcf7b9e924d5289c28c9b4166b0439ad583fc60bce7a96bad",
"",
"ots_nbot"
],
[
"p",
"bd4ae3e67e29964d494172261dc45395c89f6bd2e774642e366127171dfb81f5",
"",
"k."
],
[
"e",
"639a62d47ad1687c7908da4e5c3b65d86bf59bfbebb8f5bec3d350ed85e74fac",
"wss://pyramid.fiatjaf.com/",
"root"
],
[
"e",
"de2b152277803196c40619475267a96a11308beb846643083828f5743c4c36df",
"wss://pyramid.fiatjaf.com/",
"mention"
],
[
"e",
"fe3b1c4bddd24242009113e676c146ec0b25ac44c8c3d3475e968f4bc6889f28",
"wss://nostr.wine/",
"reply",
"da18e9860040f3bf493876fc16b1a912ae5a6f6fa8d5159c3de2b8233a0d9851"
]
],
"content": "It looks like you mostly agree with me, except you want to reserve the kinds. Reserving the kinds, at least to me, was a good idea when I thought there could be a generic interface for interacting with DVMs --and that's why I tried to make a `nak dvm` command but failed, and that may also be why DVMDash doesn't show details about each request and response, only statistics: because they're not really generic, you would have to write dedicated code for each.\n\nDoing as you suggest wouldn't improve things. Now besides knowing what parameters each DVM takes as input and as named parameters, the format and shape of the response we will also have to know if a DVM accepts a prompt or not, or if it returns a response or not -- and, worse, if it uses the feedback in any particular way that has to be handled or not. This is all excluding the fact that a DVM may just not respond you and you wouldn't know if that was because you did something wrong or if the relay is broken or the DVM is broken.\n\nWhat I'm trying to say is: hardcoded specs, one for each DVM, is already how it has to work, and will work better. Reserving a kind range doesn't make sense in that context, and getting rid of the reserved range and of the strictly request-response format allows us to grandfather in other forms of automated interaction into the DVM umbrella.\n\nI've said before that \"DVMs as a concept make no sense\", but I think they're a great marketing term, we just need to stop pretending they describe a \"standard\".",
"sig": "ceb737a8752e600921fa4114c40cb394ad40625ed5e8e429a396fe2dc4d488a11af7346fa74ad43e1b7c16e1f49ab68ceade981adf053b05fb65309b52844fbc"
}