IoT on Nostr - Thoughts on Event Structure, Privacy, and Efficiency

Summary

This article outlines an approach to handling IoT event data in Nostr, considering both ephemeral and non-ephemeral events. It discusses event structures, including types, units, and metadata tags, and suggests efficient ways to manage the size of data relayed through Nostr. The article also touches on the importance of maintaining privacy in IoT applications and addresses the potential challenges of scaling IoT data within the Nostr protocol.

Events

There are several possible approaches to structuring IoT event data. The following approach is being considered for use within Nostr:

Event Structure

Kind:
The NIP (Nostr Implementation Proposal) should define both ephemeral and non-ephemeral event kinds. While older NIPs defined kinds for each data type (e.g., 30106 for temperature), a more maintainable solution would be to have a single event kind with data types and units defined in event tags. This would simplify management while improving long-term maintainability.

Content:
The content field will typically contain data from IoT sensors, commands, or statuses. For example, a switch could have a value of 1 or 0, and a temperature reading might have a value like 20.

Tags:
Tags are essential for defining the data types, units, and additional metadata such as physical coordinates. These are some of the key tags:

• type (Required): Defines the type of data, such as intent, status, temperature, or light.
• unit (Optional): Describes the measurement unit, such as Celsius (°C), hectopascals (hPa), or lux.

Private Data

Using IoT on Nostr privately should be a priority. Following an approach similar to how Direct Message Volumes (DVMs) encrypt all data (as per NIP90) could work well. Encrypting IoT event data and possibly “giftwrapping” it could enhance privacy. However, this is currently out of the article’s scope and requires further investigation.

Ephemeral vs. Regular Events

One challenge with Nostr events is their size, especially when compared to IoT protocols like MQTT. A typical Nostr event, such as:

{"id":"072ec5876798efb182e9083464a7d6be41b2a0e46a8336db7c550eca173e1f9b","pubkey":"0987d97ee78e6a2281d2f45aedebc3d22da346a064850ca85440c2dd104badd4","created_at":1726123555,"kind":30107,"tags":[["type","pressure"],["unit","hPa"]],"content":"1005.78","sig":"a4d65dee6d2c9aed705acebaf2c8fd4ef3411126b8de472e9d03a2a94d420bb72a64fbc307146cac56abfa0b1716f001bbc1516b1ee48bc5fa955f6a1149f42d"}

is around 387 bytes. If a device sends this data to a public relay every 60 seconds, it would generate approximately 540 KB of data daily or 194 MB per year. If thousands of devices do this, relays could experience significant strain.

To address this, distinct IoT kinds could be defined for ephemeral and regular events—perhaps 20107 for regular events and 9107 for ephemeral ones. This would allow relay operators to manage event storage more effectively, possibly rejecting regular IoT events unless specifically subscribed to.

For ephemeral events, certain relays (e.g., strfry) persist the event for a limited time (typically 5 minutes) and remove it when a new event is published by the same pubkey. Defining ephemeral events would allow IoT devices to publish to public relays in a manner that doesn’t overwhelm the system. Third-party clients or relays could harvest and index these events for future querying.

Event Kinds

In Nostr, event kinds are divided as follows:

• Regular Events:
  1000 <= n < 10000 or 4 <= n < 45 or n == 1 || n == 2. These events are expected to be stored by relays.

• Ephemeral Events:
  20000 <= n < 30000. These are not expected to be stored by relays.

Conclusion

Managing IoT data on Nostr requires balancing the need for efficient data transmission with the constraints of relay storage. Distinguishing between ephemeral and regular events can help optimize relay usage. Future discussions on privacy and encryption strategies are essential to ensuring secure IoT implementations on Nostr.