Another run at the DVM re-write

[staab]

This revision is fully compatible with the previous non-spec. A specification for kind 5300 discovery flows is included for illustration. Reverse-engineering and documenting existing specs is left as an exercise for the reader.

[fiatjaf]

This is what we need.

[pippellia-btc]

I think this spec could lose a bit in abstraction but a lot in usability and incentivize more convergence of flows by:

• adding a json input schema in the DVM announcement
• passing input parameters in the request content as json

The benefits are:

• clients can validate parameters before sending
• clients can display a general input interface derived by the DVM schema (extract the name of the params, the types, the enums...)
• service providers can extend the functionalities with optional parameters without changing flow.

The last point imo is particulary important for interoperabilty. In the current scheme, service providers would all point to their own docs because they control it (like with http APIs). Instead, they could point to a flow X, and then in the schema they can extend it.

For example, I want to offer a image generation DVM. I want to follow the most popular flow for that, but I want to add one parameter (e.g. aspect ratio). Without the input schema, I would have to create a documentation for a new flow, so I might as well do it completely differently. This would discourage interoperability, because you either follow exactly one spec or abandon it.

[staab]

If providers diverge, they lose access to clients that have implemented a given flow. This is enough to encourage collaboration on specs, just like how NIPs work. Optional custom parameters are probably only going to be useful in advanced use cases, since generating forms based on schemas is inherently bad UX. But you're probably right that it's useful, and should be safe in terms of one provider dominating a spec through custom extensions (as long as client developers are smart, which isn't a given). I've added it as an optional parameter.

[pippellia-btc]

If providers diverge, they lose access to clients that have implemented a given flow. This is enough to encourage collaboration on specs, just like how NIPs work

Do NIPs work? Most PRs are buried in this repo and will never get merged.

I've added it as an optional parameter.

Thanks. I see it's for the optional parameters only, which I think it's a mistake, as an optional parameter may be supplied only if a required parameter is of a certain type. So logic like anyOf, oneOf, dependentRequired and so on...

For this reason, imo params should include the whole JSON schema.

[staab]

Do NIPs work? Most PRs are buried in this repo and will never get merged.

Mostly because the people who draft them never follow up to let anyone know that they've been implemented. NIPs work pretty well all things considered.

Thanks. I see it's for the optional parameters only, which I think it's a mistake

What happens if the parameters schema diverges from the spec? Also, I realized that parameters assumes a request, which as I mentioned in #1941 may not always be the case. I think including them assumes too much about the structure of a given flow. Removed them again, sorry.

[vitorpamplona]

Are we sure about having one kind 31999 to describe all the different service providers? What happens when some service cannot be described by it? Shouldn't each DVM type have its own way to declare who they are with as much info as they need?

For the sake of interoperability, this NIP should have a table with all valid labels for the "flow identifier" if these are not just kind numbers for the request payload.

[vitorpamplona]

Do NIPs work?

It depends on what you think NIPs are. NIPs just describe how people currently use Nostr. If you think they are dictating how to use Nostr, then you are going to have a very bad time. Lots of NIP PRs are just wishful thinking that no one implements.

[staab]

We have to draw the line somewhere, with the extremes being one kind for all providers, and one kind per flow. One kind per flow doesn't make sense, because the flow has to be identified somehow, and since we have the n tag identifying the flow, one kind is enough. I get @pippellia-btc's point that additional tags on the announcement may be desirable. But instead of defining a bunch of different kinds and attempting to categorize dvms (the semantic web strikes again), I think it's better to just define those additional tags in the flow documentation. Updated the PR to that effect.

[staab]

For the sake of interoperability, this NIP should have a table with all valid labels for the "flow identifier" if these are not just kind numbers for the request payload.

That's sort of at the bottom. There's only one flow defined, SP-01. More PRs can add more flows, defined either inline or in a table with a reference to whatever URL/NIP/thing it's defined in.

[vitorpamplona]

I would add required Heartbeat Events as designed by #1941, since it is likely that we will have lots of old kind 31999s when we search for active DVMs

[staab]

They can't be required, since legacy DVMs don't send them. But I can suggest them.

[alexgleason]

I like this version. Rebranding as a Service Provider and making the flow customizable solves a lot of the problems.

[dtdannen]

The most important thing is that there is a single kind for announcing DVMs. So using kind 31999 for all DVM announcements is good enough, and the DVM ecosystem can still live on and flourish.

I like that there can be extra tags, like documentation. That's super important, because the flows described in this document will always lag significantly behind actual DVM activity. But folks can just check documentation tags or worst case reverse engineer from relay events like they have been doing (and the reason I started DVMDash in the first place).

[dtdannen]

@staab what do you think about @vitorpamplona 's suggestion to make this something like NIP-9A instead of replacing NIP-90, for posterity? I think that's a better way to move forward, since people are still using original DVMs.

[staab]

There are always room for new, non-interoperable standards on nostr. But 90 still needs to be re-written.

[alexgleason]

As I've been working on building an NSP according to this spec, I'm starting to think what I really need is Nostr RPC, and for the NSP to maybe produce events at the end.

The original DVM spec, NIP-46, and NIP-47 are basically all just RPC events, with no standard flow tying them together. It would be nice if we could create a single NostrRPC class and do all three with it, by simply changing the kinds and/or parties.

[dtdannen]

@alexgleason you may find #1941 helpful if you want to write a NostrRPC spec. I'm curious what you think is missing or needs to be different compared to this PR or PR 1941. If this PR doesn't prevent what you're thinking, that could become NSP-02?

[dtdannen]

@staab why does it have to be rewritten? Because it doesn't match what current DVMs are doing? If old DVMs are still using NIP-89 and kinds 5000-7000, shouldn't we preserve the current spec since it's descriptive of what's happening today?

[staab]

From #1941 (comment):

These different cases can't be supported by a single infinitely-flexible NIP, because that's just a quest for the universal language (which we already have, it's called computation). But all of them would benefit from the service provider being able to 1. specify the flow, 2. publish a listing advertising their service. The specifications for these flows might be DIPs, NUDs, URLs, or NIPs, it doesn't really matter on what level they're defined.

The current spec is over-prescriptive, while also trying to be infinitely flexible. The effect is that people who read it think DVMs are one thing, when they're actually many things. There is no useful pattern common to all DVMs (even if we arbitrarily limit the term to request/response flows), except a listing event which connects a kind with a spec.

NIP 89 is currently used for this, but it doesn't actually work because it overloads the same event with "clients" and "services". A DVM cannot be a "handler" in the sense NIP 89 means it. Does a "handler" for a kind 5300 mean a DVM that responds to that kind, or a client which can interact with a DVM that responds to that kind? Currently, it means the former, which means clients can't advertise themselves as handlers for that event kind without confusing everyone. Luckily, it's easy to publish new listing events, making the migration relatively easy (not that people will).

So, to summarize, two things are going on here: 1. removal of meaningless and misleading details that don't affect implementation at all (since DVMs have their own spec anyway, and also most DVMs don't follow the spec), and 2. the addition of a listing event. The first seems like a no brainer, the second may never be adopted because people (especially Primal) probably don't care enough to re-list. That being the case, I'll split this up into two PRs.

[staab]

Eh, nevermind, I just tried it and the result is an empty spec. This PR really only defines the new listing kind and a basic definition of a DVM with no details.

[dtdannen]

There's an issue with what the NIP-90 should contain. Even if it causes some problems for clients, uses NIP-89, etc. the reality is that a bunch of people still made DVMs and supported DVMs in clients, and some of those are still running. So why don't we just leave it as it and everything new, that fixes the problems with original NIP-90, and as far as I know is prescriptive for the time being, becomes a new NIP? Or we should update this PR to include all the existing DVM flows as new NSPs.... which I could do actually. @staab what do you think? I see you did it for 5300, we could do it for all the other ones https://stats.dvmdash.live/kind-stats

[staab]

The kind 5300 example is mostly just illustrative. We could maybe bring in the most commonly used specs, but I do like the idea of data-vending-machines.com or some external repository that holds DVM definitions. If you want to contribute a few more definitions I can add them to this PR.

RE: the new listing event, I've added a clarification that suggests supporting NIP 89 listings for compatibility. Adding a new recommendation event violates the "two ways to do something" rule, but doesn't break compatibility. Which means this PR is entirely additive, and we should wait to merge it until there are the requisite implementations.