nips/107.md

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. A user can publish these event kinds:

Kind		Description	NIP
8000	intent	Trigger an action on a device	NIP-91 Event Kinds

The content of events can be transmitted in clear text (for public data) or as NIP-59 Gift Wrap.

Intent Events

Intent Events represent different actions that can be performed on a 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:

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