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!
Discussion
Hey yes! This could be a way, but I think it's worth clarifying some points.
From my perspective, a job request occurs when you already know the schema for the input parameters, allowing you to request a job. This implies that to make a job request, you should somehow have access to the schema beforehand, right?
At this point, responding with the schema in either kind 7000 or 6xxx is essentially the same. I think that to bootstrap the process, dvms can announce their schema, using nip89 announcement (or potentially other nip). Users can then discover these announcements and be ready to make job requests.
Another approach (and this is how I'm framing it for DVMCP) is that DVMs may choose not to announce themselves, perhaps because they're private and not intended to offer a "public" service. In this case, they would listen for input schema request, or for job requests if the user already knows the schema beforehand. WDYT?
Great point, yes absolutely. For the input schema request… do you think a new kind is needed? Or would just be per kind? Also, when you say “not announce” you mean no NIP89 announcement?
Hmm... I think the most logical flow would be per kind, reusing the req/res kinds of each job type, so in this way you will request the input schema from a dvm using its 5xxx req kind and it will respond in its 6xxx, the request can contain a standardized method to request the input schema so clients will know how to request this schema on any dvm. This is also more private than creating a new kind just for req res input schema, since this will look like a normal operation.
And yes, the dvm can choose not to announce itself publicly, so no nip89, this is something I am also introducing for the revised dvmcp spec.
wdyt? Someone should draft this to potentially upgrade nip90
I don’t like using kind 6xxx for both job results and schema definitions. Also, I don’t think we should be trying to solve privacy and schema definitions at the same time. Privacy needs a whole other angle, and I think it’s important to keep a good flow without privacy for workflows that don’t need it (which also makes it easy for new devs to see what’s happening to start to participate). I have some other thoughts on privacy we should talk about sometime…
What if, for DVM schema requests we used a kind number of an int + the kind request? Like 35300 instead of 5300? It really does feel like a separate flow, that should then kick off the actual DVM job request and result response. Overloading kinds only makes things way more complicated, especially for clients