Added addressable kind range and spontaneous job results

90.md

@@ -11,16 +11,19 @@ This NIP defines the interaction between customers and Service Providers for per
 Money in, data out.
 
 ## 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            |
-| ----      | -----------       |
+|-------------|------------------------|
 | 5000-5999   | Job request kinds      |
 | 6000-6999   | Job result             |
 | 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`).
 
+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).
 
 ## 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.
 
+A spontaneous job result does not need to include `request`, `e`, `i` or `p` tags.
+
 ```jsonc
 {
   "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
 
@@ -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.
 * 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.