NIP-91 IoT skeleton.

* rework nip-03 to be actually useful and usable.
* fixes.
* add ots verification flow.

01.md

@@ -82,12 +82,14 @@ Kinds specify how clients should interpret the meaning of each event and the oth
 And also a convention for kind ranges that allow for easier experimentation and flexibility of relay implementation:
 
 - for kind `n` such that `1000 <= n < 10000`, events are **regular**, which means they're all expected to be stored by relays.
-- for kind `n` such that `10000 <= n < 20000 || n == 0 || n == 3`, events are **replaceable**, which means that, for each combination of `pubkey` and `kind`, only the latest event is expected to (SHOULD) be stored by relays, older versions are expected to be discarded.
+- for kind `n` such that `10000 <= n < 20000 || n == 0 || n == 3`, events are **replaceable**, which means that, for each combination of `pubkey` and `kind`, only the latest event MUST be stored by relays, older versions MAY be discarded.
 - for kind `n` such that `20000 <= n < 30000`, events are **ephemeral**, which means they are not expected to be stored by relays.
-- for kind `n` such that `30000 <= n < 40000`, events are **parameterized replaceable**, which means that, for each combination of `pubkey`, `kind` and the `d` tag's first value, only the latest event is expected to be stored by relays, older versions are expected to be discarded.
+- for kind `n` such that `30000 <= n < 40000`, events are **parameterized 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.
 
 In case of replaceable events with the same timestamp, the event with the lowest id (first in lexical order) should be retained, and the other discarded.
 
+When answering to `REQ` messages for replaceable events such as `{"kinds":[0],"authors":[<hex-key>]}`, even if the relay has more than one version stored, it SHOULD return just the latest one.
+
 These are just conventions and relay implementations may differ.
 
 ## Communication between clients and relays

03.md

@@ -4,20 +4,33 @@ NIP-03
 OpenTimestamps Attestations for Events
 --------------------------------------
 
-`draft` `optional` `author:fiatjaf`
+`draft` `optional` `author:fiatjaf` `author:constant`
 
-When there is an OTS available it MAY be included in the existing event body under the `ots` key:
+This NIP defines an event with `kind:1040` that can contain an [OpenTimestamps](https://opentimestamps.org/) proof for any other event:
 
-```
+```json
 {
-  "id": ...,
+  "kind": 1040
-  "kind": ...,
+  "tags": [
-  ...,
+    ["e", <event-id>, <relay-url>],
-  ...,
+    ["block", <block-height-as-string>, <block-hash>],
-  "ots": <base64-encoded OTS file data>
+    ["alt", "opentimestamps attestation"]
+  ],
+  "content": <base64-encoded OTS file data>
 }
 ```
 
-The _event id_ MUST be used as the raw hash to be included in the OpenTimestamps merkle tree.
+- The OpenTimestamps proof MUST prove the referenced `e` event id as its digest.
+- The `block` tag is optional, it exists to establish a minimum date since which the given event has existed.
+- The `content` MUST be the full content of an `.ots` file containing at least one Bitcoin attestation. This file SHOULD contain a **single** Bitcoin attestation and no reference to "pending" attestations since they are useless in this context.
 
-The attestation can be either provided by relays automatically (and the OTS binary contents just appended to the events it receives) or by clients themselves when they first upload the event to relays — and used by clients to show that an event is really "at least as old as [OTS date]".
+### Example OpenTimestamps proof verification flow
+
+Using [`nak`](https://github.com/fiatjaf/nak), [`jq`](https://jqlang.github.io/jq/) and [`ots`](https://github.com/fiatjaf/ots):
+
+```bash
+~> nak req -i e71c6ea722987debdb60f81f9ea4f604b5ac0664120dd64fb9d23abc4ec7c323 wss://nostr-pub.wellorder.net | jq -r .content | ots verify
+> using an esplora server at https://blockstream.info/api
+- sequence ending on block 810391 is valid
+timestamp validated at block [810391]
+```

07.md

@@ -33,3 +33,4 @@ async window.nostr.nip04.decrypt(pubkey, ciphertext): string // takes ciphertext
 - [AKA Profiles](https://github.com/neilck/aka-extension) (Chrome, stores multiple keys)
 - [TokenPocket](https://www.tokenpocket.pro/) (Android, IOS, Chrome and derivatives)
 - [Nostrmo](https://github.com/haorendashu/nostrmo_faq#download) (Android, IOS)
+- [Spring Browser](https://spring.site) (Android)

25.md

@@ -7,7 +7,7 @@ Reactions
 
 `draft` `optional` `author:jb55`
 
-A reaction is a `kind 7` note that is used to react to other notes.
+A reaction is a `kind 7` event that is used to react to other events.
 
 The generic reaction, represented by the `content` set to a `+` string, SHOULD
 be interpreted as a "like" or "upvote".
@@ -34,6 +34,9 @@ The last `e` tag MUST be the `id` of the note that is being reacted to.
 
 The last `p` tag MUST be the `pubkey` of the event being reacted to.
 
+The reaction event MAY include a `k` tag with the stringified kind number
+of the reacted event as its value.
+
 Example code
 
 ```swift
@@ -43,6 +46,7 @@ func make_like_event(pubkey: String, privkey: String, liked: NostrEvent) -> Nost
     }
     tags.append(["e", liked.id])
     tags.append(["p", liked.pubkey])
