NIP-107
======
Nostr Internet of Things
-----------------------------------
`draft` `optional` `author:benarc` `author:blackcoffeebtc` `author:motorina0`
## Rationale
The terms/conditions of IoT software/hardware is horrible. A user should be able to message a light or heating system and ask it to turn on/off. Nostr gives the simple, permissionless development environment IoT needs.
## Terms
- `user` - user operating IoT devices with NOSTR key-pair and a client made specifically for IoT
- `device` - device to operate over Nostr with NOSTR key-pair, using a microcontroller client like nostr-arduino
## Nostr IoT Clients
### User
Where the `user` registers 'device'(s) and its keys, then updates the `device`(s).
### Device
The `device` uses a client like nostr-arduino to receive commands from the `user` or another `device`.
The `device` can also push data such as sensor readings and updates.
## Events
A `device` can publish any of the events described in [NIP-91 Event Kinds](https://github.com/nostr-protocol/nips/blob/iot/91.md#event-kinds).
A `user` can publish these event kinds:
| Kind | | Description | NIP |
|--------|----------|-------------------------------|-----------------------------------------------------------------------------------------|
| `8000` | `intent` | Trigger an action on a device | [NIP-91 Event Kinds](https://github.com/nostr-protocol/nips/blob/iot/91.md#event-kinds) |
The content of events can be transmitted in clear text (for public data) or as [NIP-59 Gift Wrap](https://github.com/staab/nips/blob/NIP-59/59.md).
## Intent Events
Intent Events represent different actions that can be performed on a device. These actions can be triggered by a `user` or by another `device`. The content of the event is a `JSON` which `MUST` have a `type` field indicating the what the JSON represents. Possible types:
| Message Type | Sent By | Description |
|--------------|----------------|------------------|
| 0 | User | Configure Device |
### Configure Device
This message is sent by a `user` to a `device`. The `device` saves the config locally and then uses it.
**Event Content**:
```json
{
"type": 0,
"name": ,
"description": ,
"categories":[ ],
"admin_pubkeys": [ []],
"publish_to_pubkeys":[ []],
"intents_from_pubkeys":[ []],
"publish_on_change": ,
"publish_interval":
}
```
| Field | Description |
|---|---|
| `admin_pubkeys` | List of public keys that are allowed to configure this device.
A fresh/blank device will not have this value, so the first received `"type: 0"` should set it.
The `admin_pubkeys` implicitly have the `actions_from_pubkeys` permissions. |
| `publish_to_pubkeys` | List of public keys to which events are published. |
| `actions_from_pubkeys` | List of public keys that are allowed to trigger an action on this device.
The `admin_pubkeys` implicitly have the `actions_from_pubkeys` permissions. |
### Event: Update a `device`
**Event Content**:
```json
{
"id": ,
"device_id": ,
"settings":[ []]
}
```
Note:
- `settings`:
- Standard `settings` include:
- eg: `[["on", ], ["range", ], ["timer_on", ], ["timer_off", ]]`