From 68e5d0ada427a5d4783b8727cd2334a6b3a5e89f Mon Sep 17 00:00:00 2001 From: Yoji Shidara Date: Wed, 20 Aug 2025 01:11:14 +0900 Subject: [PATCH] NIP-90: Fix heading levels (#2033) --- 90.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/90.md b/90.md index 785b539c..e39ce904 100644 --- a/90.md +++ b/90.md @@ -68,7 +68,7 @@ All tags are optional. * `relays`: List of relays where Service Providers SHOULD publish responses to * `p`: Service Providers the customer is interested in. Other SPs MIGHT still choose to process the job -## Encrypted Params +### Encrypted Params 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](04.md), using the user's private and service provider's public key for the shared secret @@ -122,7 +122,7 @@ Service providers publish job results, providing the output of the job result. T * `amount`: millisats that the Service Provider is requesting to be paid. An optional third value can be a bolt11 invoice. * `i`: The original input(s) specified in the request. -## Encrypted Output +### Encrypted Output 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. Add a tag encrypted to mark the output content as `encrypted` @@ -180,7 +180,7 @@ Service providers can give feedback about a job back to the customer. Any job feedback event MIGHT include results in the `.content` field, as described in the [Job Result](#job-result-kind6000-6999) section. This is useful for service providers to provide a sample of the results that have been processed so far. -# Protocol Flow +## Protocol Flow * Customer publishes a job request (e.g. `kind:5000` speech-to-text). * Service Providers MAY submit `kind:7000` job-feedback events (e.g. `payment-required`, `processing`, `error`, etc.). @@ -191,24 +191,24 @@ Job feedback (`kind:7000`) and Job Results (`kind:6000-6999`) events MAY include 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. -## Notes about the protocol flow +### Notes about the protocol flow 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. It's not up to this NIP to define how individual vending machines should choose to run their business. -# Cancellation +## Cancellation A job request might be canceled by publishing a `kind:5` delete request event tagging the job request event. -# Appendix 1: Job chaining +## Appendix 1: Job chaining 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. This gives a higher level of flexibility to service providers (which sophisticated service providers would take anyway). -# Appendix 2: Service provider discoverability +## Appendix 2: Service provider discoverability Service Providers MAY use NIP-89 announcements to advertise their support for job kinds: ```jsonc