+    tags.append(["k", liked.kind])
     let ev = NostrEvent(content: "+", pubkey: pubkey, kind: 7, tags: tags)
     ev.calculate_id()
     ev.sign(privkey: privkey)

57.md

@@ -45,7 +45,7 @@ Example:
   "kind": 9734,
   "content": "Zap!",
   "tags": [
-    ["relays", "wss://nostr-pub.wellorder.com"],
+    ["relays", "wss://nostr-pub.wellorder.com", "wss://anotherrelay.example.com"],
     ["amount", "21000"],
     ["lnurl", "lnurl1dp68gurn8ghj7um5v93kketj9ehx2amn9uh8wetvdskkkmn0wahz7mrww4excup0dajx2mrv92x9xp"],
     ["p", "04c915daefee38317fa734444acee390a8269fe5810b2241e5e6dd343dfbecc9"],
@@ -66,7 +66,7 @@ A signed `zap request` event is not published, but is instead sent using a HTTP
 - `nostr` is the `9734` `zap request` event, JSON encoded then URI encoded
 - `lnurl` is the lnurl pay url of the recipient, encoded using bech32 with the prefix `lnurl`
 
-This request should return a JSON response with a `pr` key, which is the invoice the sender must pay to finalize his zap. Here is an example flow:
+This request should return a JSON response with a `pr` key, which is the invoice the sender must pay to finalize his zap. Here is an example flow in javascript:
 
 ```javascript
 const senderPubkey // The sender's pubkey

65.md

@@ -59,3 +59,5 @@ This NIP allows Clients to connect directly with the most up-to-date relay set f
 4. DMs SHOULD only be broadcasted to the author's WRITE relays and to the receiver's READ relays to keep maximum privacy. 
 
 5. If a relay signals support for this NIP in their [NIP-11](11.md) document that means they're willing to accept kind 10002 events from a broad range of users, not only their paying customers or whitelisted group.
+
+6. Clients SHOULD deduplicate connections by normalizing relay URIs according to [RFC 3986](https://datatracker.ietf.org/doc/html/rfc3986#section-6).

91.md

@@ -0,0 +1,48 @@
+NIP-91
+======
+
+IoT sensors and intents
+-----------------------
+
+`draft` `optional` `author:BlackCoffee` `author:arcbtc` `author:fiatjaf`
+
+This NIP standardizes communication of public sensor and intent events in order to create an open, pluggable and interoperable standard for "Internet of Things" devices to communicate.
+
+The standard event format follows the following template:
+
+```js
+{
+  "kind": <a number from the table below>,
+  "tags": [
+    ["device", <optional device id>],
+    ["alt", <optional human-readable translation of the event>],
+  ],
+  "content": "<data according to the format in the table below>"
+  ...
+}
+```
+
+Ideally each device would have its own public key, which allows for easy command-and-control and comes with built-in trus guarantees (i.e. you know you're getting the data from the correct device if you know its key and can check the signature), but the `device` tag exists for when that is too cumbersome and more than one device is using the same key.
+
+The `alt` tag follows NIP-31 and can accomodate all human-readable needs, like the device name or the human-readable name of the place it is in.
+
+Other generic tags, like `g` for geolocation, may be included.
+
+### Event Kinds
+
+Kinds between 8000-8999 (inclusive) are reserved for this NIP, to be filled in the table below.
+
+| kind  | name          | type    | unit            | example             | description                                      |
+| ----- | -----         | ------  | -----           | -----               | --------                                         |
+| 8000  | intent        |         |                 |                     | someone wants to trigger an action on a device?  |
+| 8001  | on            | empty   |                 |                     | device was turned on                             |
+| 8002  | off           | empty   |                 |                     | device will turn off                             |
+| 8003  | temperature   | number  | celsius         | 20.9                |                                                  |
+| 8004  | pressure      | number  | pascals         | 1013                |                                                  |
+| 8005  | location      | array   | decimal degrees | [51.5053, -0.08737] |                                                  |
+| 8006  | light         |         |                 |                     |                                                  |
+| 8007  | humidity      |         |                 |                     |                                                  |
+| 8008  | rain          |         |                 |                     |                                                  |
+| 8009  | moisture      |         |                 |                     |                                                  |
+| 8010  | unary switch  |         | empty           |                     | a sensor that detects if a thing happened or not |
+| 8011  | binary switch | boolean |                 | true / false        | a switch that can be turned on or off            |

README.md

@@ -38,6 +38,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 - [NIP-21: `nostr:` URI scheme](21.md)
 - [NIP-22: Event `created_at` Limits](22.md)
 - [NIP-23: Long-form Content](23.md)
+- [NIP-24: Extra metadata fields and tags](24.md)
 - [NIP-25: Reactions](25.md)
 - [NIP-26: Delegated Event Signing](26.md)
 - [NIP-27: Text Note References](27.md)
@@ -66,6 +67,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 - [NIP-75: Zap Goals](75.md)
 - [NIP-78: Application-specific data](78.md)
 - [NIP-89: Recommended Application Handlers](89.md)
+- [NIP-91: IoT Sensors and Intents](91.md)
 - [NIP-94: File Metadata](94.md)
 - [NIP-98: HTTP Auth](98.md)
 - [NIP-99: Classified Listings](99.md)
@@ -91,8 +93,10 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `44`        | Channel Mute User          | [28](28.md) |
 | `1063`      | File Metadata              | [94](94.md) |
 | `1311`      | Live Chat Message          | [53](53.md) |
+| `1040`      | OpenTimestamps             | [03](03.md) |
 | `1984`      | Reporting                  | [56](56.md) |
 | `1985`      | Label                      | [32](32.md) |
+| `8000-8999` | IoT Sensors and Intents    | [91](91.md) |
 | `4550`      | Community Post Approval    | [72](72.md) |
 | `9041`      | Zap Goal                   | [75](75.md) |
 | `9734`      | Zap Request                | [57](57.md) |
@@ -156,7 +160,7 @@ Please update these lists when proposing NIPs introducing new event kinds.
 ## Standardized Tags
 
 | name              | value                                | other parameters     | NIP                                   |
-| ----------------- | ------------------------------------ | -------------------- | ------------------------ |
+| ----------------- | ------------------------------------ | -------------------- | ------------------------------------- |
 | `e`               | event id (hex)                       | relay URL, marker    | [01](01.md), [10](10.md)              |
 | `p`               | pubkey (hex)                         | relay URL, petname   | [01](01.md), [02](02.md)              |
 | `a`               | coordinates to an event              | relay URL            | [01](01.md)                           |
@@ -164,7 +168,7 @@ Please update these lists when proposing NIPs introducing new event kinds.
 | `alt`             | summary                              | --                   | [31](31.md)                           |
 | `g`               | geohash                              | --                   | [52](52.md)                           |
 | `i`               | identity                             | proof                | [39](39.md)                           |
-| `k`               | kind number (string)                 | --                   | [18](18.md), [72](72.md) |
+| `k`               | kind number (string)                 | --                   | [18](18.md), [25](25.md), [72](72.md) |
 | `l`               | label, label namespace               | annotations          | [32](32.md)                           |
 | `L`               | label namespace                      | --                   | [32](32.md)                           |
 | `m`               | MIME type                            | --                   | [94](94.md)                           |