nips/107.md

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 and ask it to turn on/off. Nostr gives the simple, permissionless development environment IoT needs.

All communication happens over NIP04.

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 or a user can publish these event kinds:

Kind		Description	NIP
4	direct_message	Communicate between two devices or between a device and a user. The messages must be a JSON following the structures defined In this NIP.	NIP04

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:

{
    "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:

{
      "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>]]