I donāt like using kind 6xxx for both job results and schema definitions. Also, I donāt think we should be trying to solve privacy and schema definitions at the same time. Privacy needs a whole other angle, and I think itās important to keep a good flow without privacy for workflows that donāt need it (which also makes it easy for new devs to see whatās happening to start to participate). I have some other thoughts on privacy we should talk about sometimeā¦
What if, for DVM schema requests we used a kind number of an int + the kind request? Like 35300 instead of 5300? It really does feel like a separate flow, that should then kick off the actual DVM job request and result response. Overloading kinds only makes things way more complicated, especially for clients
Great point, yes absolutely. For the input schema requestā¦ do you think a new kind is needed? Or would just be per kind? Also, when you say ānot announceā you mean no NIP89 announcement?
I mean thereās gotta be something here right? RIGHT?!?!
if vibe coding continues to improve... will there be no more software developers? Or will every human have millions of lines of code for their own personal software stack?
Rather than rely on the clients to request schema from the DVM in step 2, we could encourage DVMs to advertise their schema when they respond to a job request. Right now, in most client to DVM flows that require payment, the DVM first responds with a kind 7000 payment request. In this same request (or in every kind 7000 request by the DVM) they could include their schema!
Dang I want my own blossom server now
Is it called pied piper?
Community call happening now, notes here: https://docs.proton.me/doc?mode=open-url&token=6EF99KK2MC#X51mPZctMCaZ
New wiki page for NIP-89 re: DVMs. If you've ever wondered what the average NIP-89 announcement json structure looks like, check this out. Gives stats for which fields are the most common. Excellent resource if you are making a new DVM for an existing kind and need to construct the 31990 event
Come chat DVMs at the DVMDash Community Call tomorrow @ 16:00 UTC (12pm EST) - Same link as last time
planning > RL
Any good list of Nostr events at Bitcoin 2025?
Ah sorry bout that, hereās the url https://stats.dvmdash.live/kind-stats
Been working on nostr:nprofile1qqs8gu5wq57ssw3vvvypy6lnecj4sn3s7htu3tcerjzfc3sgesqn0rspzemhxue69uhhyetvv9ujuurjd9kkzmpwdejhgqgnwaehxw309aexc7fwvfhhqmrw9e3k7mgan089y with a buddy, working on making it available via DVM. If you sign up on the site you can get 10k credits for free, donāt have Nostr login yet tho
Click any of those and it takes you to the wiki page, hereās one https://njump.me/naddr1qvzqqqrcvgpzpkscaxrqqs8nhaynsahuz6c6jy4wtfhkl2x4zkwrmc4cyvaqmxz3qqykk6twvsar2ve3x5hrwufy
Seeing DVM kinds with human readable names is such a big improvement, thanks nostr:nprofile1qqspw5udc2nzw6wsj3plrrphe0343744h0ucz9e4g248chl3w8kh03qpzemhxue69uhhyetvv9ujumn0wd68ytnzv9hxgqg4waehxw309ahx7um5wfjkc6t5v4ejummjvuktvpsr for suggesting this.
If youāre going to make a DVM for a new kind, please write a short wiki article like these! If you make the -d tag ākind:<5xxx>ā it will auto show on DVM Dash!
It's not fully flushed out.... but I was thinking about having an LLM guess at what the events might be for. Something like:
1. wait until dvmdash collects at least 50 events of the new type
2. send these events to an LLM and ask it to guess what the job type might be
3. Use the output from the LLM to write a new wiki page and publish to relays... then dvmdash will automatically pick it up and use the title of that wiki page.
All the existing documentation is via wiki pages that are sitting on relays.
I don't understand how computers work
Fun fact, this is adding a feature you requested a long time ago, human translations for DVM Kinds 
> be me
> add new feature
> test locally, works fine
> push to prod, doesn't work
> different browsers give different errors
> cant tell if bug is my code or library code
> ask llm, flip flops between bad solutions
> realize it's Monday
What do you think is a good flow for someone creating a DVM for a kind that doesn't exist yet?
1. They create their DVM and put it online
2. They create a NIP-89 announcement
3. They create a spec describing what it is, the input and output structure, and structure of in between events?
Kind 5300 is really the first DVM kind that's gained any significant traction. Next closest might be kind 5100 but that's died off.
What do you think about the DVM's spec being add to the NIP-89 announcement? Seems like a good place for it.
Finally, I'm working on a tool to help recommend what kind someone should use for a new DVM they want, and to create documentation on existing kinds. Here's an example of such documentation
Sir, this is a decentralized protocol
That was quite a turnaround, great job!
What can we do to cross that final barrier of having the invoice automatically load into the nwc wallet and have the LLM send the money along?
I also found these repos:
https://github.com/getalby/nwc-mcp-server
https://github.com/getAlby/lightning-tools-mcp-server
https://github.com/AbdelStark/nostr-mcp
I think you are really close to delivering some great functionality to this MCP server... Some other functionalities that I think would open up a ton of creative use cases would be:
1) Follow a group of users that already follow an account
2) Zap one or a group of users
3) DM one or a group of users
4) Detect specific engagement types on a specific nostr note
5) Keyword search a bunch of nostr notes and zap them accordingly
6) Publish data to nostr in the form of a note
7) unfollow one or a group of users
8 ) like certain notes fitting certain keywords
9 ) send payment to a lightning address
If you can create an MCP that can do these things and more... it could start becoming really powerful.
A buddy and I built to https://memeulacra.com to see if we can get AI make funnier memes than supermeme.ai - I can give you a bunch of credits if you want to try it out. Still pretty early tho, Nostr features incoming