Nostr Web Client

If you think that sounds weird, wtf is he talking. Yes, that's the NIP90 debate right now on git.

And I even really share that this nip is useless in it's current state given how clients interop right now. 🫠 But we don't talk about this. Because whatever.

Bennu Breath 𓅣 8mo ago

Yes, confirmed. DMs don't work reliably.

Tim Bouma 8mo ago

I hacked together my own spec for which I am calling private channels for inter-api communication. Took the best from NIP17 NIP44 and gift wrapping. So far so good. Once I am happy , will share.

I know 100s of people that post on public kinds and they never show up to anyone else too :)

Nostr is messy. Most people don't notice because they are yelling at the void. They just think it was a bad post. But in fact, no one saw it.

DMs require reply. Which creates LOTs of issues that users are not ready for, like the quality and consistency of their own relays.

Also, I think you should write a DVM NIP.

Glad you understand the reference.

I made 5 or 6 suggestions to NIP90 that just stalled. Kind of not the motivation to improve the unclear things if nothing ever gets considered.

I'm currently supporting Dustin and others to write that new version of the nip, independent of if it makes it to the repo or not. Or if it gets killed of or not.

I also don't have any issue with improving the nip from it's current form, as mentioned before I'm not happy with everything there. But I'm also not happy with how this whole thing is being considered atm. And this note is how the discussion looks like to me. (But Dms actually really are an issue tho lol)

Cool, keep it simple.

Things are not being considered because everybody thinks NIP-90 is something different. And that sucks. It's too broad.

Doesn’t the activity on DVMDash kind of show it’s not useless for everyone? I know it’s still small, but people have been muddling through with the existing nip 90 and reverse engineering what’s being sent on relays. I think better documentation solves 80%

Some DVMs are great and very well used (like content discovery). Others are useless (like event counts - Last seen in 2023).

You can't bundle them all in one thing. Useless ones must disappear from the spec.

But they aren't. They have their own kinds. The generic flow is really simple.

Request - status (like payment request) - response.

Thats the generic "useless" description.

Everything else is documented in the other repo for specifics

Are they really “bundled” tho? Individual DVM kinds are like bubbles that form and may pop, and someone can come along and use those kinds again later. Right now, they aren’t “in” the spec anywhere except maybe it was using one of the reserved kinds.

The pattern of DVMs does feel different enough from other kinds of Nostr events

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.

robdev 8mo ago

💯% 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

robdev 7mo ago

Here's a first draft of [agents](https://github.com/toadlyBroodle/nips/blob/agents/agents.md ) NIP specifically for LLMs and other agents

Dustin Dannenhauer 7mo ago

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)

il_lost_ 7mo ago

this morning i saw this https://github.com/synvya/sdk

Dustin Dannenhauer 7mo ago

Thanks for sharing, will be curious to see how that develops

Dustin Dannenhauer 7mo ago

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”