The gossip model and NIP-89 share the same core principle: dynamic discovery. In the gossip model, clients find users by following their published relay lists, connecting to the minimum necessary relays to reach everyone you follow. Similarly, NIP-89 enables discovery of applications (including DVMs) that handle specific event kinds, ensuring smooth cross-client interactions. Both eliminate centralized gatekeepers by letting users publish their preferences for others to find - whether it's relays or application handlers.

My rebuttal to the deletion of NIP-90 (DVMs) spec:

GitHub

reset the DVM spec by fiatjaf · Pull Request #1903 · nostr-protocol/nips

All these people hating on DVMs and they ain’t suggesting anything better. Meanwhile, suggestions to improve NIP-90 haven’t been merged forever.

@fiatjaf why delete something that’s gaining momentum? We’re already past 4 million DVM events, kind 5300 is crushing it, and deleting the spec without recommending anything better doesn’t help. https://stats.dvmdash.live/kind-stats Each DVM kind can have its own flow, NIP-90 flow is a suggestion, not a requirement.

How do you get your news?

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!

Community call happening now, notes here:

Proton Docs

Edit documents in real time, fully end-to-end encrypted.

View quoted note →