Haha - I think it might just be that a lot of people behind the scenes are really getting into DVMs and this PR caught everyone by surprise. Most of us would rather upgrade the existing NIP-90, than start over.
Yes, each DVM should publish their own documentation. If a DVM operator doesn’t keep theirs up to date, it's their loss. They are already responsible for keeping their DVM online and available.
Nip-89 is pretty neat. DVMs are mostly using Kind 31990 which says which job request kinds they accept. I recently added this to DVMDash, so that you can see which DVMs operate on which kinds. Most only operate on a single kind, but some DVMs like https://stats.dvmdash.live/dvm-stats/5fc48ac4765ff81e9c51014b9d2f2c91621370f4c6b5452a9c06456e4cccaeb4 support multiple kinds.
In the NIP-89 announcement, the 'content' field is stringified json, and then within that is a ‘nip90Params’ field that contains all the inputs that the DVM wants to receive in the 5xxx job request kinds. So for translation DVMs, you should give a ‘language’ param. Here’s a big analysis I just published covering which params are being used per 5xxx DVM kind: https://wikistr.com/dvm-announcement-analysis*da18e9860040f3bf493876fc16b1a912ae5a6f6fa8d5159c3de2b8233a0d9851
> re: nostr-data-vending-machines.org
I'm personally not the biggest fan. It requires manual effort to keep up to date. I'd rather have clients that pull wiki events or kind 31990 events (nip-89) and show the actual documentation that the DVM owners published themselves. This is how I approached adding documentation per DVM kinds on DVMDash - I collected all the events on each DVM kind, generate a wiki doc with a brief description of the input and output, and then I link to these notes (really, dvmdash frontend pulls the wiki notes and displays them). Right now, if a new DVM came online under a new kind, and that DVM owner published a wiki event with a 'd' tag for 'kind:5xxx' where 5xxx is the kind they used, it should show up on DVMDash automatically.
For each DVM on DVMDash, it pulls data from their NIP-89 kind 31990 announcements for their description, etc.
While DVM owners have been decently good about publishing NIP-89 announcements, they haven't been so good about other types of documentation (except Vertex). I want to encourage DVM owners to also publish a kind wiki if one doesn't exist, for how they expect it to operate if they are introducing it for the first time. We might also want to add a 3rd documentation page that's just about the DVM itself.
So really, every DVM operator should do the following:
1. publish a NIP-89 kind 31990 announcement about the params they expect and kinds they support
2. publish a wiki page about their DVM, including example inputs and outputs, a description, how much it costs, etc. AFAIK this hasn't really been done yet. data-vending-machines.org was a first attempt at a such a thing, but too centralized imo.
3. (optional; for people making DVMs under new kinds) - write a kind wiki spec like what I've done here: https://njump.me/naddr1qvzqqqrcvgpzpkscaxrqqs8nhaynsahuz6c6jy4wtfhkl2x4zkwrmc4cyvaqmxz3qqykk6twvsar2vesxq02d424 - this is what is shown on https://stats.dvmdash.live/kind-stats
Dustin / Dustin Dannenhauer
npub1mg…gpdjc
2025-05-02 23:06:30
in reply to nevent1q…k7v0
Author Public Key
npub1mgvwnpsqgrem7jfcwm7pdvdfz2h95mm04r23t8pau2uzxwsdnpgs0gpdjcPublished at
2025-05-02 23:06:30Event JSON
{
"id": "d93dce58911744c453612147e6728f535cfa7a5338ddb08bb538d5636e8714f8",
"pubkey": "da18e9860040f3bf493876fc16b1a912ae5a6f6fa8d5159c3de2b8233a0d9851",
"created_at": 1746227190,
"kind": 1,
"tags": [
[
"a",
"30818:da18e9860040f3bf493876fc16b1a912ae5a6f6fa8d5159c3de2b8233a0d9851:kind:5300",
"",
"mention"
],
[
"e",
"639a62d47ad1687c7908da4e5c3b65d86bf59bfbebb8f5bec3d350ed85e74fac",
"ws://47.236.4.9:8080",
"root"
],
[
"e",
"652cbb1a89c4e9fbac98fa2f6947e21b4a5d07b4451650d29570f0d08280b592",
"ws://47.236.4.9:8080",
"reply"
],
[
"p",
"da18e9860040f3bf493876fc16b1a912ae5a6f6fa8d5159c3de2b8233a0d9851",
"wss://purplepag.es/",
"Dustin"
],
[
"p",
"155b5f0000ea709dcf7b9e924d5289c28c9b4166b0439ad583fc60bce7a96bad",
"",
"ots_nbot"
],
[
"p",
"bd4ae3e67e29964d494172261dc45395c89f6bd2e774642e366127171dfb81f5",
"",
"k."
],
[
"p",
"3bf0c63fcb93463407af97a5e5ee64fa883d107ef9e558472c4eb9aaaefa459d"
],
[
"r",
"wss://purplepag.es/"
],
[
"r",
"wss://relay.damus.io/"
],
[
"r",
"wss://relay.getalby.com/v1"
],
[
"r",
"wss://bevo.nostr1.com/"
],
[
"r",
"wss://nostr-pub.wellorder.net/"
],
[
"r",
"wss://nostr.wine/"
],
[
"r",
"wss://relay.primal.net/"
]
],
"content": "Haha - I think it might just be that a lot of people behind the scenes are really getting into DVMs and this PR caught everyone by surprise. Most of us would rather upgrade the existing NIP-90, than start over. \n\nYes, each DVM should publish their own documentation. If a DVM operator doesn’t keep theirs up to date, it's their loss. They are already responsible for keeping their DVM online and available.\n\nNip-89 is pretty neat. DVMs are mostly using Kind 31990 which says which job request kinds they accept. I recently added this to DVMDash, so that you can see which DVMs operate on which kinds. Most only operate on a single kind, but some DVMs like https://stats.dvmdash.live/dvm-stats/5fc48ac4765ff81e9c51014b9d2f2c91621370f4c6b5452a9c06456e4cccaeb4 support multiple kinds.\n\nIn the NIP-89 announcement, the 'content' field is stringified json, and then within that is a ‘nip90Params’ field that contains all the inputs that the DVM wants to receive in the 5xxx job request kinds. So for translation DVMs, you should give a ‘language’ param. Here’s a big analysis I just published covering which params are being used per 5xxx DVM kind: https://wikistr.com/dvm-announcement-analysis*da18e9860040f3bf493876fc16b1a912ae5a6f6fa8d5159c3de2b8233a0d9851\n\n\u003e re: nostr-data-vending-machines.org\n\nI'm personally not the biggest fan. It requires manual effort to keep up to date. I'd rather have clients that pull wiki events or kind 31990 events (nip-89) and show the actual documentation that the DVM owners published themselves. This is how I approached adding documentation per DVM kinds on DVMDash - I collected all the events on each DVM kind, generate a wiki doc with a brief description of the input and output, and then I link to these notes (really, dvmdash frontend pulls the wiki notes and displays them). Right now, if a new DVM came online under a new kind, and that DVM owner published a wiki event with a 'd' tag for 'kind:5xxx' where 5xxx is the kind they used, it should show up on DVMDash automatically.\n\nFor each DVM on DVMDash, it pulls data from their NIP-89 kind 31990 announcements for their description, etc.\n\nWhile DVM owners have been decently good about publishing NIP-89 announcements, they haven't been so good about other types of documentation (except Vertex). I want to encourage DVM owners to also publish a kind wiki if one doesn't exist, for how they expect it to operate if they are introducing it for the first time. We might also want to add a 3rd documentation page that's just about the DVM itself.\n\nSo really, every DVM operator should do the following:\n1. publish a NIP-89 kind 31990 announcement about the params they expect and kinds they support\n2. publish a wiki page about their DVM, including example inputs and outputs, a description, how much it costs, etc. AFAIK this hasn't really been done yet. data-vending-machines.org was a first attempt at a such a thing, but too centralized imo.\n3. (optional; for people making DVMs under new kinds) - write a kind wiki spec like what I've done here: https://njump.me/naddr1qvzqqqrcvgpzpkscaxrqqs8nhaynsahuz6c6jy4wtfhkl2x4zkwrmc4cyvaqmxz3qqykk6twvsar2vesxq02d424 - this is what is shown on https://stats.dvmdash.live/kind-stats\n",
"sig": "303c92aa6ae2bbde67c0aba412b6694079219fdb86eb43506df30b8dd46c8e6030309a123380eb97b2ec25a7576c8624873d1549165fe87fc2a1797ec3b5fdef"
}