Summary

This article outlines an approach to handling IoT event data in Nostr, considering both replaceable and regular 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 replaceable and regular event kinds. Previous PRs for IoT on Nostr NIPs defined kinds for each data type (e.g., 30106 for temperature), a more maintainable solution would be to have a limited number of kinds 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 that could be used:

• ["l", "type", "[data-type]"]. Describes the type of data, where [data-type] could be for example intent, status, temperature, or light.
• ["unit", "[unit-name]"]. Describes the measurement unit where [unit-name] is for example "celsius" (°C), "hectopascal" (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.

Replaceable 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":[["l","type","pressure"],["unit","hectopascal"]],"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 replaceable and regular events—perhaps 30107 for replaceable events and 9107 for regular events. This would allow relay operators to manage event storage more effectively, possibly rejecting regular events that originate from npubs that are not subscribed to a paid relay.

For replaceable events, relays will persist the event and replace it with a new event that is published by the same pubkey with the same kind and d tag. Defining replaceable events would allow IoT devices to publish to public relays in a manner that doesn't abuse the relay. Third-party clients or relays could "harvest" these events in real time and index them for future processing.

Example REQ for data queries

Using tags in the manner described above, querying a relay for specific information could be done with a request similar to the one shown below:

["REQ", "TMBl2WOTX5oMI8ngKKwzBhpONaH8ahanYFM0DUDmspxQ3Sf9K06zqztjTwYLV2Ul0",{"kinds": [30107], "authors": ["d0bfc94bd4324f7df2a7601c4177209828047c4d3904d64009a3c67fb5d5e7ca"], "#l": ["type", "temperature"], "limit": 2}]

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.

• Parameterised replaceable
  30000 <= n < 40000, These events are parameterised replaceable, which means that, for each combination of pubkey, kind and the d tag's first value, only the latest event MUST be stored by relays, older versions MAY be discarded.

Conclusion

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