NIP-107
======

Nostr Internet of Things 
-----------------------------------

`draft` `optional` `author:benarc` `author:blackcoffeebtc`

## 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 <a href="https://github.com/lnbits/arduino-nostr">nostr-arduino</a>


## 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 <a href="https://github.com/lnbits/arduino-nostr">nostr-arduino</a> 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) |


### Messages
JSON messages that represent different actions or states can be exchanged between two or more `devices` or between `users` and `devices`.
Each `JSON` message `MUST` have a `type` field indicating the what the JSON represents. Possible types:

| Message Type | Sent By        | Description      |
|--------------|----------------|------------------|
| 0            | User           | Configure Device |
| 1            | User \| Device | Command          |
| 2            | Device         | State Data       |

### Event: Configure `device`
This message is sent by a `user` to a `device`. The `device` saves the config locally and uses it.

**Event Content**:
```json
{
    "type": 0,
    "admin_pubkeys": [ [<String (optional), admin user public-key>]],
    "name": <String (optional), set a name for the device>,
    "description": <String (optional), device description>,
    "categories":[ <String (optional), device category, such as 'boiler'>],
    "send_to_pubkeys":[ [<String (optional), user public-key>]],
    "commands_from_pubkeys":[ [<String (optional), user public-key>]],
}
```

Note:
 - `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.
 - `users`:
   - a list that can restrict access to public-keys, `device`(s) also has keys and can be a `user`.

### Event: Update a `device`

**Event Content**:
```json
{
      "id": <String, UUID generated by the user. Sequential IDs (`0`, `1`, `2`...) are discouraged>,
    "device_id": <String, UUID of the stall to which this device belong to>,
    "settings":[ [<String (optional), user public-key>]]
}
```

Note:
 - `settings`:
   - Standard `settings` include:
   - eg: `[["on", <bool>], ["range", <int, 0-1000>], ["timer_on", <int unix timestamp>], ["timer_off", <int unix timestamp>]]`