draft

01.md

@@ -113,7 +113,7 @@ Relays expose a websocket endpoint to which clients can connect. Clients SHOULD
 Clients can send 3 types of messages, which must be JSON arrays, according to the following patterns:
 
   * `["EVENT", <event JSON as defined above>]`, used to publish events.
-  * `["REQ", <subscription_id>, <filter>]`, used to request events and subscribe to new updates.
+  * `["REQ", <subscription_id>, <filters1>, <filters2>, ...]`, used to request events and subscribe to new updates.
   * `["CLOSE", <subscription_id>]`, used to stop previous subscriptions.
 
 `<subscription_id>` is an arbitrary, non-empty string of max length 64 chars. It represents a subscription per connection. Relays MUST manage `<subscription_id>`s independently for each WebSocket connection. `<subscription_id>`s are not guaranteed to be globally unique.
@@ -142,6 +142,8 @@ The `since` and `until` properties can be used to specify the time range of even
 
 All conditions of a filter that are specified must match for an event for it to pass the filter, i.e., multiple conditions are interpreted as `&&` conditions.
 
+A `REQ` message may contain multiple filters. In this case, events that match any of the filters are to be returned, i.e., multiple filters are to be interpreted as `||` conditions.
+
 The `limit` property of a filter is only valid for the initial query and MUST be ignored afterwards. When `limit: n` is present it is assumed that the events returned in the initial query will be the last `n` events ordered by the `created_at`. Newer events should appear first, and in the case of ties the event with the lowest id (first in lexical order) should be first. It is safe to return less events than `limit` specifies, but it is expected that relays do not return (much) more events than requested so clients don't get unnecessarily overwhelmed by data.
 
 ### From relay to client: sending events and notices

50.md

@@ -8,11 +8,11 @@ Search Capability
 
 ## Abstract
 
-Many Nostr use cases require some form of general search feature, in addition to structured queries by tags or ids.
+Many Nostr use cases require some form of general search feature, in addition to structured queries by tags or ids. 
-Specifics of the search algorithms will differ between event kinds, this NIP only describes a general
+Specifics of the search algorithms will differ between event kinds, this NIP only describes a general 
 extensible framework for performing such queries.
 
-## `search` filter field
+## `search` filter field 
 
 A new `search` field is introduced for `REQ` messages from clients:
 ```jsonc
@@ -21,23 +21,23 @@ A new `search` field is introduced for `REQ` messages from clients:
   "search": <string>
 }
 ```
-`search` field is a string describing a query in a human-readable form, i.e. "best nostr apps".
+`search` field is a string describing a query in a human-readable form, i.e. "best nostr apps". 
-Relays SHOULD interpret the query to the best of their ability and return events that match it.
+Relays SHOULD interpret the query to the best of their ability and return events that match it. 
 Relays SHOULD perform matching against `content` event field, and MAY perform
-matching against other fields if that makes sense in the context of a specific kind.
+matching against other fields if that makes sense in the context of a specific kind. 
 
 Results SHOULD be returned in descending order by quality of search result (as defined by the implementation),
 not by the usual `.created_at`. The `limit` filter SHOULD be applied after sorting by matching score.
-A query string may contain `key:value` pairs (two words separated by colon), these are extensions, relays SHOULD ignore
+A query string may contain `key:value` pairs (two words separated by colon), these are extensions, relays SHOULD ignore 
 extensions they don't support.
 
-Clients may specify several search filters, i.e. `["REQ", "_", {"kinds": [1], "search": "purple"}]`. Clients may
+Clients may specify several search filters, i.e. `["REQ", "", { "search": "orange" }, { "kinds": [1, 2], "search": "purple" }]`. Clients may 
 include `kinds`, `ids` and other filter field to restrict the search results to particular event kinds.
 
-Clients SHOULD use the supported_nips field to learn if a relay supports `search` filter. Clients MAY send `search`
+Clients SHOULD use the supported_nips field to learn if a relay supports `search` filter. Clients MAY send `search` 
 filter queries to any relay, if they are prepared to filter out extraneous responses from relays that do not support this NIP.
 
-Clients SHOULD query several relays supporting this NIP to compensate for potentially different
+Clients SHOULD query several relays supporting this NIP to compensate for potentially different 
 implementation details between relays.
 
 Clients MAY verify that events returned by a relay match the specified query in a way that suits the

83.md

