nip17: "seen" event.

17.md

@@ -8,7 +8,11 @@ Private Direct Messages
 
 This NIP defines an encrypted direct messaging scheme using [NIP-44](44.md) encryption and [NIP-59](59.md) seals and gift wraps.
 
-## Direct Message Kind
+## Message kinds
+
+Each of these message kinds can be gift-wrapped as described afterwards. Clients have to first unwrap them to then see their kinds.
+
+### Direct Message Kind
 
 Kind `14` is a chat message. `p` tags identify one or more receivers of the message.
 
@@ -41,7 +45,7 @@ An `e` tag denotes the direct parent message this post is replying to.
 
 Kind `14`s MUST never be signed. If it is signed, the message might leak to relays and become **fully public**.
 
-## File Message Kind
+### File Message Kind
 
 ```jsonc
 {
@@ -59,7 +63,6 @@ Kind `14`s MUST never be signed. If it is signed, the message might leak to rela
     ["decryption-key", "<decryption-key>"],
     ["decryption-nonce", "<decryption-nonce>"],
     ["x", "<the SHA-256 hexencoded string of the file>"],
-    // rest of tags...
   ],
   "content": "<file-url>"
 }
@@ -82,6 +85,46 @@ Kind `15` is used for sending encrypted file event messages:
 
 Just like kind `14`, kind `15`s MUST never be signed.
 
+### "Seen" event
+
+An event of kind `30016` that CAN be emitted automatically by a client whenever a chat window is displayed to the user, even if the user hasn't acted on it.
+
+```jsonc
+{
+  "id": "<usual hash>",
+  "pubkey": "<sender-pubkey>",
+  "created_at": "<current-time>",
+  "kind": 30016,
+  "tags": [
+    ["d", "<subject>"],
+    ["seen", "<latest_message_id>", "<previous_id>", "<...>"]
+  ],
+  "content": ""
+}
+```
+
+- `d` must be set to the conversation subject, or it can be empty or omitted in the most common case of a `<subject>` not existing.
+- `seen` must be set to the id of the last messages seen. It can contain any number of ids, ordered from the newest to the oldest.
+
+This event SHOULD be discarded whenever a new event is received for the same conversation.
+
+Any messages with timestamp before the last item in the `seen` array are assumed to have been seen.
+
+If there is a gap in the `seen` array that indicates a message may have been missed for whatever reason.
+
+For example:
+
+- `alice` sends message `aaaa`
+- `alice` sends message `bbbb`
+- `alice` sends message `cccc`
+- `bob` sends event with `["seen", "bbbb", "aaaa"]`
+- at this point `alice`'s client should display `aaaa` and `bbbb` as seen, `cccc` as unseen
+- `alice` sends message `dddd`
+- `alice` sends message `eeee`, which is lost due to relay malfunction
+- `alice` sends message `ffff`
+- `bob` sends event with `["seen", "ffff", "dddd", "cccc"]`
+- at this point `alice`'s client should display all messages as seen, except for `eeee` which should be displayed with an error indicator
+
 ## Chat Rooms
 
 The set of `pubkey` + `p` tags defines a chat room. If a new `p` tag is added or a current one is removed, a new room is created with a clean message history.

5E.md

@@ -1,124 +0,0 @@
-# NIP-5E
-
-## Nostr Live Streams
-
-`draft` `optional` `dep:53` `dep:92` `dep:94` `dep:40`
-
-Describes a way to distribute live video streams via nostr.
-
-**"Live Video" in this context implies segmented video streams like HLS or DASH**
-
-All other live interactions (chat/zap/raid etc) from [NIP-53](53.md) are re-used here so that the main stream event is interchangeable.
-
-## N94 Stream
-
-A new `kind: 1053` event lists a single live stream.
-
-Example:
-
-```jsonc
-{
-  "kind": 1053,
-  "tags": [
-    ["title", "<name of the event>"],
-    ["summary", "<description>"],
-    ["image", "<preview image url>"],
-    [
-      "variant",
-      "dim 1920x1080",
-      "bitrate 5000000",
-      "m video/mp2t",
-      "d 1080p"
-    ],
-    [
-      "variant",
-      "dim 1280x720",
-      "bitrate 3000000",
-      "m video/mp2t",
-      "d 720p"
-    ],
-    [
-      "variant",
-      "dim 1920x1080",
-      "bitrate 6000000",
-      "m video/mp4",
-      "d 1080p-fmp4"
-    ],
-    ["t", "hashtag"],
-    ["relays", "wss://one.com", "wss://two.com", /*...*/],
-    ["pinned", "<event id of pinned live chat message>"],
-    ["goal", "<event id of stream goal>"]
-  ],
-  "content": "",
-  // other fields...
-}
-```
-
-The `variant` tag works like `imeta` tag from [NIP-92](92.md) and defines a variant stream.
-
-The `d` entry of the `variant` tag is used in the NIP-94 segment event for variant following.
-
-## N94 Segment
-
-Each segment of the stream is a [NIP-94](94.md) event which describes where the file can be found and its hash.
-
-```jsonc
-{
-  "kind": 1063,
-  "tags": [
-    ["d", "1080p"],
-    ["k", "1053"],
-    ["e", "<id-of-kind-1053>"],
-    ["x", "<sha256>"],
-    ["m", "video/mp2t"],
-    ["dim", "1920x1080"],
-    ["duration", "2.033"],
-    ["index", "1234"],
-    ["url", "https://example.com/1234.ts"],
-    ["fallback", "https://another.com/1234.ts"],
-    ["expiration", "1752752349"],
-    ["service", "blossom"],
-    ...
-  ]
-  // other fields...
-}
-```
-
-Aside from the standard NIP-94 tags:
-
-- `d`: Variant stream tag.
-- `index`: Segment index, a simple counter. Used of ordering.
-
-`service` tag should be used for extended censorship resitance by looking up the appropriate server list (Blossom) of the uploader and checking for files on alternate servers.
-
-An [NIP-40](40.md) `expiration` tag MAY be used to automatically clean up segments after a specified time, which is useful for live streams that are not intended to persist. Producers SHOULD also automatically delete segment files from file servers.
-
-## Implementors
-
-### Consumers
-
-Clients wishing to implement a player should use [MSE](https://developer.mozilla.org/en-US/docs/Web/API/Media_Source_Extensions_API) or similar technologies which allow appending data to the player buffer.
-
-Other services MAY provide a compatability layer with [NIP-53](53.md) live streams by producing HLS playlists over a N94 Stream.
-
-Clients SHOULD listen for new segments using a filter like this:
-
-`{"kinds":[1063],"#e":["<id-of-kind-1053>"],"limit":10}`
-
-Leaving the subscription open will allow clients to be notified immediately as segments are published and can fetch those segments and append them to the player buffer, enabling live playback without delays.
-
-### Producers
-
-Segment length SHOULD be carefully considered as a trade off between stream delay and total number of NIP-94 events / segment files.
-
-Using `expiration` tags on N94 segments and deleting segment files from servers SHOULD be used to cleanup streams which don't want to persist after the stream is finished.
-
-## Example implementations:
-
-### Player
-
-[zap.stream](https://github.com/v0l/zap.stream/blob/main/src/element/stream/n94-player.tsx)
-
-### Producer
-
-[n94](https://github.com/v0l/zap-stream-core/tree/main/crates/n94)

README.md

@@ -102,11 +102,9 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 - [NIP-96: HTTP File Storage Integration](96.md)
 - [NIP-98: HTTP Auth](98.md)
 - [NIP-99: Classified Listings](99.md)
-- [NIP-5E: Nostr Live Streams](5E.md)
 - [NIP-B0: Web Bookmarks](B0.md)
 - [NIP-B7: Blossom](B7.md)
 - [NIP-C0: Code Snippets](C0.md)
-- [NIP-7D: Threads](7D.md)
 - [NIP-C7: Chats](C7.md)
 
 ## Event Kinds
@@ -149,7 +147,6 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `1021`        | Bid                             | [15](15.md)                            |
 | `1022`        | Bid confirmation                | [15](15.md)                            |
 | `1040`        | OpenTimestamps                  | [03](03.md)                            |
-| `1053`        | Live Stream                     | [5E](5E.md)                            |
 | `1059`        | Gift Wrap                       | [59](59.md)                            |
 | `1063`        | File Metadata                   | [94](94.md)                            |
 | `1068`        | Poll                            | [88](88.md)                            |