mirror of
https://github.com/nostr-protocol/nips.git
synced 2024-12-23 08:55:52 -05:00
87 lines
3.5 KiB
Markdown
87 lines
3.5 KiB
Markdown
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 <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) |
|
|
|
|
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.
|
|
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 |
|
|
|
|
### 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>]]`
|