mirror of
https://github.com/nostr-protocol/nips.git
synced 2025-12-10 09:08:50 +00:00
Compare commits
1 Commits
a079d1c13e
...
nip-17-typ
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
ea587f58d2 |
1
24.md
1
24.md
@@ -17,7 +17,6 @@ These are extra fields not specified in NIP-01 that may be present in the string
|
|||||||
- `website`: a web URL related in any way to the event author.
|
- `website`: a web URL related in any way to the event author.
|
||||||
- `banner`: an URL to a wide (~1024x768) picture to be optionally displayed in the background of a profile screen.
|
- `banner`: an URL to a wide (~1024x768) picture to be optionally displayed in the background of a profile screen.
|
||||||
- `bot`: a boolean to clarify that the content is entirely or partially the result of automation, such as with chatbots or newsfeeds.
|
- `bot`: a boolean to clarify that the content is entirely or partially the result of automation, such as with chatbots or newsfeeds.
|
||||||
- `birthday`: an object representing the author's birth date. The format is { "year": number, "month": number, "day": number }. Each field MAY be omitted.
|
|
||||||
|
|
||||||
### Deprecated fields
|
### Deprecated fields
|
||||||
|
|
||||||
|
|||||||
19
34.md
19
34.md
@@ -125,7 +125,24 @@ Issues may have a `subject` tag, which clients can utilize to display a header.
|
|||||||
|
|
||||||
## Replies
|
## Replies
|
||||||
|
|
||||||
Replies to either a `kind:1621` _issue_ or a `kind:1617` _patch_ event should follow [NIP-22 comment](22.md).
|
Replies are also Markdown text. The difference is that they MUST be issued as replies to either a `kind:1621` _issue_ or a `kind:1617` _patch_ event. The threading of replies and patches should follow NIP-10 rules.
|
||||||
|
|
||||||
|
```jsonc
|
||||||
|
{
|
||||||
|
"kind": 1622,
|
||||||
|
"content": "<markdown text>",
|
||||||
|
"tags": [
|
||||||
|
["a", "30617:<base-repo-owner-pubkey>:<base-repo-id>", "<relay-url>"],
|
||||||
|
["e", "<issue-or-patch-id-hex>", "", "root"],
|
||||||
|
|
||||||
|
// other "e" and "p" tags should be applied here when necessary, following the threading rules of NIP-10
|
||||||
|
["p", "<patch-author-pubkey-hex>", "", "mention"],
|
||||||
|
["e", "<previous-reply-id-hex>", "", "reply"],
|
||||||
|
// rest of tags...
|
||||||
|
],
|
||||||
|
// other fields...
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
## Status
|
## Status
|
||||||
|
|
||||||
|
|||||||
58
45.md
58
45.md
@@ -29,51 +29,15 @@ In case a relay uses probabilistic counts, it MAY indicate it in the response wi
|
|||||||
|
|
||||||
Whenever the relay decides to refuse to fulfill the `COUNT` request, it MUST return a `CLOSED` message.
|
Whenever the relay decides to refuse to fulfill the `COUNT` request, it MUST return a `CLOSED` message.
|
||||||
|
|
||||||
## HyperLogLog
|
|
||||||
|
|
||||||
Relays may return an HyperLogLog value together with the count, hex-encoded.
|
|
||||||
|
|
||||||
```
|
|
||||||
["COUNT", <subscription_id>, {"count": <integer>, "hll": "<hex>"}]
|
|
||||||
```
|
|
||||||
|
|
||||||
This is so it enables merging results from multiple relays and yielding a reasonable estimate of reaction counts, comment counts and follower counts, while saving many millions of bytes of bandwidth for everybody.
|
|
||||||
|
|
||||||
### Algorithm
|
|
||||||
|
|
||||||
This section describes the steps a relay should take in order to return HLL values to clients.
|
|
||||||
|
|
||||||
1. Upon receiving a filter, if it is eligible (see below) for HyperLogLog, compute the deterministic `offset` for that filter (see below);
|
|
||||||
2. Initialize 256 registers to `0` for the HLL value;
|
|
||||||
3. For all the events that are to be counted according to the filter, do this:
|
|
||||||
1. Read the byte at position `offset` of the event `pubkey`, its value will be the register index `ri`;
|
|
||||||
2. Count the number of leading zero bits starting at position `offset+1` of the event `pubkey` and add `1`;
|
|
||||||
3. Compare that with the value stored at register `ri`, if the new number is bigger, store it.
|
|
||||||
|
|
||||||
That is all that has to be done on the relay side, and therefore the only part needed for interoperability.
|
|
||||||
|
|
||||||
On the client side, these HLL values received from different relays can be merged (by simply going through all the registers in HLL values from each relay and picking the highest value for each register, regardless of the relay).
|
|
||||||
|
|
||||||
And finally the absolute count can be estimated by running some methods I don't dare to describe here in English, it's better to check some implementation source code (also, there can be different ways of performing the estimation, with different quirks applied on top of the raw registers).
|
|
||||||
|
|
||||||
### Filter eligibility and `offset` computation
|
|
||||||
|
|
||||||
This NIP defines (for now) two filters eligible for HyperLogLog:
|
|
||||||
|
|
||||||
- `{"#p": ["<pubkey>"], "kinds": [3]}`, i.e. a filter for `kind:3` events with a single `"p"` tag, which means the client is interested in knowing how many people "follow" the target `<pubkey>`. In this case the `offset` will be given by reading the character at the position `32` of the hex `<pubkey>` value as a base-16 number then adding `8` to it.
|
|
||||||
- `{"#e": ["<id>"], "kinds": [7]}`, i.e. a filter for `kind:7` events with a single `"e"` tag, which means the client is interested in knowing how many people have reacted to the target event `<id>`. In this case the `offset` will be given by reading the character at the position `32` of the hex `<id>` value as a base-16 number then adding `8` to it.
|
|
||||||
- `{"#E": ["<id>"], "kinds": [1111]}`, i.e. a filter for the total number of comments any specific root event has received. In this case the `offset` will be given by reading the character at the position `32` of the hex `<id>` value as a base-16 number then adding `8` to it.
|
|
||||||
|
|
||||||
### Attack vectors
|
|
||||||
|
|
||||||
One could mine a pubkey with a certain number of zero bits in the exact place where the HLL algorithm described above would look for them in order to artificially make its reaction or follow "count more" than others. For this to work a different pubkey would have to be created for each different target (event id, followed profile etc). This approach is not very different than creating tons of new pubkeys and using them all to send likes or follow someone in order to inflate their number of followers. The solution is the same in both cases: clients should not fetch these reaction counts from open relays that accept everything, they should base their counts on relays that perform some form of filtering that makes it more likely that only real humans are able to publish there and not bots or artificially-generated pubkeys.
|
|
||||||
|
|
||||||
### `hll` encoding
|
|
||||||
|
|
||||||
The value `hll` value must be the concatenation of the 256 registers, each being a uint8 value (i.e. a byte). Therefore `hll` will be a 512-character hex string.
|
|
||||||
|
|
||||||
## Examples
|
## Examples
|
||||||
|
|
||||||
|
### Followers count
|
||||||
|
|
||||||
|
```
|
||||||
|
["COUNT", <subscription_id>, {"kinds": [3], "#p": [<pubkey>]}]
|
||||||
|
["COUNT", <subscription_id>, {"count": 238}]
|
||||||
|
```
|
||||||
|
|
||||||
### Count posts and reactions
|
### Count posts and reactions
|
||||||
|
|
||||||
```
|
```
|
||||||
@@ -81,7 +45,6 @@ The value `hll` value must be the concatenation of the 256 registers, each being
|
|||||||
["COUNT", <subscription_id>, {"count": 5}]
|
["COUNT", <subscription_id>, {"count": 5}]
|
||||||
```
|
```
|
||||||
|
|
||||||
|
|
||||||
### Count posts approximately
|
### Count posts approximately
|
||||||
|
|
||||||
```
|
```
|
||||||
@@ -89,13 +52,6 @@ The value `hll` value must be the concatenation of the 256 registers, each being
|
|||||||
["COUNT", <subscription_id>, {"count": 93412452, "approximate": true}]
|
["COUNT", <subscription_id>, {"count": 93412452, "approximate": true}]
|
||||||
```
|
```
|
||||||
|
|
||||||
### Followers count with HyperLogLog
|
|
||||||
|
|
||||||
```
|
|
||||||
["COUNT", <subscription_id>, {"kinds": [3], "#p": [<pubkey>]}]
|
|
||||||
["COUNT", <subscription_id>, {"count": 16578, "hll": "0607070505060806050508060707070706090d080b0605090607070b07090606060b0705070709050807080805080407060906080707080507070805060509040a0b06060704060405070706080607050907070b08060808080b080607090a06060805060604070908050607060805050d05060906090809080807050e0705070507060907060606070708080b0807070708080706060609080705060604060409070a0808050a0506050b0810060a0908070709080b0a07050806060508060607080606080707050806080c0a0707070a080808050608080f070506070706070a0908090c080708080806090508060606090906060d07050708080405070708"}]
|
|
||||||
```
|
|
||||||
|
|
||||||
### Relay refuses to count
|
### Relay refuses to count
|
||||||
|
|
||||||
```
|
```
|
||||||
|
|||||||
2
65.md
2
65.md
@@ -63,8 +63,6 @@ This NIP allows Clients to connect directly with the most up-to-date relay set f
|
|||||||
|
|
||||||
6. Clients SHOULD deduplicate connections by normalizing relay URIs according to [RFC 3986](https://datatracker.ietf.org/doc/html/rfc3986#section-6).
|
6. Clients SHOULD deduplicate connections by normalizing relay URIs according to [RFC 3986](https://datatracker.ietf.org/doc/html/rfc3986#section-6).
|
||||||
|
|
||||||
7. When publishing to a relay, clients SHOULD ensure the user's `kind 10002` is also available on that relay. Relays SHOULD accept and serve `kind 10002` notes for any pubkey whose notes they store. Relays MAY scrape the network for missing `kind 10002` events. The goal here is that for any note served from a relay the user can also request the author's relay selections as a way of bootstrapping further context discovery.
|
|
||||||
|
|
||||||
## Related articles
|
## Related articles
|
||||||
- [Outbox model](https://mikedilger.com/gossip-model/)
|
- [Outbox model](https://mikedilger.com/gossip-model/)
|
||||||
- [What is the Outbox Model?](https://habla.news/u/hodlbod@coracle.social/8YjqXm4SKY-TauwjOfLXS)
|
- [What is the Outbox Model?](https://habla.news/u/hodlbod@coracle.social/8YjqXm4SKY-TauwjOfLXS)
|
||||||
|
|||||||
69
73.md
69
73.md
@@ -16,29 +16,26 @@ There are certain established global content identifiers such as [Book ISBNs](ht
|
|||||||
| Type | `i` tag | `k` tag |
|
| Type | `i` tag | `k` tag |
|
||||||
| --- | --- | --- |
|
| --- | --- | --- |
|
||||||
| URLs | "`<URL, normalized, no fragment>`" | "web" |
|
| URLs | "`<URL, normalized, no fragment>`" | "web" |
|
||||||
| Books | "isbn:`<id, without hyphens>`" | "isbn" |
|
|
||||||
| Geohashes | "geo:`<geohash, lowercase>`" | "geo" |
|
|
||||||
| Movies | "isan:`<id, without version part>`" | "isan" |
|
|
||||||
| Papers | "doi:`<id, lowercase>`" | "doi" |
|
|
||||||
| Hashtags | "#`<topic, lowercase>`" | "#" |
|
| Hashtags | "#`<topic, lowercase>`" | "#" |
|
||||||
|
| Geohashes | "geo:`<geohash, lowercase>`" | "geo" |
|
||||||
|
| Books | "isbn:`<id, without hyphens>`" | "isbn" |
|
||||||
| Podcast Feeds | "podcast:guid:`<guid>`" | "podcast:guid" |
|
| Podcast Feeds | "podcast:guid:`<guid>`" | "podcast:guid" |
|
||||||
| Podcast Episodes | "podcast:item:guid:`<guid>`" | "podcast:item:guid" |
|
| Podcast Episodes | "podcast:item:guid:`<guid>`" | "podcast:item:guid" |
|
||||||
| Podcast Publishers | "podcast:publisher:guid:`<guid>`" | "podcast:publisher:guid" |
|
| Podcast Publishers | "podcast:publisher:guid:`<guid>`" | "podcast:publisher:guid" |
|
||||||
| Blockchain Transaction | "`<blockchain>`:[`<chainId>`:]tx:`<txid, hex, lowercase>`" | "`<blockchain>`:tx" |
|
| Movies | "isan:`<id, without version part>`" | "isan" |
|
||||||
| Blockchain Address | "`<blockchain>`:[`<chainId>`:]address:`<address>`" | "`<blockchain>`:address" |
|
| Papers | "doi:`<id, lowercase>`" | "doi" |
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## Examples
|
## Examples
|
||||||
|
|
||||||
|
|
||||||
### Webpages
|
### Webpages
|
||||||
|
|
||||||
For the webpage "https://myblog.example.com/post/2012-03-27/hello-world" the "i" and "k" tags are:
|
For the webpage "https://myblog.example.com/post/2012-03-27/hello-world" the "i" and "k" tags are:
|
||||||
|
|
||||||
```jsonc
|
```jsonc
|
||||||
[
|
[
|
||||||
["i", "https://myblog.example.com/post/2012-03-27/hello-world"],
|
["i","https://myblog.example.com/post/2012-03-27/hello-world"],
|
||||||
["k", "web"]
|
["k", "web"]
|
||||||
]
|
]
|
||||||
```
|
```
|
||||||
@@ -61,62 +58,6 @@ Book ISBNs MUST be referenced _**without hyphens**_ as many book search APIs ret
|
|||||||
|
|
||||||
Movie ISANs SHOULD be referenced _**without the version part**_ as the versions / edits of movies are not relevant. More info on ISAN parts here - https://support.isan.org/hc/en-us/articles/360002783131-Records-relations-and-hierarchies-in-the-ISAN-Registry
|
Movie ISANs SHOULD be referenced _**without the version part**_ as the versions / edits of movies are not relevant. More info on ISAN parts here - https://support.isan.org/hc/en-us/articles/360002783131-Records-relations-and-hierarchies-in-the-ISAN-Registry
|
||||||
|
|
||||||
### Blockchain
|
|
||||||
|
|
||||||
`<blockchain>` can be any layer 1 chain (`bitcoin`, `ethereum`, `solana`, ...). If necessary (e.g. for ethereum), you can specify a `<chainId>`.
|
|
||||||
|
|
||||||
#### Bitcoin
|
|
||||||
|
|
||||||
```
|
|
||||||
bitcoin:address:<bech32, lowercase | base58, case sensitive>
|
|
||||||
bitcoin:tx:<txid, hex, lowercase>
|
|
||||||
```
|
|
||||||
|
|
||||||
E.g. https://blockstream.info/tx/a1075db55d416d3ca199f55b6084e2115b9345e16c5cf302fc80e9d5fbf5d48d
|
|
||||||
|
|
||||||
```jsonc
|
|
||||||
[
|
|
||||||
["i", "bitcoin:tx:a1075db55d416d3ca199f55b6084e2115b9345e16c5cf302fc80e9d5fbf5d48d"],
|
|
||||||
["k", "bitcoin:tx"]
|
|
||||||
]
|
|
||||||
```
|
|
||||||
|
|
||||||
E.g. https://blockstream.info/address/1HQ3Go3ggs8pFnXuHVHRytPCq5fGG8Hbhx
|
|
||||||
|
|
||||||
```jsonc
|
|
||||||
[
|
|
||||||
["i", "bitcoin:address:1HQ3Go3ggs8pFnXuHVHRytPCq5fGG8Hbhx"],
|
|
||||||
["k", "bitcoin:address"]
|
|
||||||
]
|
|
||||||
```
|
|
||||||
|
|
||||||
#### Ethereum (and other EVM chains)
|
|
||||||
|
|
||||||
```
|
|
||||||
ethereum:<chainId, integer>:tx:<txHash, hex, lowercase>
|
|
||||||
ethereum:<chainId, integer>:address:<hex, lowercase>
|
|
||||||
```
|
|
||||||
|
|
||||||
E.g. https://etherscan.io/address/0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045
|
|
||||||
|
|
||||||
```jsonc
|
|
||||||
[
|
|
||||||
["i", "ethereum:1:address:0xd8da6bf26964af9d7eed9e03e53415d37aa96045"],
|
|
||||||
["k", "ethereum:address"]
|
|
||||||
]
|
|
||||||
```
|
|
||||||
|
|
||||||
E.g. https://gnosisscan.io/tx/0x98f7812be496f97f80e2e98d66358d1fc733cf34176a8356d171ea7fbbe97ccd
|
|
||||||
|
|
||||||
```jsonc
|
|
||||||
[
|
|
||||||
["i", "ethereum:100:tx:0x98f7812be496f97f80e2e98d66358d1fc733cf34176a8356d171ea7fbbe97ccd"],
|
|
||||||
["k", "ethereum:tx"]
|
|
||||||
]
|
|
||||||
```
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
### Optional URL Hints
|
### Optional URL Hints
|
||||||
|
|||||||
65
C0.md
65
C0.md
@@ -1,65 +0,0 @@
|
|||||||
# NIP-C0: Code Snippets
|
|
||||||
|
|
||||||
`draft` `optional`
|
|
||||||
|
|
||||||
## Abstract
|
|
||||||
|
|
||||||
This NIP defines a new event kind for sharing and storing code snippets. Unlike regular text notes (`kind:1`), code snippets have specialized metadata like language, extension, and other code-specific attributes that enhance discoverability, syntax highlighting, and improved user experience.
|
|
||||||
|
|
||||||
## Event Kind
|
|
||||||
|
|
||||||
This NIP defines `kind:1337` as a code snippet event.
|
|
||||||
|
|
||||||
The `.content` field contains the actual code snippet text.
|
|
||||||
|
|
||||||
## Optional Tags
|
|
||||||
|
|
||||||
- `l` - Programming language name (lowercase). Examples: "javascript", "python", "rust"
|
|
||||||
- `name` - Name of the code snippet, commonly a filename. Examples: "hello-world.js", "quick-sort.py"
|
|
||||||
- `extension` - File extension (without the dot). Examples: "js", "py", "rs"
|
|
||||||
- `description` - Brief description of what the code does
|
|
||||||
- `runtime` - Runtime or environment specification (e.g., "node v18.15.0", "python 3.11")
|
|
||||||
- `license` - License under which the code is shared (e.g., "MIT", "GPL-3.0", "Apache-2.0")
|
|
||||||
- `dep` - Dependency required for the code to run (can be repeated)
|
|
||||||
- `repo` - Reference to a repository where this code originates
|
|
||||||
|
|
||||||
## Format
|
|
||||||
|
|
||||||
```json
|
|
||||||
{
|
|
||||||
"id": "<32-bytes lowercase hex-encoded SHA-256 of the the serialized event data>",
|
|
||||||
"pubkey": "<32-bytes lowercase hex-encoded public key of the event creator>",
|
|
||||||
"created_at": <Unix timestamp in seconds>,
|
|
||||||
"kind": 1337,
|
|
||||||
"content": "function helloWorld() {\n console.log('Hello, Nostr!');\n}\n\nhelloWorld();",
|
|
||||||
"tags": [
|
|
||||||
["l", "javascript"],
|
|
||||||
["extension", "js"],
|
|
||||||
["name", "hello-world.js"],
|
|
||||||
["description", "A basic JavaScript function that prints 'Hello, Nostr!' to the console"],
|
|
||||||
["runtime", "node v18.15.0"],
|
|
||||||
["license", "MIT"],
|
|
||||||
["repo", "https://github.com/nostr-protocol/nostr"]
|
|
||||||
],
|
|
||||||
"sig": "<64-bytes signature of the id>"
|
|
||||||
}
|
|
||||||
```
|
|
||||||
|
|
||||||
## Client Behavior
|
|
||||||
|
|
||||||
Clients that support this NIP SHOULD:
|
|
||||||
|
|
||||||
1. Display code snippets with proper syntax highlighting based on the language.
|
|
||||||
2. Allow copying the full code snippet with a single action.
|
|
||||||
3. Render the code with appropriate formatting, preserving whitespace and indentation.
|
|
||||||
4. Display the language and extension prominently.
|
|
||||||
5. Provide "run" functionality for supported languages when possible.
|
|
||||||
6. Display the description (if available) as part of the snippet presentation.
|
|
||||||
|
|
||||||
Clients MAY provide additional functionality such as:
|
|
||||||
|
|
||||||
1. Code editing capabilities
|
|
||||||
2. Forking/modifying snippets
|
|
||||||
3. Creating executable environments based on the runtime/dependencies
|
|
||||||
4. Downloading the snippet as a file using the provided extension
|
|
||||||
5. Sharing the snippet with attribution
|
|
||||||
15
README.md
15
README.md
@@ -100,7 +100,6 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
|
|||||||
- [NIP-98: HTTP Auth](98.md)
|
- [NIP-98: HTTP Auth](98.md)
|
||||||
- [NIP-99: Classified Listings](99.md)
|
- [NIP-99: Classified Listings](99.md)
|
||||||
- [NIP-7D: Threads](7D.md)
|
- [NIP-7D: Threads](7D.md)
|
||||||
- [NIP-C0: Code Snippets](C0.md)
|
|
||||||
- [NIP-C7: Chats](C7.md)
|
- [NIP-C7: Chats](C7.md)
|
||||||
|
|
||||||
## Event Kinds
|
## Event Kinds
|
||||||
@@ -149,10 +148,9 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
|
|||||||
| `1068` | Poll | [88](88.md) |
|
| `1068` | Poll | [88](88.md) |
|
||||||
| `1111` | Comment | [22](22.md) |
|
| `1111` | Comment | [22](22.md) |
|
||||||
| `1311` | Live Chat Message | [53](53.md) |
|
| `1311` | Live Chat Message | [53](53.md) |
|
||||||
| `1337` | Code Snippet | [C0](C0.md) |
|
|
||||||
| `1617` | Patches | [34](34.md) |
|
| `1617` | Patches | [34](34.md) |
|
||||||
| `1621` | Issues | [34](34.md) |
|
| `1621` | Issues | [34](34.md) |
|
||||||
| `1622` | Git Replies (deprecated) | [34](34.md) |
|
| `1622` | Replies | [34](34.md) |
|
||||||
| `1630`-`1633` | Status | [34](34.md) |
|
| `1630`-`1633` | Status | [34](34.md) |
|
||||||
| `1971` | Problem Tracker | [nostrocket][nostrocket] |
|
| `1971` | Problem Tracker | [nostrocket][nostrocket] |
|
||||||
| `1984` | Reporting | [56](56.md) |
|
| `1984` | Reporting | [56](56.md) |
|
||||||
@@ -300,7 +298,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
|
|||||||
| `I` | root external identity | -- | [22](22.md) |
|
| `I` | root external identity | -- | [22](22.md) |
|
||||||
| `k` | kind | -- | [18](18.md), [25](25.md), [72](72.md), [73](73.md) |
|
| `k` | kind | -- | [18](18.md), [25](25.md), [72](72.md), [73](73.md) |
|
||||||
| `K` | root scope | -- | [22](22.md) |
|
| `K` | root scope | -- | [22](22.md) |
|
||||||
| `l` | label, label namespace, language name| -- | [32](32.md), [C0](C0.md) |
|
| `l` | label, label namespace | -- | [32](32.md) |
|
||||||
| `L` | label namespace | -- | [32](32.md) |
|
| `L` | label namespace | -- | [32](32.md) |
|
||||||
| `m` | MIME type | -- | [94](94.md) |
|
| `m` | MIME type | -- | [94](94.md) |
|
||||||
| `p` | pubkey (hex) | relay URL, petname | [01](01.md), [02](02.md), [22](22.md) |
|
| `p` | pubkey (hex) | relay URL, petname | [01](01.md), [02](02.md), [22](22.md) |
|
||||||
@@ -323,20 +321,17 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
|
|||||||
| `clone` | git clone URL | -- | [34](34.md) |
|
| `clone` | git clone URL | -- | [34](34.md) |
|
||||||
| `content-warning` | reason | -- | [36](36.md) |
|
| `content-warning` | reason | -- | [36](36.md) |
|
||||||
| `delegation` | pubkey, conditions, delegation token | -- | [26](26.md) |
|
| `delegation` | pubkey, conditions, delegation token | -- | [26](26.md) |
|
||||||
| `dep` | Required dependency | -- | [C0](C0.md) |
|
| `description` | description | -- | [34](34.md), [57](57.md), [58](58.md) |
|
||||||
| `description` | description | -- | [34](34.md), [57](57.md), [58](58.md), [C0](C0.md) |
|
|
||||||
| `emoji` | shortcode, image URL | -- | [30](30.md) |
|
| `emoji` | shortcode, image URL | -- | [30](30.md) |
|
||||||
| `encrypted` | -- | -- | [90](90.md) |
|
| `encrypted` | -- | -- | [90](90.md) |
|
||||||
| `extension` | File extension | -- | [C0](C0.md) |
|
|
||||||
| `expiration` | unix timestamp (string) | -- | [40](40.md) |
|
| `expiration` | unix timestamp (string) | -- | [40](40.md) |
|
||||||
| `file` | full path (string) | -- | [35](35.md) |
|
| `file` | full path (string) | -- | [35](35.md) |
|
||||||
| `goal` | event id (hex) | relay URL | [75](75.md) |
|
| `goal` | event id (hex) | relay URL | [75](75.md) |
|
||||||
| `image` | image URL | dimensions in pixels | [23](23.md), [52](52.md), [58](58.md) |
|
| `image` | image URL | dimensions in pixels | [23](23.md), [52](52.md), [58](58.md) |
|
||||||
| `imeta` | inline metadata | -- | [92](92.md) |
|
| `imeta` | inline metadata | -- | [92](92.md) |
|
||||||
| `license` | License of the shared content | -- | [C0](C0.md) |
|
|
||||||
| `lnurl` | `bech32` encoded `lnurl` | -- | [57](57.md) |
|
| `lnurl` | `bech32` encoded `lnurl` | -- | [57](57.md) |
|
||||||
| `location` | location string | -- | [52](52.md), [99](99.md) |
|
| `location` | location string | -- | [52](52.md), [99](99.md) |
|
||||||
| `name` | name | -- | [34](34.md), [58](58.md), [72](72.md), [C0](C0.md) |
|
| `name` | name | -- | [34](34.md), [58](58.md), [72](72.md) |
|
||||||
| `nonce` | random | difficulty | [13](13.md) |
|
| `nonce` | random | difficulty | [13](13.md) |
|
||||||
| `preimage` | hash of `bolt11` invoice | -- | [57](57.md) |
|
| `preimage` | hash of `bolt11` invoice | -- | [57](57.md) |
|
||||||
| `price` | price | currency, frequency | [99](99.md) |
|
| `price` | price | currency, frequency | [99](99.md) |
|
||||||
@@ -344,8 +339,6 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
|
|||||||
| `published_at` | unix timestamp (string) | -- | [23](23.md) |
|
| `published_at` | unix timestamp (string) | -- | [23](23.md) |
|
||||||
| `relay` | relay url | -- | [42](42.md), [17](17.md) |
|
| `relay` | relay url | -- | [42](42.md), [17](17.md) |
|
||||||
| `relays` | relay list | -- | [57](57.md) |
|
| `relays` | relay list | -- | [57](57.md) |
|
||||||
| `repo` | Reference to the origin repository | -- | [C0](C0.md) |
|
|
||||||
| `runtime` | Runtime or environment specification | -- | [C0](C0.md) |
|
|
||||||
| `server` | file storage server url | -- | [96](96.md) |
|
| `server` | file storage server url | -- | [96](96.md) |
|
||||||
| `subject` | subject | -- | [14](14.md), [17](17.md), [34](34.md) |
|
| `subject` | subject | -- | [14](14.md), [17](17.md), [34](34.md) |
|
||||||
| `summary` | summary | -- | [23](23.md), [52](52.md) |
|
| `summary` | summary | -- | [23](23.md), [52](52.md) |
|
||||||
|
|||||||
Reference in New Issue
Block a user