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

Reply to this note

Please Login to reply.

Discussion

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