Nostr can act as a marketplace for data processing, where users request jobs to be processed in certain ways (e.g., "speech-to-text", "summarization", etc.), but they don't necessarily care about "who" processes the data.
This NIP is not to be confused with a 1:1 marketplace; instead, it describes a flow where a user announces a desired output, willingness to pay, and service providers compete to fulfill the job requirement in the best way possible.
*`job`: The output of a previous job with the specified event ID. The dermination of which output to build upon is up to the service provider to decide (e.g. waiting for a signaling from the customer, waiting for a payment, etc.)
*`<marker>`: An optional field indicating how this input should be used within the context of the job
*`output`: Expected output format. Different job request `kind` defines this more precisely.
*`param`: Optional parameters for the job as key (first argument)/value (second argument). Different job request `kind` defines this more precisely. (e.g. `[ "param", "lang", "es" ]`)
If the user wants to keep the input parameters a secret, they can encrypt the `i` and `param` tags with the service provider's 'p' tag and add it to the content field. Add a tag `encrypted` as tags. Encryption for private tags will use [NIP-04 - Encrypted Direct Message encryption](https://github.com/nostr-protocol/nips/blob/master/04.md), using the user's private and service provider's public key for the shared secret
Service providers publish job results, providing the output of the job result. They should tag the original job request event id as well as the customer's pubkey.
If the request has encrypted params, then output should be encrypted and placed in `content` field. If the output is encrypted, then avoid including `i` tag with input-data as clear text.
*`status` tag: Service Providers SHOULD indicate what this feedback status refers to. [Appendix 1](#appendix-1-job-feedback-status) defines status. Extra human-readable information can be added as an extra argument.
Any job feedback event MIGHT include results in the `.content` field, as described in the [Job Result](#job-result) section. This is useful for service providers to provide a sample of the results that have been processed so far.
Customers can give feedback about a job result back to the service provider via a `kind:7` from [NIP-25 - Reactions](https://github.com/nostr-protocol/nips/blob/8331354947f2d577e13eb5da4a56133071cb1019/25.md) with an additional `feedback` tag along with `e` and `p` tags that specifically refers to the note from which the DVM responded (the final result from the DVM).
*`content`: Feedback string to the service provider consistent with [NIP-25 - Reactions](https://github.com/nostr-protocol/nips/blob/8331354947f2d577e13eb5da4a56133071cb1019/25.md).
*`feedback`: Additional feedback that is outside the scope of [NIP-25 - Reactions](https://github.com/nostr-protocol/nips/blob/8331354947f2d577e13eb5da4a56133071cb1019/25.md). This could be a message from the user such as "worked but took too long", or a score in a custom range (i.e. a Likert scale score of 1-5 or 1-100). Best practice is to check if the NIP-89 of the DVM is asking for a preferred feedback format and request the user to enter feedback in that format. The preferred format of the DVM's feedback from the customer is stored in the `pff` tag of the NIP-89 event. DVMs may specify how they would like feedback when announcing themselves via [NIP-89 - Recommended Application Handlers](https://github.com/nostr-protocol/nips/blob/master/89.md). Keep in mind that a customer giving feedback may, in fact, be another DVM and not a human.
*`e`, `p`, `k`: tags that are defined in the [NIP-25 - Reactions](https://github.com/nostr-protocol/nips/blob/8331354947f2d577e13eb5da4a56133071cb1019/25.md) spec.
* At any point, if there is an `amount` pending to be paid as instructed by the service provider, the user can pay the included `bolt11` or zap the job result event the service provider has sent to the user
Job feedback (`kind:7000`) and Job Results (`kind:6000-6999`) events MAY include an `amount` tag, this can be interpreted as a suggestion to pay. Service Providers MUST use the `payment-required` feedback event to signal that a payment is required and no further actions will be performed until the payment is sent.
Customers can always either pay the included `bolt11` invoice or zap the event requesting the payment and service providers should monitor for both if they choose to include a bolt11 invoice.
The flow is deliberately ambiguous, allowing vast flexibility for the interaction between customers and service providers so that service providers can model their behavior based on their own decisions/perceptions of risk.
Some service providers might choose to submit a `payment-required` as the first reaction before sending a `processing` or before delivering results, some might choose to serve partial results for the job (e.g. a sample), send a `payment-required` to deliver the rest of the results, and some service providers might choose to assess likelihood of payment based on an npub's past behavior and thus serve the job results before requesting payment for the best possible UX.
A Customer MAY request multiple jobs to be processed as a chain, where the output of a job is the input of another job. (e.g. podcast transcription -> summarization of the transcription). This is done by specifying as input an event id of a different job with the `job` type.
Service Providers MAY begin processing a subsequent job the moment they see the prior job's result, but they will likely wait for a zap to be published first. This introduces a risk that Service Provider of job #1 might delay publishing the zap event in order to have an advantage. This risk is up to Service Providers to mitigate or to decide whether the service provider of job #1 tends to have good-enough results so as to not wait for an explicit zap to assume the job was accepted.
