They are. They are all forced to use NIP-04, for instance. So, nobody can migrate to NIP-44 because we don't have approval from devs of these less used kinds. NIP-90 forces kind ranges, which blocks any DVM from being replaceable or ephemeral. Error messages are all the same, even though each DVM has their own error types. Job chaining has never been used. The `bid` system doesn't make any sense. The generic input and outputs designs can be massively simplified in each kind. They don't need to use `i` and `param`. They could just have their own tag names.
Discussion
💯% agree. Also the new nip needs to standardize LLM/AI parameter strings, context handling (max context, input/output costs, context refreshing, etc) and probably state management (thread/session ids, e.g. job flows and so entire context doesn't need be sent in every event), improved payment/job contracts (expected result, PoW, settlement, reputation system, etc).
You should write a NIP for LLM DVMs, rob. Make it from scratch without only the things that matter to LLMs
Here's a first draft of [agents](https://github.com/toadlyBroodle/nips/blob/agents/agents.md ) NIP specifically for LLMs and other agents
First, this is pretty great at an initial glance. This is a nice update for how kind 5050 DVMs should work.
This is not replacing the whole of NIP-90 DVMs which is something else (and that’s fine). DVMs are async “API calls” without timeouts or api-keys in a marketplace like manner using Nostr events.
Possible warning, having this “New tags can be proposed for future needs.” seems to prevent it to being eligible to be added to the nips repo because it leaves too much room to be open. (Mostly sarcasm from me, maybe actually true for others)
this morning i saw this https://github.com/synvya/sdk
Thanks for sharing, will be curious to see how that develops
The other thing is, it would be much better to use a single word like “LLM” or “service” here
“AI (Agent): A Nostr pubkey (typically an automated agent, service, or bot)”
- bot is useless for any meaningful conversation (it’s not specific in any way)
- agent has a similar problem, and this whole flow you’ve described is really specific to language based models that go back and forth in a conversation like style. If you are primarily thinking of adopting the OpenAI standard (which is great) it would be clearer to say something not “agent” or “bot”