@@ -0,0 +1,201 @@
+# NIP-83: Stories
+
+`draft` `optional`
+
+This NIP defines a standard for "stories" content.
+
+## Abstract
+
+Stories allow users to share, usually time-limited, visual content that can be enhanced with interactive elements called "stickers".
+
+## Specification
+
+### Event Structure
+
+Stories are represented as events with kind `23`.
+
+### Tags
+
+- `dim`: MUST be present, this is the story canvas in the format `["dim", "<width>x<height>"]`, which defines the coordinate system for all stickers and elements.
+- `imeta` tags as defined in NIP-92.
+- `dur` duration of the story in seconds.
+
+#### Sticker Tags
+
+Stickers are interactive elements placed on the story. They use the format:
+
+```
+["sticker", "<type>", "value", "<x>,<y>", "<width>x<height>", "key1 value1", "key2 value2", ...]
+```
+
+Where:
+
+- `<type>`: The sticker type (see below)
+- `<value>`: The main value of the sticker.
+- `<x>,<y>`: Position coordinates relative to the story canvas
+- `<width>x<height>`: Dimensions of the sticker
+- Additional key-value pairs with the key and value combined in a single element, separated by a space, like `imeta` tags.
+
+##### Sticker Types
+
+- `pubkey`: Mentions a user. Requires a `p` tag with the same index.
+- `event`: Embeds a Nostr event. Requires an `e` tag with the same index.
+- `prompt`: Requests user input with optional placeholder text.
+- `text`: Renders text on the story. The text content is specified using a `"text <value>"` property.
+- `countdown`: Displays a countdown timer to a specific Unix timestamp. The value should be a valid Unix timestamp in seconds.
+
+### Styling Properties
+
+Stickers can have additional properties:
+
+- `style`: A named style identifier. Clients are encouraged to mimic common style implementations from other clients.
+- `rot`: Rotation in degrees (0-360).
+
+Additional properties may be defined by clients, with common practices expected to emerge over time.
+
+## Design Considerations
+
+This NIP intentionally avoids highly specific styling mechanisms (like CSS) to ensure compatibility across different platforms, device types, and technologies. Instead, it provides foundational positioning and sizing with named styles that clients can interpret according to their capabilities.
+
+## Examples
+
+A basic story with an image and a text sticker:
+
+```json
+{
+  "kind": 23,
+  "content": "",
+  "tags": [
+    ["dim", "1080x1920"],
+    [
+      "imeta",
+      "url",
+      "https://example.com/image.jpg",
+      "m",
+      "image/jpeg",
+      "blurhash",
+      "UBL_:rOpGG-;0g9FD%IA4oIpELxu"
+    ],
+    [
+      "sticker",
+      "text",
+      "Hello Nostr!",
+      "540,960",
+      "600x200",
+      "style emphasis",
+      "rot 5"
+    ]
+  ]
+}
+```
+
+A story with a user mention:
+
+```json
+{
+  "kind": 23,
+  "content": "",
+  "tags": [
+    ["dim", "1080x1920"],
+    ["expiration", "<timestampp>"],
+    ["imeta", "url", "https://example.com/image.jpg", "m", "image/jpeg"],
+    ["p", "fa984bd7dbb282f07e16e7ae87b26a2a7b9b90b7246a44771f0cf5ae58018f52"],
+    [
+      "sticker",
+      "pubkey",
+      "fa984bd7dbb282f07e16e7ae87b26a2a7b9b90b7246a44771f0cf5ae58018f52",
+      "540,960",
+      "300x300",
+      "style flou"
+    ],
+    [
+      "a",
+      "30023:6260f29fa75c91aaa292f082e5e87b438d2ab4fdf96af398567b01802ee2fcd4:7b734cf9"
+    ],
+    [
+      "sticker",
+      "event",
+      "30023:6260f29fa75c91aaa292f082e5e87b438d2ab4fdf96af398567b01802ee2fcd4:7b734cf9",
+      "540,960",
+      "300x300",
+      "style flou"
+    ]
+  ]
+}
+```
+
+A story with a countdown timer:
+
+```json
+{
+  "kind": 23,
+  "content": "",
+  "tags": [
+    ["expiration", "<timestamp>"],
+    ["dim", "1080x1920"],
+    ["imeta", "url", "https://example.com/event-image.jpg", "m", "image/jpeg"],
+    [
+      "sticker",
+      "countdown",
+      "1718486400",
+      "540,800",
+      "400x150",
+      "style emphasis",
+      "text Event starts in"
+    ]
+  ]
+}
+```
+
+## Client Behavior
+
+Clients SHOULD respect the coordinate system defined by the `dim` tag. When displaying stories on screens with different aspect ratios, clients SHOULD maintain the relative positioning of all elements.
+
+## Implementation Notes
+
+- Stories are ephemeral by nature. Clients MAY choose to display stories for a limited time (typically 24 hours).
+- For consistent rendering across platforms, measurements and coordinates SHOULD be treated as logical units rather than specific pixel values.
+- Clients SHOULD make reasonable attempts to reproduce named styles consistently with other implementations.
+
+## A note about `style`
+
+Stickers use a very ambiguous `style` with just a name. Clients can interpret what the name represents in their users screens freely, but clients should strive for consistency and sane defaults. Styles can emerge in the wild and clients are
+encouraged to work on supporting what their users want.
+
+The reason to avoid providing precise definitions and styling attributes is because recoinciling different platforms, native, web would end up yielding something as complicated as CSS which would be an overkill and, just like CSS has shown, an ever-shifting goal post.
+
+## Appendix 1: Sticker Type Examples
+
+### Mentions
+
+```
+["sticker", "pubkey", "fa984bd7dbb282f07e16e7ae87b26a2a7b9b90b7246a44771f0cf5ae58018f52", "540,960", "300x300", "style default"]
+```
+
+### Event
+
+An event to be embedded. Addressable events should use the `<kind>:<pubkey>:<d-tag>` format.
+
+Additionally, event stickers should include the corresponding `a` and/or `e` tag to help find the event (relay hint, etc.).
+
+```
+["sticker", "event", "1a5f6849cef16334e1a73f289d457d54833769731c0631a39ca9631a6575e91d", "200,500", "400x200", "style card"]
+```
+
+### Ask for a reply
+
+```
+["sticker", "prompt", "Ask me a question", "540,1200", "600x100", "style rounded"]
+```
+
+### Embed text
+
+```
+["sticker", "text", "Hello world!", "540,960", "500x150", "style bold", "rot 15"]
+```
+
+### Timer countdown
+
+```
+["sticker", "countdown", "1718486400", "540,700", "400x100", "text Event starts in"]
+```