nostr/nips
1
0
Fork 0
mirror of https://github.com/nostr-protocol/nips.git synced 2024-12-22 08:25:53 -05:00
Code Issues Actions Packages Projects Releases Wiki Activity

Added addressable kind range and spontaneous job results

Browse Source
This commit is contained in:
blackcoffeexbt 2024-10-25 11:57:30 +01:00
parent e3afd7ac5b
commit c8adf34534
1 changed files with 36 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

46
90.md
View File

@ -11,16 +11,19 @@ This NIP defines the interaction between customers and Service Providers for per
Money in, data out. Money in, data out.
## Kinds ## Kinds
This NIP reserves the range `5000-7000` for data vending machine use. This NIP reserves the range `5000-7000` and `36107` for data vending machine use.
| Kind | Description | | Kind | Description |
| ---- | ----------- | |-------------|------------------------|
| 5000-5999 | Job request kinds | | 5000-5999 | Job request kinds |
| 6000-6999 | Job result | | 6000-6999 | Job result |
| 7000 | Job feedback | | 7000 | Job feedback |
| 36000-36xxx | Addressable job result |
Job results always use a kind number that is `1000` higher than the job request kind. (e.g. request: `kind:5001` gets a result: `kind:6001`). Job results always use a kind number that is `1000` higher than the job request kind. (e.g. request: `kind:5001` gets a result: `kind:6001`).
Addressable job results always use a kind number that is `31000` higher than the job request kind. (e.g. request: `kind:5107` gets a result: `kind:36107`).
Job request types are defined [separately](https://github.com/nostr-protocol/data-vending-machines/tree/master/kinds). Job request types are defined [separately](https://github.com/nostr-protocol/data-vending-machines/tree/master/kinds).
## Rationale ## Rationale
@ -102,6 +105,8 @@ This param data will be encrypted and added to the `content` field and `p` tag s
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. 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.
A spontaneous job result does not need to include `request`, `e`, `i` or `p` tags.
```jsonc ```jsonc
{ {
"pubkey": "<service-provider pubkey>", "pubkey": "<service-provider pubkey>",
@ -118,9 +123,30 @@ Service providers publish job results, providing the output of the job result. T
} }
``` ```
* `request`: The job request event stringified-JSON. ## Addressable job result (`kind:36107`)
* `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. Addressable events can be used for DVM results which contain data that a relay does not necessarily need to store. For example, data from IoT devices can be reasonably
high frequency and storing multiple results from the same device per day may not be necessary.
A spontaneous addressable job result does not need to include `request`, `e`, `i` or `p` tags.
The d tag can have any value, but using a human-readable string such as "iot-device-123-event-8333" can improve usability.
```jsonc
{
"pubkey": "<service-provider pubkey>",
"content": "<stringified-json-array>",
"kind": 36xxx,
"tags": [
["request", "<job-request>"],
["e", "<job-request-id>", "<relay-hint>"],
["i", "<input-data>"],
["p", "<customer's-pubkey>"],
["amount", "requested-payment-amount", "<optional-bolt11>"]
["d", "<unique-string>"]
],
}
```
## Encrypted Output ## Encrypted Output
@ -187,7 +213,7 @@ Any job feedback event MIGHT include results in the `.content` field, as describ
* Upon completion, the service provider publishes the result of the job with a `kind:6000` job-result event. * Upon completion, the service provider publishes the result of the job with a `kind:6000` job-result event.
* 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 * 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. Job feedback (`kind:7000`) and Job Results (`kind:6000-6999` or `kind:36000-36999`) 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. 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.