better replacement is rest api, graph ql, grpc, json rpc and...
but i agree that we need to keep the spec somewhere else as archive.
nostr:nprofile1qqsrhuxx8l9ex335q7he0f09aej04zpazpl0ne2cgukyawd24mayt8gprfmhxue69uhkcmmrdd3x77pwve5kzar2v9nzucm0d5hszxmhwden5te0wfjkccte9emk2um5v4exucn5vvhxxmmd9ux73xm6 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.
Discussion
how would it be better? I have looked far and wide and can't find anything simpler than Nostr DVMs, so I am skeptical by what you mean by "better"
its known. any body can use it. there is 1000000 of libraries and developers using them. we can use them on nostr as well. we already have a lot or more experience with them. they rely on proper well-defined and battle tested protocols.
how would it work natively with Nostr? How would they advertise themselves? Could they communicate over Nostr events sent via relays, or is it a lower level protocol like https, websockets, etc? If the communication is not happening over Nostr (and instead relies on https, websockets, etc) why even user Nostr to begin with?
I think that as soon as you start to try building any of those protocols on Nostr, you'll realize you either need to offload communication from Nostr events or it will be more complicated than some of the existing DVM flows.
The DVM spec is flexible though, so if it is possible to do any of those, asynchronously, then maybe you could get it to work, but I bet it would be complicated than some of the ones we have now (like 5300 for example).
Okay I just dived into this a bit more and.... RPC looks a lot like what we already are doing, so I'd be curious what you feel is missing from DVMs that doesn't support this.