mirror of
https://github.com/nostr-protocol/nips.git
synced 2025-12-09 00:28:51 +00:00
Compare commits
2 Commits
stories
...
reaction-t
| Author | SHA1 | Date | |
|---|---|---|---|
|
23b069d469 | ||
|
|
1b86a40df4 |
4
01.md
4
01.md
@@ -78,8 +78,8 @@ This NIP defines 3 standard tags that can be used across all event kinds with th
|
||||
- The `e` tag, used to refer to an event: `["e", <32-bytes lowercase hex of the id of another event>, <recommended relay URL, optional>, <32-bytes lowercase hex of the author's pubkey, optional>]`
|
||||
- The `p` tag, used to refer to another user: `["p", <32-bytes lowercase hex of a pubkey>, <recommended relay URL, optional>]`
|
||||
- The `a` tag, used to refer to an addressable or replaceable event
|
||||
- for an addressable event: `["a", "<kind integer>:<32-bytes lowercase hex of a pubkey>:<d tag value>", <recommended relay URL, optional>]`
|
||||
- for a normal replaceable event: `["a", "<kind integer>:<32-bytes lowercase hex of a pubkey>:", <recommended relay URL, optional>]` (note: include the trailing colon)
|
||||
- for an addressable event: `["a", <kind integer>:<32-bytes lowercase hex of a pubkey>:<d tag value>, <recommended relay URL, optional>]`
|
||||
- for a normal replaceable event: `["a", <kind integer>:<32-bytes lowercase hex of a pubkey>:, <recommended relay URL, optional>]`
|
||||
|
||||
As a convention, all single-letter (only english alphabet letters: a-z, A-Z) key tags are expected to be indexed by relays, such that it is possible, for example, to query or subscribe to events that reference the event `"5c83da77af1dec6d7289834998ad7aafbd9e2191396d75ec3cc27f5a77226f36"` by using the `{"#e": ["5c83da77af1dec6d7289834998ad7aafbd9e2191396d75ec3cc27f5a77226f36"]}` filter. Only the first value in any given tag is indexed.
|
||||
|
||||
|
||||
24
17.md
24
17.md
@@ -21,7 +21,7 @@ Kind `14` is a chat message. `p` tags identify one or more receivers of the mess
|
||||
"tags": [
|
||||
["p", "<receiver-1-pubkey>", "<relay-url>"],
|
||||
["p", "<receiver-2-pubkey>", "<relay-url>"],
|
||||
["e", "<kind-14-id>", "<relay-url>"] // if this is a reply
|
||||
["e", "<kind-14-id>", "<relay-url>", "reply"] // if this is a reply
|
||||
["subject", "<conversation-title>"],
|
||||
// rest of tags...
|
||||
],
|
||||
@@ -31,13 +31,7 @@ Kind `14` is a chat message. `p` tags identify one or more receivers of the mess
|
||||
|
||||
`.content` MUST be plain text. Fields `id` and `created_at` are required.
|
||||
|
||||
An `e` tag denotes the direct parent message this post is replying to.
|
||||
|
||||
`q` tags MAY be used when citing events in the `.content` with [NIP-21](21.md).
|
||||
|
||||
```json
|
||||
["q", "<event-id> or <event-address>", "<relay-url>", "<pubkey-if-a-regular-event>"]
|
||||
```
|
||||
Tags that mention, quote and assemble threading structures MUST follow [NIP-10](10.md).
|
||||
|
||||
Kind `14`s MUST never be signed. If it is signed, the message might leak to relays and become **fully public**.
|
||||
|
||||
@@ -57,7 +51,7 @@ Kind `14`s MUST never be signed. If it is signed, the message might leak to rela
|
||||
["file-type", "<file-mime-type>"],
|
||||
["encryption-algorithm", "<encryption-algorithm>"],
|
||||
["decryption-key", "<decryption-key>"],
|
||||
["decryption-nonce", "<decryption-nonce>"],
|
||||
["decryptiion-nonce", "<decryption-nonce>"],
|
||||
["x", "<the SHA-256 hexencoded string of the file>"],
|
||||
// rest of tags...
|
||||
],
|
||||
@@ -74,16 +68,16 @@ Kind 15 is used for sending encrypted file event messages:
|
||||
- `content`: The URL of the file (`<file-url>`).
|
||||
- `x` containing the SHA-256 hexencoded string of the file.
|
||||
- `size` (optional) size of file in bytes
|
||||
- `dim` (optional) size of the file in pixels in the form `<width>x<height>`
|
||||
- `blurhash`(optional) the [blurhash](https://github.com/woltapp/blurhash) to show while the client is loading the file
|
||||
- `thumb` (optional) URL of thumbnail with same aspect ratio (encrypted with the same key, nonce)
|
||||
- `dim` (optional) size of file in pixels in the form `<width>x<height>`
|
||||
- `blurhash`(optional) the [blurhash](https://github.com/woltapp/blurhash) to show while the file is being loaded by the client
|
||||
- `thumb` (optional) url of thumbnail with same aspect ratio
|
||||
- `fallback` (optional) zero or more fallback file sources in case `url` fails
|
||||
|
||||
Just like kind 14, kind `15`s MUST never be signed.
|
||||
|
||||
## 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.
|
||||
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 clean message history.
|
||||
|
||||
Clients SHOULD render messages of the same room in a continuous thread.
|
||||
|
||||
@@ -91,7 +85,7 @@ An optional `subject` tag defines the current name/topic of the conversation. An
|
||||
|
||||
## Encrypting
|
||||
|
||||
Following [NIP-59](59.md), the **unsigned** `kind:14` & `kind:15` chat messages must be sealed (`kind:13`) and then gift-wrapped (`kind:1059`) to each receiver and the sender individually.
|
||||
Following [NIP-59](59.md), the **unsigned** `kind:14` & `kind:15` chat message must be sealed (`kind:13`) and then gift-wrapped (`kind:1059`) to each receiver and the sender individually.
|
||||
|
||||
```jsonc
|
||||
{
|
||||
@@ -173,7 +167,7 @@ The main limitation of this approach is having to send a separate encrypted even
|
||||
|
||||
Clients implementing this NIP should by default only connect to the set of relays found in their `kind:10050` list. From that they should be able to load all messages both sent and received as well as get new live updates, making it for a very simple and lightweight implementation that should be fast.
|
||||
|
||||
When sending a message to anyone, clients must then connect to the relays in the receiver's `kind:10050` and send the events there but can disconnect right after unless more messages are expected to be sent (e.g. the chat tab is still selected). Clients should also send a copy of their outgoing messages to their own `kind:10050` relay set.
|
||||
When sending a message to anyone, clients must then connect to the relays in the receiver's `kind:10050` and send the events there, but can disconnect right after unless more messages are expected to be sent (e.g. the chat tab is still selected). Clients should also send a copy of their outgoing messages to their own `kind:10050` relay set.
|
||||
|
||||
## Examples
|
||||
|
||||
|
||||
4
23.md
4
23.md
@@ -60,7 +60,3 @@ References to other Nostr notes, articles or profiles must be made according to
|
||||
"id": "..."
|
||||
}
|
||||
```
|
||||
|
||||
### Replies & Comments
|
||||
|
||||
Replies to `kind 30023` MUST use [NIP-22](./22.md) `kind 1111` comments.
|
||||
2
55.md
2
55.md
@@ -484,8 +484,6 @@ If the user chose to always reject the event, signer application will return the
|
||||
|
||||
# Usage for Web Applications
|
||||
|
||||
You should consider using [NIP-46: Nostr Connect](46.md) for a better experience for web applications. When using this approach, the web app can't call the signer in the background, so the user will see a popup for every event you try to sign.
|
||||
|
||||
Since web applications can't receive a result from the intent, you should add a modal to paste the signature or the event json or create a callback url.
|
||||
|
||||
If you send the callback url parameter, Signer Application will send the result to the url.
|
||||
|
||||
250
66.md
250
66.md
@@ -1,250 +0,0 @@
|
||||
# NIP-66: Relay Discovery and Liveness Monitoring
|
||||
|
||||
`draft` `optional`
|
||||
|
||||
You want to find relays. You may want to discover relays based on criteria that's up to date. You may even want to ensure that you have a complete dataset. You probably want to filter relays based on their reported liveness.
|
||||
|
||||
In its purest form:
|
||||
|
||||
```json
|
||||
{
|
||||
"kind": 30166,
|
||||
"created_at": 1722173222,
|
||||
"content": "{}",
|
||||
"tags": [
|
||||
[ "d", "wss://somerelay.abc/" ]
|
||||
],
|
||||
"pubkey": "<pubkey>",
|
||||
"sig": "<signature>",
|
||||
"id": "<eventid>"
|
||||
}
|
||||
```
|
||||
|
||||
This event signals that the relay at `wss://somerelay.abc/` was reported "online" by `<pubkey>` at timestamp `1722173222`. This event **MAY** be extended upon to include more information.
|
||||
|
||||
## Kinds
|
||||
`NIP-66` defines two (2) event kinds, `30166` and `10166`
|
||||
|
||||
| kind | name | description |
|
||||
|-------|----------------------------|-----------------------------------------------------------------------------------------|
|
||||
| [30166](#k30166) | Relay Discovery | An addressable event that is published by a monitor when a relay is online |
|
||||
| [10166](#k10166) | Relay Monitor Announcement | An RE that stores data that signals the intent of a pubkey to monitor relays and publish `30166` events at a regular _frequency_ |
|
||||
|
||||
## Ontology
|
||||
- `Relay Operator`: someone who operates a relay
|
||||
- `Monitor`: A pubkey that monitors relays and publishes `30166` events at the frequency specified in their `10166` event.
|
||||
- `Ad-hoc Monitor`: A pubkey that monitors relays and publishes `30166` events at an irregular frequency.
|
||||
- `Monitor Service`: A group or individual that monitors relays using one or more `Monitors`.
|
||||
- `Check`: a specific data point that is tested or aggregated by a monitor.
|
||||
|
||||
## `30166`: "Relay Discovery" <a id="k30166"></a>
|
||||
|
||||
### Summary
|
||||
`30166` is a `NIP-33` addressable event, referred to as a "Relay Discovery" event. These events are optimized with a small footprint for protocol-level relay Discovery.
|
||||
|
||||
### Purpose
|
||||
Discovery of relays over nostr.
|
||||
|
||||
### Schema
|
||||
|
||||
#### Content
|
||||
`30166` content fields **SHOULD** include the stringified JSON of the relay's NIP-11 informational document. This data **MAY** be provided for informational purposes only.
|
||||
|
||||
#### `created_at`
|
||||
The `created_at` field in a NIP-66 event should reflect the time when the relay liveness (and potentially other data points) was checked.
|
||||
|
||||
#### `tags`
|
||||
|
||||
##### Meta Tags (unindexed)
|
||||
- `rtt-open` The relay's open **round-trip time** in milliseconds.
|
||||
- `rtt-read` The relay's read **round-trip time** in milliseconds.
|
||||
- `rtt-write` The relay's write **round-trip time** in milliseconds.
|
||||
|
||||
_Other `rtt` values **MAY** be present. This NIP should be updated if there is value found in more `rtt` values._
|
||||
|
||||
##### Single Letter Tags (indexed)
|
||||
- `d` The relay URL/URI. The `#d` tag **must** be included in the `event.tags[]` array. Index position `1` **must** be the relay websocket URL/URI. If a URL it **SHOULD** be [normalized](https://datatracker.ietf.org/doc/html/rfc3986#section-6). For relays not accessible via conventional means but rather by an npub/pubkey, an npub/pubkey **MAY** be used in place of a URL.
|
||||
```json
|
||||
[ "d", "wss://somerelay.abc/"]
|
||||
```
|
||||
|
||||
- `n`: Network
|
||||
```json
|
||||
[ "n", "clearnet" ]
|
||||
```
|
||||
|
||||
- `T`: Relay Type. Enumerated [relay type](https://github.com/nostr-protocol/nips/issues/1282) formatted as `PascalCase`
|
||||
```json
|
||||
["T", "PrivateInbox" ]
|
||||
```
|
||||
|
||||
- `N`: Supported Nips _From NIP-11 "Informational Document" `nip11.supported_nips[]`_
|
||||
```json
|
||||
[ "N", "42" ]
|
||||
```
|
||||
|
||||
- `R`: Requirements _NIP-11 "Informational Document" `nip11.limitations.payment_required`, `nip11.limitations.auth_required` and/or any other boolean value within `nip11.limitations[]` that is added in the future_
|
||||
```json
|
||||
[ "R", "payment" ],
|
||||
[ "R", "auth" ],
|
||||
```
|
||||
Since the nostr protocol does not currently support filtering on whether an indexed tag **is** or **is not** set, to make "public" and "no auth" relays discoverable requires a `!` flag
|
||||
|
||||
```json
|
||||
[ "R", "!payment" ], //no payment required, is public
|
||||
[ "R", "!auth" ], //no authentication required
|
||||
```
|
||||
|
||||
- `t`: "Topics" _From NIP-11 "Informational Document" `nip11.tags[]`_
|
||||
```json
|
||||
[ "t", "nsfw" ]
|
||||
```
|
||||
|
||||
- `k`: Accepted/Blocked Kinds [`NIP-22`]
|
||||
```json
|
||||
[ "k", "0" ],
|
||||
[ "k", "3" ],
|
||||
[ "k", "10002" ]
|
||||
```
|
||||
|
||||
or for blocked kinds
|
||||
|
||||
```json
|
||||
[ "k", "!0" ]
|
||||
[ "k", "!3" ],
|
||||
[ "k", "!10002" ]
|
||||
```
|
||||
|
||||
- `g`: `NIP-52` `g` tags (geohash)
|
||||
```json
|
||||
[ "g", "9r1652whz" ]
|
||||
```
|
||||
|
||||
- `30166` **MAY** be extended with global tags defined by other NIPs that do no collide with locally defined indices, including but not limited to: `p`, `t`, `e`, `a`, `i` and `l/L`.
|
||||
|
||||
#### Robust Example of a `30166` Event
|
||||
_Relay was online, and you can filter on a number of different tags_
|
||||
```json
|
||||
{
|
||||
"id": "<eventid>",
|
||||
"pubkey": "<monitor's pubkey>",
|
||||
"created_at": "<created_at [some recent date ...]>",
|
||||
"signature": "<signature>",
|
||||
"content": "{}",
|
||||
"kind": 30166,
|
||||
"tags": [
|
||||
["d","wss://some.relay/"],
|
||||
["n", "clearnet"],
|
||||
["N", "40"],
|
||||
["N", "33"],
|
||||
["R", "!payment"],
|
||||
["R", "auth"],
|
||||
["g", "ww8p1r4t8"],
|
||||
["p", "somehexkey..."],
|
||||
["l", "en", "ISO-639-1"],
|
||||
["t", "nsfw" ],
|
||||
["rtt-open", 234 ]
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
## `10166`: "Relay Monitor Announcement" Events <a id="k10166"></a>
|
||||
|
||||
### Summary
|
||||
`10166` is a replacable event herein referred to as "Relay Monitor Announcement" events. These events contain information about a publisher's intent to monitor and publish data as `30166` events. This event is optional and is intended for monitors who intend to provide monitoring services at a regular and predictable frequency.
|
||||
|
||||
### Purpose
|
||||
To provide a directory of monitors, their intent to publish, their criteria and parameters of monitoring activities. Absence of this event implies the monitor is ad-hoc and does not publish events at a predictable frequency, and relies on mechanisms to infer data integrity, such as web-of-trust.
|
||||
|
||||
### Schema
|
||||
|
||||
#### Standard Tags
|
||||
|
||||
- `frequency` The frequency **in seconds** at which the monitor publishes events. A string-integer at index `1` represents the expected frequency the monitor will publish `30166` events. There should only be `1` frequency per monitor.
|
||||
|
||||
```json
|
||||
[ "frequency", "3600" ]
|
||||
```
|
||||
|
||||
- `timeout` (optional) The timeout values for various checks conducted by a monitor. Index `1` is the monitor's timeout in milliseconds. Index `2` describes what test the timeout is used for. If no index `2` is provided, it is inferred that the timeout provided applies to all tests. These values can assist relay operators in understanding data signaled by the monitor in _Relay Discovery Events_.
|
||||
```json
|
||||
[ "timeout", "2000", "open" ],
|
||||
[ "timeout", "2000", "read" ],
|
||||
[ "timeout", "3000", "write" ],
|
||||
[ "timeout", "2000", "nip11" ],
|
||||
[ "timeout", "4000", "ssl" ]
|
||||
```
|
||||
|
||||
#### Indexed Tags
|
||||
- `c` "Checks" **SHOULD** be a lowercase string describing the check(s) conducted by a monitor. Due to the rapidly evolving nature of relays, enumeration is organic and not strictly defined. But examples of some checks could be websocket `open/read/write/auth`, `nip11` checks, `dns` and `geo` checks, and and any other checks the monitor may deem useful.. Other checks **MAY** be included. New types of checks **SHOULD** be added to this NIP as they are needed.
|
||||
```json
|
||||
[ "c", "ws" ],
|
||||
[ "c", "nip11" ],
|
||||
[ "c", "dns" ],
|
||||
[ "c", "geo" ],
|
||||
[ "c", "ssl" ],
|
||||
```
|
||||
|
||||
- `g`: `NIP-52` `g` tags (geohash)
|
||||
```json
|
||||
[ "g", "9r1652whz" ]
|
||||
```
|
||||
|
||||
- Any other globally defined indexable tags **MAY** be included as found necessary.
|
||||
|
||||
### Other Requirements
|
||||
Monitors **SHOULD** have the following
|
||||
- A published `0` (NIP-1) event
|
||||
- A published `10002` (NIP-65) event that defines the relays the monitor publishes to.
|
||||
|
||||
### Robust Example of a `10166` Event
|
||||
```json
|
||||
{
|
||||
"id": "<eventid>",
|
||||
"pubkey": "<monitor's pubkey>",
|
||||
"created_at": "<created_at [some recent date ...]>",
|
||||
"signature": "<signature>",
|
||||
"content": "",
|
||||
"tags": [
|
||||
|
||||
[ "timeout", "open", "5000" ],
|
||||
[ "timeout", "read", "3000" ],
|
||||
[ "timeout", "write", "3000" ],
|
||||
[ "timeout", "nip11", "3000" ],
|
||||
|
||||
[ "frequency", "3600" ],
|
||||
|
||||
[ "c", "ws" ],
|
||||
[ "c", "nip11" ],
|
||||
[ "c", "ssl" ],
|
||||
[ "c", "dns" ],
|
||||
[ "c", "geo" ]
|
||||
|
||||
[ "g", "ww8p1r4t8" ]
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
## Methodology
|
||||
|
||||
### Monitors
|
||||
1. A _Relay Monitor_ checks the liveness and potentially other attributes of a relay.
|
||||
|
||||
2. _Relay Monitor_ publishes a kind `30166` note when a relay it is monitoring is online. If the monitor has a `10166` event, events should be published at the frequency defined in their `10166` note.
|
||||
|
||||
_Any pubkey that publishes `30166` events **SHOULD** at a minimum be checking that the relay is available by websocket and behaves like a relay_
|
||||
|
||||
### Clients
|
||||
1. In most cases, a client **SHOULD** filter on `30166` events using either a statically or dynamically defined monitor's `pubkey` and a `created_at` value respective of the monitor's published `frequency`. If the monitor has no stated frequency, other mechanisms should be employed to determine data integrity.
|
||||
|
||||
2. _Relay Liveness_ is subjectively determined by the client, starting with the `frequency` value of a monitor.
|
||||
|
||||
3. The liveness of a _Relay Monitor_ can be subjectively determined by detecting whether the _Relay Monitor_ has published events with respect to `frequency` value of any particular monitor.
|
||||
|
||||
4. The reliability and trustworthiness of a _Relay Monitor_ could be established via web-of-trust, reviews or similar mechanisms.
|
||||
|
||||
## Risk Mitigation
|
||||
|
||||
- When a client implements `NIP-66` events, the client should have a fallback if `NIP-66` events cannot be located.
|
||||
|
||||
- A `Monitor` or `Ad-hoc Monitor` may publish erroneous `30166` events, intentionally or otherwise. Therefor, it's important to program defensively to limit the impact of such events. This can be achieved with web-of-trust, reviews, fallbacks and/or data-aggregation for example.
|
||||
37
73.md
37
73.md
@@ -9,37 +9,26 @@ External Content IDs
|
||||
There are certain established global content identifiers such as [Book ISBNs](https://en.wikipedia.org/wiki/ISBN), [Podcast GUIDs](https://podcastnamespace.org/tag/guid), and [Movie ISANs](https://en.wikipedia.org/wiki/International_Standard_Audiovisual_Number) that are useful to reference in nostr events so that clients can query all the events assosiated with these ids.
|
||||
|
||||
|
||||
`i` tags are used for referencing these external content ids, with `k` tags representing the external content id kind so that clients can query all the events for a specific kind.
|
||||
`i` tags are used for referencing these external content ids, with `k` tags representing the external content id kind so that clients can query all the events for a specific kind.
|
||||
|
||||
## Supported IDs
|
||||
|
||||
| Type | `i` tag | `k` tag |
|
||||
| --- | --- | --- |
|
||||
| URLs | "`<URL, normalized, no fragment>`" | "web" |
|
||||
| Hashtags | "#`<topic, lowercase>`" | "#" |
|
||||
| Geohashes | "geo:`<geohash, lowercase>`" | "geo" |
|
||||
| Books | "isbn:`<id, without hyphens>`" | "isbn" |
|
||||
| Podcast Feeds | "podcast:guid:`<guid>`" | "podcast:guid" |
|
||||
| Podcast Episodes | "podcast:item:guid:`<guid>`" | "podcast:item:guid" |
|
||||
| Podcast Publishers | "podcast:publisher:guid:`<guid>`" | "podcast:publisher:guid" |
|
||||
| Movies | "isan:`<id, without version part>`" | "isan" |
|
||||
| Papers | "doi:`<id, lowercase>`" | "doi" |
|
||||
| Type | `i` tag | `k` tag |
|
||||
|- | - | - |
|
||||
| URLs | "`<URL, normalized, no fragment>`" | "`<scheme-host, normalized>`" |
|
||||
| Hashtags | "#`<topic, lowercase>`" | "#" |
|
||||
| Geohashes| "geo:`<geohash, lowercase>`" | "geo" |
|
||||
| Books | "isbn:`<id, without hyphens>`" | "isbn" |
|
||||
| Podcast Feeds | "podcast:guid:`<guid>`" | "podcast:guid" |
|
||||
| Podcast Episodes | "podcast:item:guid:`<guid>`" | "podcast:item:guid" |
|
||||
| Podcast Publishers | "podcast:publisher:guid:`<guid>`" | "podcast:publisher:guid" |
|
||||
| Movies | "isan:`<id, without version part>`" | "isan" |
|
||||
| Papers | "doi:`<id, lowercase>`" | "doi" |
|
||||
|
||||
---
|
||||
|
||||
## Examples
|
||||
|
||||
### Webpages
|
||||
|
||||
For the webpage "https://myblog.example.com/post/2012-03-27/hello-world" the "i" and "k" tags are:
|
||||
|
||||
```jsonc
|
||||
[
|
||||
["i","https://myblog.example.com/post/2012-03-27/hello-world"],
|
||||
["k", "web"]
|
||||
]
|
||||
```
|
||||
|
||||
### Books:
|
||||
|
||||
- Book ISBN: `["i", "isbn:9780765382030"]` - https://isbnsearch.org/isbn/9780765382030
|
||||
@@ -67,3 +56,5 @@ Each `i` tag MAY have a url hint as the second argument to redirect people to a
|
||||
`["i", "podcast:item:guid:d98d189b-dc7b-45b1-8720-d4b98690f31f", https://fountain.fm/episode/z1y9TMQRuqXl2awyrQxg]`
|
||||
|
||||
`["i", "isan:0000-0000-401A-0000-7", https://www.imdb.com/title/tt0120737]`
|
||||
|
||||
|
||||
|
||||
201
83.md
201
83.md
@@ -1,201 +0,0 @@
|
||||
# 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"]
|
||||
```
|
||||
18
README.md
18
README.md
@@ -80,7 +80,6 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
|
||||
- [NIP-62: Request to Vanish](62.md)
|
||||
- [NIP-64: Chess (PGN)](64.md)
|
||||
- [NIP-65: Relay List Metadata](65.md)
|
||||
- [NIP-66: Relay Discovery and Liveness Monitoring](66.md)
|
||||
- [NIP-68: Picture-first feeds](68.md)
|
||||
- [NIP-69: Peer-to-peer Order events](69.md)
|
||||
- [NIP-70: Protected Events](70.md)
|
||||
@@ -127,10 +126,6 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
|
||||
| `20` | Picture | [68](68.md) |
|
||||
| `21` | Video Event | [71](71.md) |
|
||||
| `22` | Short-form Portrait Video Event | [71](71.md) |
|
||||
| `30` | internal reference | [NKBIP-03] |
|
||||
| `31` | external web reference | [NKBIP-03] |
|
||||
| `32` | hardcopy reference | [NKBIP-03] |
|
||||
| `33` | prompt reference | [NKBIP-03] |
|
||||
| `40` | Channel Creation | [28](28.md) |
|
||||
| `41` | Channel Metadata | [28](28.md) |
|
||||
| `42` | Channel Message | [28](28.md) |
|
||||
@@ -190,7 +185,6 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
|
||||
| `10050` | Relay list to receive DMs | [51](51.md), [17](17.md) |
|
||||
| `10063` | User server list | [Blossom][blossom] |
|
||||
| `10096` | File storage server list | [96](96.md) |
|
||||
| `10166` | Relay Monitor Announcement | [66](66.md) |
|
||||
| `13194` | Wallet Info | [47](47.md) |
|
||||
| `17375` | Cashu Wallet Event | [60](60.md) |
|
||||
| `21000` | Lightning Pub RPC | [Lightning.Pub][lnpub] |
|
||||
@@ -217,11 +211,10 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
|
||||
| `30023` | Long-form Content | [23](23.md) |
|
||||
| `30024` | Draft Long-form Content | [23](23.md) |
|
||||
| `30030` | Emoji sets | [51](51.md) |
|
||||
| `30040` | Curated Publication Index | [NKBIP-01] |
|
||||
| `30041` | Curated Publication Content | [NKBIP-01] |
|
||||
| `30040` | Modular Article Header | [NKBIP-01] |
|
||||
| `30041` | Modular Article Content | [NKBIP-01] |
|
||||
| `30063` | Release artifact sets | [51](51.md) |
|
||||
| `30078` | Application-specific Data | [78](78.md) |
|
||||
| `30166` | Relay Discovery | [66](66.md) |
|
||||
| `30267` | App curation sets | [51](51.md) |
|
||||
| `30311` | Live Event | [53](53.md) |
|
||||
| `30315` | User Statuses | [38](38.md) |
|
||||
@@ -252,9 +245,8 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
|
||||
[cornychat-slideset]: https://cornychat.com/datatypes#kind30388slideset
|
||||
[cornychat-linkset]: https://cornychat.com/datatypes#kind31388linkset
|
||||
[joinstr]: https://gitlab.com/1440000bytes/joinstr/-/blob/main/NIP.md
|
||||
[NKBIP-01]: https://wikistr.com/nkbip-01*fd208ee8c8f283780a9552896e4823cc9dc6bfd442063889577106940fd927c1
|
||||
[NKBIP-02]: https://wikistr.com/nkbip-02*fd208ee8c8f283780a9552896e4823cc9dc6bfd442063889577106940fd927c1
|
||||
[NKBIP-03]: https://wikistr.com/nkbip-03*fd208ee8c8f283780a9552896e4823cc9dc6bfd442063889577106940fd927c1
|
||||
[NKBIP-01]: https://wikistr.com/nkbip-01
|
||||
[NKBIP-02]: https://wikistr.com/nkbip-02
|
||||
[blossom]: https://github.com/hzrd149/blossom
|
||||
[Tidal-nostr]: https://wikistr.com/tidal-nostr
|
||||
|
||||
@@ -384,4 +376,4 @@ All NIPs are public domain.
|
||||
|
||||
<a align="center" href="https://github.com/nostr-protocol/nips/graphs/contributors">
|
||||
<img src="https://contrib.rocks/image?repo=nostr-protocol/nips" />
|
||||
</a>
|
||||
</a>
|
||||
|
||||
Reference in New Issue
Block a user