mirror of
https://github.com/nostr-protocol/nips.git
synced 2025-12-09 16:48:50 +00:00
Compare commits
2 Commits
key-invali
...
Giszmo-pat
| Author | SHA1 | Date | |
|---|---|---|---|
|
d5906545f8 | ||
|
|
535cfcc7e5 |
12
01.md
12
01.md
@@ -16,7 +16,7 @@ The only object type that exists is the `event`, which has the following format
|
||||
|
||||
```json
|
||||
{
|
||||
"id": <32-bytes lowercase hex-encoded sha256 of the serialized event data>,
|
||||
"id": <32-bytes lowercase hex-encoded sha256 of the serialized event data>
|
||||
"pubkey": <32-bytes lowercase hex-encoded public key of the event creator>,
|
||||
"created_at": <unix timestamp in seconds>,
|
||||
"kind": <integer>,
|
||||
@@ -66,8 +66,8 @@ Clients can send 3 types of messages, which must be JSON arrays, according to th
|
||||
"kinds": <a list of a kind numbers>,
|
||||
"#e": <a list of event ids that are referenced in an "e" tag>,
|
||||
"#p": <a list of pubkeys that are referenced in a "p" tag>,
|
||||
"since": <an integer unix timestamp in seconds, events must be newer than this to pass>,
|
||||
"until": <an integer unix timestamp in seconds, events must be older than this to pass>,
|
||||
"since": <an integer unix timestamp, events must be newer than this to pass>,
|
||||
"until": <an integer unix timestamp, events must be older than this to pass>,
|
||||
"limit": <maximum number of events to be returned in the initial query>
|
||||
}
|
||||
```
|
||||
@@ -99,7 +99,7 @@ This NIP defines no rules for how `NOTICE` messages should be sent or treated.
|
||||
## Basic Event Kinds
|
||||
|
||||
- `0`: `set_metadata`: the `content` is set to a stringified JSON object `{name: <username>, about: <string>, picture: <url, string>}` describing the user who created the event. A relay may delete past `set_metadata` events once it gets a new one for the same pubkey.
|
||||
- `1`: `text_note`: the `content` is set to the **plaintext** content of a note (anything the user wants to say). Content that must be parsed, such as Markdown and HTML, should not be used. Clients should also not parse content as those.
|
||||
- `1`: `text_note`: the `content` is set to the plaintext content of a note (anything the user wants to say). Markdown links (`[]()` stuff) are not plaintext.
|
||||
- `2`: `recommend_server`: the `content` is set to the URL (e.g., `wss://somerelay.com`) of a relay the event creator wants to recommend to its followers.
|
||||
|
||||
A relay may choose to treat different message kinds differently, and it may or may not choose to have a default way to handle kinds it doesn't know about.
|
||||
@@ -107,7 +107,5 @@ A relay may choose to treat different message kinds differently, and it may or m
|
||||
## Other Notes:
|
||||
|
||||
- Clients should not open more than one websocket to each relay. One channel can support an unlimited number of subscriptions, so clients should do that.
|
||||
- The `tags` array can store a tag identifier as the first element of each subarray, plus arbitrary information afterward (always as strings). This NIP defines `"p"` — meaning "pubkey", which points to a pubkey of someone that is referred to in the event —, and `"e"` — meaning "event", which points to the id of an event this event is quoting, replying to or referring to somehow. See [NIP-10](10.md) for a detailed description of "e" and "p" tags.
|
||||
- The `tags` array can store a tag identifier as the first element of each subarray, plus arbitrary information afterward (always as strings). This NIP defines `"p"` — meaning "pubkey", which points to a pubkey of someone that is referred to in the event —, and `"e"` — meaning "event", which points to the id of an event this event is quoting, replying to or referring to somehow. See [NIP-10](https://github.com/nostr-protocol/nips/blob/127d5518bfa9a4e4e7510490c0b8d95e342dfa4b/10.md) for a detailed description of "e" and "p" tags.
|
||||
- The `<recommended relay URL>` item present on the `"e"` and `"p"` tags is an optional (could be set to `""`) URL of a relay the client could attempt to connect to fetch the tagged event or other events from a tagged profile. It MAY be ignored, but it exists to increase censorship resistance and make the spread of relay addresses more seamless across clients.
|
||||
- Clients should use the created_at field to judge the age of a metadata event and completely replace older metadata events with newer metadata events regardless of the order in which they arrive. Clients should not merge any filled fields within older metadata events into empty fields of newer metadata events.
|
||||
- When a websocket is closed by the relay with a status code 4000 that means the client shouldn't try to connect again.
|
||||
|
||||
6
05.md
6
05.md
@@ -6,7 +6,7 @@ Mapping Nostr keys to DNS-based internet identifiers
|
||||
|
||||
`final` `optional` `author:fiatjaf` `author:mikedilger`
|
||||
|
||||
On events of kind `0` (`set_metadata`) one can specify the key `"nip05"` with an [internet identifier](https://datatracker.ietf.org/doc/html/rfc5322#section-3.4.1) (an email-like address) as the value. Although there is a link to a very liberal "internet identifier" specification above, NIP-05 assumes the `<local-part>` part will be restricted to the characters `a-z0-9-_.`, case-insensitive.
|
||||
On events of kind `0` (`set_metadata`) one can specify the key `"nip05"` with an [internet identifier](https://datatracker.ietf.org/doc/html/rfc5322#section-3.4.1) (an email-like address) as the value. Although there is a link to a very liberal "internet identifier" specification above, NIP-05 assumes the `<local-part>` part will be restricted to the characters `a-z0-9-_.`, case insensitive.
|
||||
|
||||
Upon seeing that, the client splits the identifier into `<local-part>` and `<domain>` and use these values to make a GET request to `https://<domain>/.well-known/nostr.json?name=<local-part>`.
|
||||
|
||||
@@ -50,7 +50,7 @@ or with the **optional** `"relays"` attribute:
|
||||
|
||||
If the pubkey matches the one given in `"names"` (as in the example above) that means the association is right and the `"nip05"` identifier is valid and can be displayed.
|
||||
|
||||
The optional `"relays"` attribute may contain an object with public keys as properties and arrays of relay URLs as values. When present, that can be used to help clients learn in which relays the specific user may be found. Web servers which serve `/.well-known/nostr.json` files dynamically based on the query string SHOULD also serve the relays data for any name they serve in the same reply when that is available.
|
||||
The optional `"relays"` attribute may contain an object with public keys as properties and arrays of relay URLs as values. When present, that can be used to help clients learn in which relays that user may be found. Web servers which serve `/.well-known/nostr.json` files dynamically based on the query string SHOULD also serve the relays data for any name they serve in the same reply when that is available.
|
||||
|
||||
## Finding users from their NIP-05 identifier
|
||||
|
||||
@@ -76,7 +76,7 @@ Clients may treat the identifier `_@domain` as the "root" identifier, and choose
|
||||
|
||||
### Reasoning for the `/.well-known/nostr.json?name=<local-part>` format
|
||||
|
||||
By adding the `<local-part>` as a query string instead of as part of the path, the protocol can support both dynamic servers that can generate JSON on-demand and static servers with a JSON file in it that may contain multiple names.
|
||||
By adding the `<local-part>` as a query string instead of as part of the path the protocol can support both dynamic servers that can generate JSON on-demand and static servers with a JSON file in it that may contain multiple names.
|
||||
|
||||
### Allowing access from JavaScript apps
|
||||
|
||||
|
||||
5
07.md
5
07.md
@@ -26,10 +26,7 @@ async window.nostr.nip04.decrypt(pubkey, ciphertext): string // takes ciphertext
|
||||
|
||||
- [horse](https://github.com/fiatjaf/horse) (Chrome and derivatives)
|
||||
- [nos2x](https://github.com/fiatjaf/nos2x) (Chrome and derivatives)
|
||||
- [Alby](https://getalby.com) (Chrome and derivatives, Firefox)
|
||||
- [Alby](https://getalby.com) (Chrome and derivatives, Firefox, Safari)
|
||||
- [Blockcore](https://www.blockcore.net/wallet) (Chrome and derivatives)
|
||||
- [nos2x-fox](https://diegogurpegui.com/nos2x-fox/) (Firefox)
|
||||
- [Flamingo](https://www.getflamingo.org/) (Chrome and derivatives)
|
||||
- [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)
|
||||
|
||||
3
09.md
3
09.md
@@ -8,7 +8,7 @@ Event Deletion
|
||||
|
||||
A special event with kind `5`, meaning "deletion" is defined as having a list of one or more `e` tags, each referencing an event the author is requesting to be deleted.
|
||||
|
||||
Each tag entry must contain an "e" event id and/or NIP-33 `a` tags intended for deletion.
|
||||
Each tag entry must contain an "e" event id intended for deletion.
|
||||
|
||||
The event's `content` field MAY contain a text note describing the reason for the deletion.
|
||||
|
||||
@@ -21,7 +21,6 @@ For example:
|
||||
"tags": [
|
||||
["e", "dcd59..464a2"],
|
||||
["e", "968c5..ad7a4"],
|
||||
["a", "<kind>:<pubkey>:<d-identifier>"]
|
||||
],
|
||||
"content": "these posts were published by accident",
|
||||
...other fields
|
||||
|
||||
75
11.md
75
11.md
@@ -69,18 +69,18 @@ are rejected or fail immediately.
|
||||
```json
|
||||
{
|
||||
...
|
||||
"limitation": {
|
||||
"max_message_length": 16384,
|
||||
"max_subscriptions": 20,
|
||||
"max_filters": 100,
|
||||
"max_limit": 5000,
|
||||
"max_subid_length": 100,
|
||||
"min_prefix": 4,
|
||||
"max_event_tags": 100,
|
||||
"max_content_length": 8196,
|
||||
"min_pow_difficulty": 30,
|
||||
"auth_required": true,
|
||||
"payment_required": true,
|
||||
limitation: {
|
||||
max_message_length: 16384,
|
||||
max_subscriptions: 20,
|
||||
max_filters: 100,
|
||||
max_limit: 5000,
|
||||
max_subid_length: 100,
|
||||
min_prefix: 4,
|
||||
max_event_tags: 100,
|
||||
max_content_length: 8196,
|
||||
min_pow_difficulty: 30,
|
||||
auth_required: true,
|
||||
payment_required: true,
|
||||
}
|
||||
...
|
||||
}
|
||||
@@ -141,11 +141,11 @@ all, and preferably an error will be provided when those are received.
|
||||
```json
|
||||
{
|
||||
...
|
||||
"retention": [
|
||||
{ "kinds": [0, 1, [5, 7], [40, 49]], "time": 3600 },
|
||||
{ "kinds": [[40000, 49999]], "time": 100 },
|
||||
{ "kinds": [[30000, 39999]], "count": 1000 },
|
||||
{ "time": 3600, "count": 10000 }
|
||||
retention: [
|
||||
{ kinds: [0, 1, [5, 7], [40, 49]], time: 3600 },
|
||||
{ kinds: [[40000, 49999], time: 100 },
|
||||
{ kinds: [[30000, 39999], count: 1000 },
|
||||
{ time: 3600, count: 10000 }
|
||||
]
|
||||
...
|
||||
}
|
||||
@@ -154,7 +154,7 @@ all, and preferably an error will be provided when those are received.
|
||||
`retention` is a list of specifications: each will apply to either all kinds, or
|
||||
a subset of kinds. Ranges may be specified for the kind field as a tuple of inclusive
|
||||
start and end values. Events of indicated kind (or all) are then limited to a `count`
|
||||
and/or time period.
|
||||
and or time period.
|
||||
|
||||
It is possible to effectively blacklist Nostr-based protocols that rely on
|
||||
a specific `kind` number, by giving a retention time of zero for those `kind` values.
|
||||
@@ -175,8 +175,8 @@ It is not possible to describe the limitations of each country's laws
|
||||
and policies which themselves are typically vague and constantly shifting.
|
||||
|
||||
Therefore, this field allows the relay operator to indicate which
|
||||
countries' laws might end up being enforced on them, and then
|
||||
indirectly on their users' content.
|
||||
country's' laws might end up being enforced on them, and then
|
||||
indirectly on their users's content.
|
||||
|
||||
Users should be able to avoid relays in countries they don't like,
|
||||
and/or select relays in more favourable zones. Exposing this
|
||||
@@ -185,7 +185,7 @@ flexibility is up to the client software.
|
||||
```json
|
||||
{
|
||||
...
|
||||
"relay_countries": [ "CA", "US" ],
|
||||
relay_countries: [ 'CA', 'US' ],
|
||||
...
|
||||
}
|
||||
```
|
||||
@@ -208,9 +208,9 @@ To support this goal, relays MAY specify some of the following values.
|
||||
```json
|
||||
{
|
||||
...
|
||||
"language_tags": [ "en", "en-419" ],
|
||||
"tags": [ "sfw-only", "bitcoin-only", "anime" ],
|
||||
"posting_policy": "https://example.com/posting-policy.html",
|
||||
language_tags: [ 'en', 'en-419' ],
|
||||
tags: [ 'sfw-only', 'bitcoin-only', 'anime' ],
|
||||
posting_policy: 'https://example.com/posting-policy.html',
|
||||
...
|
||||
}
|
||||
```
|
||||
@@ -220,7 +220,7 @@ To support this goal, relays MAY specify some of the following values.
|
||||
the major languages spoken on the relay.
|
||||
|
||||
- `tags` is a list of limitations on the topics to be discussed.
|
||||
For example `sfw-only` indicates that only "Safe For Work" content
|
||||
For example `sfw-only` indicates hat only "Safe For Work" content
|
||||
is encouraged on this relay. This relies on assumptions of what the
|
||||
"work" "community" feels "safe" talking about. In time, a common
|
||||
set of tags may emerge that allow users to find relays that suit
|
||||
@@ -245,28 +245,16 @@ Relays that require payments may want to expose their fee schedules.
|
||||
```json
|
||||
{
|
||||
...
|
||||
"payments_url": "https://my-relay/payments",
|
||||
"fees": {
|
||||
"admission": [{ "amount": 1000000, "unit": "msats" }],
|
||||
"subscription": [{ "amount": 5000000, "unit": "msats", "period": 2592000 }],
|
||||
"publication": [{ "kinds": [4], "amount": 100, "unit": "msats" }],
|
||||
payments_url: "https://my-relay/payments",
|
||||
fees: {
|
||||
"admission": [{ amount: 1000000, unit: 'msats' }],
|
||||
"subscription": [{ amount: 5000000, unit: 'msats', period: 2592000 }],
|
||||
"publication": [{ kinds: [4], amount: 100, unit: 'msats' }],
|
||||
},
|
||||
...
|
||||
}
|
||||
```
|
||||
|
||||
### Icon ###
|
||||
|
||||
A URL pointing to an image to be used as an icon for the relay. Recommended to be squared in shape.
|
||||
|
||||
```json
|
||||
{
|
||||
...
|
||||
"icon": "https://nostr.build/i/53866b44135a27d624e99c6165cabd76ac8f72797209700acb189fce75021f47.jpg",
|
||||
...
|
||||
}
|
||||
```
|
||||
|
||||
### Examples ###
|
||||
As of 2 May 2023 the following `curl` command provided these results.
|
||||
|
||||
@@ -293,5 +281,4 @@ As of 2 May 2023 the following `curl` command provided these results.
|
||||
"payment_required":true},
|
||||
"payments_url":"https://eden.nostr.land/invoices",
|
||||
"fees":{"admission":[{"amount":5000000,"unit":"msats"}],
|
||||
"publication":[]}},
|
||||
"icon": "https://nostr.build/i/53866b44135a27d624e99c6165cabd76ac8f72797209700acb189fce75021f47.jpg"
|
||||
"publication":[]}}
|
||||
|
||||
4
15.md
4
15.md
@@ -38,8 +38,8 @@ A merchant can publish these events:
|
||||
| `0 ` | `set_meta` | The merchant description (similar with any `nostr` public key). | [NIP01 ](https://github.com/nostr-protocol/nips/blob/master/01.md) |
|
||||
| `30017` | `set_stall` | Create or update a stall. | [NIP33](https://github.com/nostr-protocol/nips/blob/master/33.md) (Parameterized Replaceable Event) |
|
||||
| `30018` | `set_product` | Create or update a product. | [NIP33](https://github.com/nostr-protocol/nips/blob/master/33.md) (Parameterized Replaceable Event) |
|
||||
| `4 ` | `direct_message` | Communicate with the customer. The messages can be plain-text or JSON. | [NIP04](https://github.com/nostr-protocol/nips/blob/master/04.md) |
|
||||
| `5 ` | `delete` | Delete a product or a stall. | [NIP09](https://github.com/nostr-protocol/nips/blob/master/09.md) |
|
||||
| `4 ` | `direct_message` | Communicate with the customer. The messages can be plain-text or JSON. | [NIP09](https://github.com/nostr-protocol/nips/blob/master/09.md) |
|
||||
| `5 ` | `delete` | Delete a product or a stall. | [NIP05](https://github.com/nostr-protocol/nips/blob/master/05.md) |
|
||||
|
||||
### Event `30017`: Create or update a stall.
|
||||
|
||||
|
||||
2
16.md
2
16.md
@@ -20,8 +20,6 @@ Upon a replaceable event with a newer timestamp than the currently known latest
|
||||
effectively replacing what gets returned when querying for
|
||||
`author:kind` tuples.
|
||||
|
||||
If two events have the same timestamp, the event with the lowest id (first in lexical order) SHOULD be retained, and the other discarded.
|
||||
|
||||
Ephemeral Events
|
||||
----------------
|
||||
An *ephemeral event* is defined as an event with a kind `20000 <= n < 30000`.
|
||||
|
||||
21
18.md
21
18.md
@@ -6,10 +6,11 @@ Reposts
|
||||
|
||||
`draft` `optional` `author:jb55` `author:fiatjaf` `author:arthurfranca`
|
||||
|
||||
A repost is a `kind 6` event that is used to signal to followers
|
||||
that a `kind 1` text note is worth reading.
|
||||
A repost is a `kind 6` note that is used to signal to followers
|
||||
that another event is worth reading.
|
||||
|
||||
The `content` of a repost event is _the stringified JSON of the reposted note_. It MAY also be empty, but that is not recommended.
|
||||
The `content` of a repost event is empty. Optionally, it MAY contain
|
||||
the stringified JSON of the reposted note event for quick look up.
|
||||
|
||||
The repost event MUST include an `e` tag with the `id` of the note that is
|
||||
being reposted. That tag MUST include a relay URL as its third entry
|
||||
@@ -20,15 +21,5 @@ reposted.
|
||||
|
||||
## Quote Reposts
|
||||
|
||||
Quote reposts are `kind 1` events with an embedded `e` tag
|
||||
(see [NIP-08](08.md) and [NIP-27](27.md)). Because a quote repost includes
|
||||
an `e` tag, it may show up along replies to the reposted note.
|
||||
|
||||
## Generic Reposts
|
||||
|
||||
Since `kind 6` reposts are reserved for `kind 1` contents, we use `kind 16`
|
||||
as a "generic repost", that can include any kind of event inside other than
|
||||
`kind 1`.
|
||||
|
||||
`kind 16` reposts SHOULD contain a `k` tag with the stringified kind number
|
||||
of the reposted event as its value.
|
||||
Quote reposts are `kind 1` events with an embedded `e` tag (see [NIP-08](08.md) and [NIP-27](27.md)).
|
||||
Because a quote repost includes an `e` tag, it may show up along replies to the reposted note.
|
||||
|
||||
2
23.md
2
23.md
@@ -6,7 +6,7 @@ Long-form Content
|
||||
|
||||
`draft` `optional` `author:fiatjaf`
|
||||
|
||||
This NIP defines `kind:30023` (a parameterized replaceable event according to [NIP-33](33.md)) for long-form text content, generally referred to as "articles" or "blog posts". `kind:30024` has the same structure as `kind:30023` and is used to save long form drafts.
|
||||
This NIP defines `kind:30023` (a parameterized replaceable event according to [NIP-33](33.md)) for long-form text content, generally referred to as "articles" or "blog posts".
|
||||
|
||||
"Social" clients that deal primarily with `kind:1` notes should not be expected to implement this NIP.
|
||||
|
||||
|
||||
6
26.md
6
26.md
@@ -1,4 +1,4 @@
|
||||
NIP-26
|
||||
NIP: 26
|
||||
=======
|
||||
|
||||
Delegated Event Signing
|
||||
@@ -52,9 +52,7 @@ For example, the following condition strings are valid:
|
||||
- `kind=0&kind=1&created_at>1675721813`
|
||||
- `kind=1&created_at>1674777689&created_at<1675721813`
|
||||
|
||||
For the vast majority of use-cases, it is advisable that:
|
||||
1. Query strings should include a `created_at` ***after*** condition reflecting the current time, to prevent the delegatee from publishing historic notes on the delegator's behalf.
|
||||
2. Query strings should include a `created_at` ***before*** condition that is not empty and is not some extremely distant time in the future. If delegations are not limited in time scope, they expose similar security risks to simply using the root key for authentication.
|
||||
For the vast majority of use-cases, it is advisable that query strings should include a `created_at` ***after*** condition reflecting the current time, to prevent the delegatee from publishing historic notes on the delegator's behalf.
|
||||
|
||||
#### Example
|
||||
|
||||
|
||||
2
28.md
2
28.md
@@ -37,7 +37,7 @@ In the channel creation `content` field, Client SHOULD include basic channel met
|
||||
|
||||
Update a channel's public metadata.
|
||||
|
||||
Clients and relays SHOULD handle kind 41 events similar to kind 33 replaceable events, where the information is used to update the metadata, without modifying the event id for the channel. Only the most recent kind 41 is needed to be stored.
|
||||
Clients and relays SHOULD handle kind 41 events similar to kind 0 `metadata` events.
|
||||
|
||||
Clients SHOULD ignore kind 41s from pubkeys other than the kind 40 pubkey.
|
||||
|
||||
|
||||
56
30.md
56
30.md
@@ -1,56 +0,0 @@
|
||||
NIP-30
|
||||
======
|
||||
|
||||
Custom Emoji
|
||||
------------
|
||||
|
||||
`draft` `optional` `author:alexgleason`
|
||||
|
||||
Custom emoji may be added to **kind 0** and **kind 1** events by including one or more `"emoji"` tags, in the form:
|
||||
|
||||
```
|
||||
["emoji", <shortcode>, <image-url>]
|
||||
```
|
||||
|
||||
Where:
|
||||
|
||||
- `<shortcode>` is a name given for the emoji, which MUST be comprised of only alphanumeric characters and underscores.
|
||||
- `<image-url>` is a URL to the corresponding image file of the emoji.
|
||||
|
||||
For each emoji tag, clients should parse emoji shortcodes (aka "emojify") like `:shortcode:` in the event to display custom emoji.
|
||||
|
||||
Clients may allow users to add custom emoji to an event by including `:shortcode:` identifier in the event, and adding the relevant `"emoji"` tags.
|
||||
|
||||
### Kind 0 events
|
||||
|
||||
In kind 0 events, the `name` and `about` fields should be emojified.
|
||||
|
||||
```json
|
||||
{
|
||||
"kind": 0,
|
||||
"content": "{\"name\":\"Alex Gleason :soapbox:\"}",
|
||||
"tags": [
|
||||
["emoji", "soapbox", "https://gleasonator.com/emoji/Gleasonator/soapbox.png"]
|
||||
],
|
||||
"pubkey": "79c2cae114ea28a981e7559b4fe7854a473521a8d22a66bbab9fa248eb820ff6",
|
||||
"created_at": 1682790000
|
||||
}
|
||||
```
|
||||
|
||||
### Kind 1 events
|
||||
|
||||
In kind 1 events, the `content` should be emojified.
|
||||
|
||||
```json
|
||||
{
|
||||
"kind": 1,
|
||||
"content": "Hello :gleasonator: 😂 :ablobcatrainbow: :disputed: yolo",
|
||||
"tags": [
|
||||
["emoji", "ablobcatrainbow", "https://gleasonator.com/emoji/blobcat/ablobcatrainbow.png"],
|
||||
["emoji", "disputed", "https://gleasonator.com/emoji/Fun/disputed.png"],
|
||||
["emoji", "gleasonator", "https://gleasonator.com/emoji/Gleasonator/gleasonator.png"]
|
||||
],
|
||||
"pubkey": "79c2cae114ea28a981e7559b4fe7854a473521a8d22a66bbab9fa248eb820ff6",
|
||||
"created_at": 1682630000
|
||||
}
|
||||
```
|
||||
15
31.md
15
31.md
@@ -1,15 +0,0 @@
|
||||
NIP-31
|
||||
======
|
||||
|
||||
Dealing with unknown event kinds
|
||||
--------------------------------
|
||||
|
||||
`draft` `optional` `author:pablof7z` `author:fiatjaf`
|
||||
|
||||
When creating a new custom event kind that is part of a custom protocol and isn't meant to be read as text (like `kind:1`), clients should use an `alt` tag to write a short human-readable plaintext summary of what that event is about.
|
||||
|
||||
The intent is that social clients, used to display only `kind:1` notes, can still show something in case a custom event pops up in their timelines. The content of the `alt` tag should provide enough context for a user that doesn't know anything about this event kind to understand what it is.
|
||||
|
||||
These clients that only know `kind:1` are not expected to ask relays for events of different kinds, but users could still reference these weird events on their notes, and without proper context these could be nonsensical notes. Having the fallback text makes that situation much better -- even if only for making the user aware that they should try to view that custom event elsewhere.
|
||||
|
||||
`kind:1`-centric clients can make interacting with these event kinds more functional by supporting [NIP-89](https://github.com/nostr-protocol/nips/blob/master/89.md).
|
||||
126
32.md
126
32.md
@@ -1,126 +0,0 @@
|
||||
NIP-32
|
||||
======
|
||||
|
||||
Labeling
|
||||
---------
|
||||
|
||||
`draft` `optional` `author:staab` `author:gruruya` `author:s3x-jay`
|
||||
|
||||
A label is a `kind 1985` event that is used to label other entities. This supports a number of use cases, from distributed moderation and content recommendations to reviews and ratings.
|
||||
|
||||
Label Target
|
||||
----
|
||||
|
||||
The label event MUST include one or more tags representing the object or objects being
|
||||
labeled: `e`, `p`, `a`, `r`, or `t` tags. This allows for labeling of events, people, relays,
|
||||
or topics respectively. As with NIP-01, a relay hint SHOULD be included when using `e` and
|
||||
`p` tags.
|
||||
|
||||
Label Tag
|
||||
----
|
||||
|
||||
This NIP introduces a new tag `l` which denotes a label, and a new `L` tag which denotes a label namespace.
|
||||
A label MUST include a mark matching an `L` tag. `L` tags refer to a tag type within nostr, or a nomenclature
|
||||
external to nostr defined either formally or by convention. Any string can be a namespace, but publishers SHOULD
|
||||
ensure they are unambiguous by using a well-defined namespace (such as an ISO standard) or reverse domain name notation.
|
||||
|
||||
Namespaces starting with `#` indicate that the label target should be associated with the label's value.
|
||||
This is a way of attaching standard nostr tags to events, pubkeys, relays, urls, etc.
|
||||
|
||||
Some examples:
|
||||
|
||||
- `["l", "footstr", "#t"]` - the publisher thinks the given entity should have the `footstr` topic applied.
|
||||
- `["l", "<pubkey>", "#p"]` - the publisher thinks the given entity is related to `<pubkey>`
|
||||
- `["l", "IT-MI", "ISO-3166-2"]` - Milano, Italy using ISO 3166-2.
|
||||
- `["l", "VI-hum", "com.example.ontology"]` - Violence toward a human being as defined by ontology.example.com.
|
||||
|
||||
`L` tags containing the label namespaces MUST be included in order to support searching by
|
||||
namespace rather than by a specific tag. The special `ugc` ("user generated content") namespace
|
||||
MAY be used when the label content is provided by an end user.
|
||||
|
||||
`l` and `L` tags MAY be added to other event kinds to support self-reporting. For events
|
||||
with a kind other than 1985, labels refer to the event itself.
|
||||
|
||||
Label Annotations
|
||||
-----
|
||||
|
||||
A label tag MAY include a 4th positional element detailing extra metadata about the label in question. This string
|
||||
should be a json-encoded object. Any key MAY be used, but the following are recommended:
|
||||
|
||||
- `quality` may have a value of 0 to 1. This allows for an absolute, granular scale that can be represented in any way (5 stars, color scale, etc).
|
||||
- `confidence` may have a value of 0 to 1. This indicates the certainty which the author has about their rating.
|
||||
- `context` may be an array of urls (including NIP-21 urls) indicating other context that should be considered when interpreting labels.
|
||||
|
||||
Content
|
||||
-------
|
||||
|
||||
Labels should be short, meaningful strings. Longer discussions, such as for a review, or an
|
||||
explanation of why something was labeled the way it was, should go in the event's `content` field.
|
||||
|
||||
Example events
|
||||
--------------
|
||||
|
||||
A suggestion that multiple pubkeys be associated with the `permies` topic.
|
||||
|
||||
```json
|
||||
{
|
||||
"kind": 1985,
|
||||
"tags": [
|
||||
["L", "#t"],
|
||||
["l", "permies", "#t"],
|
||||
["p", <pubkey1>, <relay_url>],
|
||||
["p", <pubkey2>, <relay_url>]
|
||||
],
|
||||
"content": "",
|
||||
...
|
||||
}
|
||||
```
|
||||
|
||||
A review of a relay.
|
||||
|
||||
```json
|
||||
{
|
||||
"kind": 1985,
|
||||
"tags": [
|
||||
["L", "com.example.ontology"],
|
||||
["l", "relay/review", "com.example.ontology", "{\"quality\": 0.1}"],
|
||||
["r", <relay_url>]
|
||||
],
|
||||
"content": "This relay is full of mean people.",
|
||||
...
|
||||
}
|
||||
```
|
||||
|
||||
Publishers can self-label by adding `l` tags to their own non-1985 events.
|
||||
|
||||
```json
|
||||
{
|
||||
"kind": 1,
|
||||
"tags": [
|
||||
["L", "com.example.ontology"],
|
||||
["l", "IL-frd", "com.example.ontology"]
|
||||
],
|
||||
"content": "Send me 100 sats and I'll send you 200 back",
|
||||
...
|
||||
}
|
||||
```
|
||||
|
||||
Other Notes
|
||||
-----------
|
||||
|
||||
When using this NIP to bulk-label many targets at once, events may be deleted and a replacement
|
||||
may be published. We have opted not to use parameterizable/replaceable events for this due to the
|
||||
complexity in coming up with a standard `d` tag. In order to avoid ambiguity when querying,
|
||||
publishers SHOULD limit labeling events to a single namespace.
|
||||
|
||||
Before creating a vocabulary, explore how your use case may have already been designed and
|
||||
imitate that design if possible. Reverse domain name notation is encouraged to avoid
|
||||
namespace clashes, but for the sake of interoperability all namespaces should be
|
||||
considered open for public use, and not proprietary. In other words, if there is a
|
||||
namespace that fits your use case, use it even if it points to someone else's domain name.
|
||||
|
||||
Vocabularies MAY choose to fully qualify all labels within a namespace (for example,
|
||||
`["l", "com.example.vocabulary:my-label"]`. This may be preferred when defining more
|
||||
formal vocabularies that should not be confused with another namespace when querying
|
||||
without an `L` tag. For these vocabularies, all labels SHOULD include the namespace
|
||||
(rather than mixing qualified and unqualified labels).
|
||||
4
33.md
4
33.md
@@ -10,7 +10,7 @@ This NIP adds a new event range that allows for replacement of events that have
|
||||
|
||||
Implementation
|
||||
--------------
|
||||
The value of a tag can be any string and is defined as the first parameter of a tag after the tag name.
|
||||
The value of a tag is defined as the first parameter of a tag after the tag name.
|
||||
|
||||
A *parameterized replaceable event* is defined as an event with a kind `30000 <= n < 40000`.
|
||||
Upon a parameterized replaceable event with a newer timestamp than the currently known latest
|
||||
@@ -18,8 +18,6 @@ replaceable event with the same kind, author and first `d` tag value being recei
|
||||
SHOULD be discarded, effectively replacing what gets returned when querying for
|
||||
`author:kind:d-tag` tuples.
|
||||
|
||||
If two events have the same timestamp, the event with the lowest id (first in lexical order) SHOULD be retained, and the other discarded.
|
||||
|
||||
A missing or a `d` tag with no value should be interpreted equivalent to a `d` tag with the
|
||||
value as an empty string. Events from the same author with any of the following `tags`
|
||||
replace each other:
|
||||
|
||||
7
36.md
7
36.md
@@ -9,9 +9,6 @@ Sensitive Content / Content Warning
|
||||
The `content-warning` tag enables users to specify if the event's content needs to be approved by readers to be shown.
|
||||
Clients can hide the content until the user acts on it.
|
||||
|
||||
`l` and `L` tags MAY be also be used as defined in [NIP-32](32.md) with the `content-warning` or other namespace to support
|
||||
further qualification and querying.
|
||||
|
||||
#### Spec
|
||||
|
||||
```
|
||||
@@ -29,10 +26,6 @@ options:
|
||||
"kind": 1,
|
||||
"tags": [
|
||||
["t", "hastag"],
|
||||
["L", "content-warning"],
|
||||
["l", "reason", "content-warning"],
|
||||
["L", "social.nos.ontology"],
|
||||
["l", "NS-nud", "social.nos.ontology"],
|
||||
["content-warning", "reason"] /* reason is optional */
|
||||
],
|
||||
"content": "sensitive content with #hastag\n",
|
||||
|
||||
95
37.md
95
37.md
@@ -1,95 +0,0 @@
|
||||
NIP-37
|
||||
======
|
||||
|
||||
Methods for dealing with lost or compromised keys
|
||||
-------------------------------------------------
|
||||
|
||||
`draft` `optional` `author:fiatjaf`
|
||||
|
||||
This NIP defines a series of methods that can be used to make catastrophic key loss events less horrible.
|
||||
|
||||
The intention here is not to claim that there is a generalized "key rotation" scheme on Nostr, but still make it
|
||||
so that in most cases people are able to move to new keys and not lost 100% of their followers and reputation
|
||||
when that happens, and also that it is possible to prevent most of the reputational damage that could be
|
||||
caused by having an evil hacker take control of someone else's keys.
|
||||
|
||||
The implementation of this NIP could be done directly in social clients or in dedicated clients that users would
|
||||
visit from time to time in order to have an automated scan be done on their contacts and then the dedicated app
|
||||
could suggest migrating from old keys to new keys, or suggest stop following compromised keys, or even perform
|
||||
these migrations automatically.
|
||||
|
||||
### Method A: Simple Key Deletion
|
||||
|
||||
Based on https://github.com/nostr-protocol/nips/pull/377, the idea is that someone, after noticing that their key
|
||||
has been compromised and deciding that it is not possible to use any of the other methods here described, can
|
||||
proceed to publish the following event:
|
||||
|
||||
```js
|
||||
{
|
||||
"kind": 10529,
|
||||
"pubkey": "<compromised-pubkey>",
|
||||
"tags": [
|
||||
["reason", "I typed my key on anigma"]
|
||||
|
||||
// this is unnecessary, but it's an extra requirement to prevent people from making a 10529 event by chance
|
||||
["key-compromised"],
|
||||
],
|
||||
"content": "",
|
||||
// ...
|
||||
}
|
||||
```
|
||||
|
||||
Upon receiving this, relays implementing this NIP SHOULD somehow mark it as invalid and refuse to store any more
|
||||
events from this key. Relays MAY also decide to also delete all events from this key.
|
||||
|
||||
Upon receiving this, clients implementing this NIP SHOULD stop following the key.
|
||||
|
||||
Clients may give users the option to "delete your public key" with this type of event. Clients SHOULD display a
|
||||
prominent message explaining that the action is not reversible, SHOULD explain that this does not guarantee their
|
||||
posts are deleted forever, and SHOULD require special confirmation such as requiring the user to type a message.
|
||||
|
||||
### Method B: Social Key Migration
|
||||
|
||||
The idea here is that users could pick some friends from their contact list and a threshold number to signal to
|
||||
the rest that the old key has been lost and what is the new key -- e.g. Alice can determine that, from Bob, Carol
|
||||
and Derek, if any 2 of these 3 agree, their recommendation is authoritative.
|
||||
|
||||
This is done by publishing an event like this (for example):
|
||||
|
||||
```js
|
||||
{
|
||||
"kind": 10520,
|
||||
"pubkey": "<user-pubkey-that-will-be-compromised>",
|
||||
"tags": [
|
||||
["p", "<friend1-pubkey>"],
|
||||
["p", "<friend2-pubkey>"],
|
||||
["p", "<friend3-pubkey>"],
|
||||
["threshold", "2"]
|
||||
],
|
||||
"content": "",
|
||||
// ...
|
||||
}
|
||||
```
|
||||
|
||||
And then, when the friends want to recommend the switch to a new pubkey, they can publish events like
|
||||
|
||||
```js
|
||||
{
|
||||
"kind": 1521,
|
||||
"pubkey": "<friend1-pubkey>",
|
||||
"tags": [
|
||||
["p", "<compromised-pubkey>"],
|
||||
["e", "<event-of-kind-10520-that-this-refers-to>"],
|
||||
["new-key", "<new-key>"]
|
||||
],
|
||||
"content": "",
|
||||
// ...
|
||||
}
|
||||
```
|
||||
|
||||
Very importantly, when evaluating events of kind `1521` for a given `p`, clients should ensure that their corresponding
|
||||
event `10520` is at least 3 months older **and that an OpenTimestamps proof exists for that**.
|
||||
|
||||
### Method C: Hierarchically Pregenerated Keys
|
||||
|
||||
I'll write this later, just a placeholder. It's probably better to see if methods A and B work first.
|
||||
8
45.md
8
45.md
@@ -14,13 +14,13 @@ Some queries a client may want to execute against connected relays are prohibiti
|
||||
|
||||
## Filters and return values
|
||||
|
||||
This NIP defines the verb `COUNT`, which accepts a subscription id and filters as specified in [NIP 01](01.md) for the verb `REQ`. Multiple filters are OR'd together and aggregated into a single count result.
|
||||
This NIP defines the verb `COUNT`, which accepts a subscription id and filters as specified in [NIP 01](01.md) for the verb `REQ`.
|
||||
|
||||
```
|
||||
["COUNT", <subscription_id>, <filters JSON>...]
|
||||
```
|
||||
|
||||
Counts are returned using a `COUNT` response in the form `{"count": <integer>}`. Relays may use probabilistic counts to reduce compute requirements.
|
||||
Counts are returned using a `COUNT` response with positional "count" objects in the form `{"count": <integer>}`. Relays may use probabilistic counts to reduce compute requirements.
|
||||
|
||||
```
|
||||
["COUNT", <subscription_id>, {"count": <integer>}]
|
||||
@@ -36,4 +36,8 @@ Examples:
|
||||
# Count posts and reactions
|
||||
["COUNT", <subscription_id>, {"kinds": [1, 7], "authors": [<pubkey>]}]
|
||||
["COUNT", <subscription_id>, {"count": 5}]
|
||||
|
||||
# Both of the above in one `COUNT`
|
||||
["COUNT", <subscription_id>, {"kinds": [3], "#p": [<pubkey>]}, {"kinds": [1, 7], "authors": [<pubkey>]}]
|
||||
["COUNT", <subscription_id>, {"count": 238}, {"count": 5}]
|
||||
```
|
||||
|
||||
26
47.md
26
47.md
@@ -12,18 +12,8 @@ This NIP describes a way for clients to access a remote Lightning wallet through
|
||||
|
||||
## Terms
|
||||
|
||||
* **client**: Nostr app on any platform that wants to pay Lightning invoices.
|
||||
* **user**: The person using the **client**, and want's to connect their wallet app to their **client**.
|
||||
* **wallet service**: Nostr app that typically runs on an always-on computer (eg. in the cloud or on a Raspberry Pi). This app has access to the APIs of the wallets it serves.
|
||||
|
||||
## Theory of Operation
|
||||
1. **Users** who which to use this NIP to send lightning payments to other nostr users must first acquire a special "connection" URI from their NIP-47 compliant wallet application. The wallet application may provide this URI using a QR screen, or a pasteable string, or some other means.
|
||||
|
||||
2. The **user** should then copy this URI into their **client(s)** by pasting, or scanning the QR, etc. The **client(s)** should save this URI and use it later whenever the **user** makes a payment. The **client** should then request an `info` (13194) event from the relay(s) specified in the URI. The **wallet service** will have sent that event to those relays earlier, and the relays will hold it as a replaceable event.
|
||||
|
||||
3. When the **user** initiates a payment their nostr **client** create a `pay_invoice` request, encrypts it using a token from the URI, and sends it (kind 23194) to the relay(s) specified in the connection URI. The **wallet service** will be listening on those relays and will decrypt the request and then contact the **user's** wallet application to send the payment. The **wallet service** will know how to talk to the wallet application because the connection URI specified relay(s) that have access to the wallet app API.
|
||||
|
||||
4. Once the payment is complete the **wallet service** will send an encrypted `response` (kind 23195) to the **user** over the relay(s) in the URI.
|
||||
* **client**: Nostr app on any platform that wants to pay Lightning invoices
|
||||
* **wallet service**: Nostr app that typically runs on an always-on computer (eg. in the cloud or on a Raspberry Pi).
|
||||
|
||||
## Events
|
||||
|
||||
@@ -33,9 +23,8 @@ There are three event kinds:
|
||||
- `NIP-47 response`: 23195
|
||||
|
||||
The info event should be a replaceable event that is published by the **wallet service** on the relay to indicate which commands it supports. The content should be
|
||||
a plaintext string with the supported commands, space-separated, eg. `pay_invoice get_balance`. Only the `pay_invoice` command is described in this NIP, but other commands might be defined in different NIPs.
|
||||
|
||||
Both the request and response events SHOULD contain one `p` tag, containing the public key of the **wallet service** if this is a request, and the public key of the **user** if this is a response. The response event SHOULD contain an `e` tag with the id of the request event it is responding to.
|
||||
a plaintext string with the supported commands, space-seperated, eg. `pay_invoice get_balance`. Only the `pay_invoice` command is described in this NIP, but other commands might be defined in different NIPs.
|
||||
Both the request and response events SHOULD contain one `p` tag, containing the public key of the **wallet service** if this is a request, and the public key of the **client** if this is a response. The response event SHOULD contain an `e` tag with the id of the request event it is responding to.
|
||||
|
||||
The content of requests and responses is encrypted with [NIP04](https://github.com/nostr-protocol/nips/blob/master/04.md), and is a JSON-RPCish object with a semi-fixed structure:
|
||||
|
||||
@@ -64,8 +53,8 @@ Response:
|
||||
```
|
||||
|
||||
The `result_type` field MUST contain the name of the method that this event is responding to.
|
||||
The `error` field MUST contain a `message` field with a human readable error message and a `code` field with the error code if the command was not successful.
|
||||
If the command was successful, the `error` field must be null.
|
||||
The `error` field MUST contain a `message` field with a human readable error message and a `code` field with the error code if the command was not succesful.
|
||||
If the command was succesful, the `error` field must be null.
|
||||
|
||||
### Error codes
|
||||
- `RATE_LIMITED`: The client is sending commands too fast. It should retry in a few seconds.
|
||||
@@ -88,7 +77,6 @@ The **wallet service** generates this connection URI with protocol `nostr+wallet
|
||||
- The user can have different keys for different applications. Keys can be revoked and created at will and have arbitrary constraints (eg. budgets).
|
||||
- The key is harder to leak since it is not shown to the user and backed up.
|
||||
- It improves privacy because the user's main key would not be linked to their payments.
|
||||
- `lud16` Recommended. A lightning address that clients can use to automatically setup the `lud16` field on the user's profile if they have none configured.
|
||||
|
||||
The **client** should then store this connection and use it when the user wants to perform actions like paying an invoice. Due to this NIP using ephemeral events, it is recommended to pick relays that do not close connections on inactivity to not drop events.
|
||||
|
||||
@@ -129,7 +117,7 @@ Errors:
|
||||
## Example pay invoice flow
|
||||
|
||||
0. The user scans the QR code generated by the **wallet service** with their **client** application, they follow a `nostr+walletconnect:` deeplink or configure the connection details manually.
|
||||
1. **client** sends an event to the **wallet service** service with kind `23194`. The content is a `pay_invoice` request. The private key is the secret from the connection string above.
|
||||
1. **client** sends an event to with **wallet service** service with kind `23194`. The content is a `pay_invoice` request. The private key is the secret from the connection string above.
|
||||
2. **wallet service** verifies that the author's key is authorized to perform the payment, decrypts the payload and sends the payment.
|
||||
3. **wallet service** responds to the event by sending an event with kind `23195` and content being a response either containing an error message or a preimage.
|
||||
|
||||
|
||||
15
56.md
15
56.md
@@ -32,9 +32,6 @@ being reported, which consists of the following report types:
|
||||
|
||||
Some report tags only make sense for profile reports, such as `impersonation`
|
||||
|
||||
`l` and `L` tags MAY be also be used as defined in [NIP-32](32.md) to support
|
||||
further qualification and querying.
|
||||
|
||||
Example events
|
||||
--------------
|
||||
|
||||
@@ -42,9 +39,7 @@ Example events
|
||||
{
|
||||
"kind": 1984,
|
||||
"tags": [
|
||||
["p", <pubkey>, "nudity"]
|
||||
["L", "social.nos.ontology"],
|
||||
["l", "NS-nud", "social.nos.ontology"],
|
||||
[ "p", <pubkey>, "nudity"]
|
||||
],
|
||||
"content": "",
|
||||
...
|
||||
@@ -53,8 +48,8 @@ Example events
|
||||
{
|
||||
"kind": 1984,
|
||||
"tags": [
|
||||
["e", <eventId>, "illegal"],
|
||||
["p", <pubkey>]
|
||||
[ "e", <eventId>, "illegal"],
|
||||
[ "p", <pubkey>]
|
||||
],
|
||||
"content": "He's insulting the king!",
|
||||
...
|
||||
@@ -63,8 +58,8 @@ Example events
|
||||
{
|
||||
"kind": 1984,
|
||||
"tags": [
|
||||
["p", <impersonator pubkey>, "impersonation"],
|
||||
["p", <victim pubkey>]
|
||||
[ "p", <impersonator pubkey>, "impersonation"],
|
||||
[ "p", <victim pubkey>]
|
||||
],
|
||||
"content": "Profile is imitating #[1]",
|
||||
...
|
||||
|
||||
44
57.md
44
57.md
@@ -6,21 +6,21 @@ Lightning Zaps
|
||||
|
||||
`draft` `optional` `author:jb55` `author:kieran`
|
||||
|
||||
This NIP defines two new event types for recording lightning payments between users. `9734` is a `zap request`, representing a payer's request to a recipient's lightning wallet for an invoice. `9735` is a `zap receipt`, representing the confirmation by the recipient's lightning wallet that the invoice issued in response to a `zap request` has been paid.
|
||||
This NIP defines two new event types for recording lightning payments between users. `9734` is a `zap request`, representing a payer's request to a recipient's lightning wallet for an invoice. `9735` is a `zap receipt`, representing the confirmation by the recipient's lightning wallet that the invoice issued in response to a zap request has been paid.
|
||||
|
||||
Having lightning receipts on nostr allows clients to display lightning payments from entities on the network. These can be used for fun or for spam deterrence.
|
||||
|
||||
## Protocol flow
|
||||
|
||||
1. Client calculates a recipient's lnurl pay request url from the `zap` tag on the event being zapped (see Appendix G), or by decoding their lud06 or lud16 field on their profile according to the [lnurl specifications](https://github.com/lnurl/luds). The client MUST send a GET request to this url and parse the response. If `allowsNostr` exists and it is `true`, and if `nostrPubkey` exists and is a valid BIP 340 public key in hex, the client should associate this information with the user, along with the response's `callback`, `minSendable`, and `maxSendable` values.
|
||||
2. Clients may choose to display a lightning zap button on each post or on a user's profile. If the user's lnurl pay request endpoint supports nostr, the client SHOULD use this NIP to request a `zap receipt` rather than a normal lnurl invoice.
|
||||
2. Clients may choose to display a lightning zap button on each post or on a user's profile. If the user's lnurl pay request endpoint supports nostr, the client SHOULD use this NIP to request a zap receipt rather than a normal lnurl invoice.
|
||||
3. When a user (the "sender") indicates they want to send a zap to another user (the "recipient"), the client should create a `zap request` event as described in Appendix A of this NIP and sign it.
|
||||
4. Instead of publishing the `zap request`, the `9734` event should instead be sent to the `callback` url received from the lnurl pay endpoint for the recipient using a GET request. See Appendix B for details and an example.
|
||||
5. The recipient's lnurl server will receive this `zap request` and validate it. See Appendix C for details on how to properly configure an lnurl server to support zaps, and Appendix D for details on how to validate the `nostr` query parameter.
|
||||
6. If the `zap request` is valid, the server should fetch a description hash invoice where the description is this `zap request` note and this note only. No additional lnurl metadata is included in the description. This will be returned in the response according to [LUD06](https://github.com/lnurl/luds/blob/luds/06.md).
|
||||
5. The recipient's lnurl server will receive this request and validate it. See Appendix C for details on how to properly configure an lnurl server to support zaps, and Appendix D for details on how to validate the `nostr` query parameter.
|
||||
6. If the request is valid, the server should fetch a description hash invoice where the description is this note and this note only. No additional lnurl metadata is included in the description. This will be returned in the response according to [LUD06](https://github.com/lnurl/luds/blob/luds/06.md).
|
||||
7. On receiving the invoice, the client MAY pay it or pass it to an app that can pay the invoice.
|
||||
8. Once the invoice is paid, the recipient's lnurl server MUST generate a `zap receipt` as described in Appendix E, and publish it to the `relays` specified in the `zap request`.
|
||||
9. Clients MAY fetch `zap receipt`s on posts and profiles, but MUST authorize their validity as described in Appendix F. If the `zap request` note contains a non-empty `content`, it may display a zap comment. Generally clients should show users the `zap request` note, and use the `zap receipt` to show "zap authorized by ..." but this is optional.
|
||||
9. Clients MAY fetch zap notes on posts and profiles, but MUST authorize their validity as described in Appendix F. If the zap request note contains a non-empty `content`, it may display a zap comment. Generally clients should show users the `zap request` note, and use the `zap note` to show "zap authorized by ..." but this is optional.
|
||||
|
||||
## Reference and examples
|
||||
|
||||
@@ -60,10 +60,10 @@ Example:
|
||||
|
||||
### Appendix B: Zap Request HTTP Request
|
||||
|
||||
A signed `zap request` event is not published, but is instead sent using a HTTP GET request to the recipient's `callback` url, which was provided by the recipient's lnurl pay endpoint. This request should have the following query parameters defined:
|
||||
A signed zap request event is not published, but is instead sent using a HTTP GET request to the recipient's `callback` url, which was provided by the recipient's lnurl pay endpoint. This request should have the following query parameters defined:
|
||||
|
||||
- `amount` is the amount in _millisats_ the sender intends to pay
|
||||
- `nostr` is the `9734` `zap request` event, JSON encoded then URI encoded
|
||||
- `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:
|
||||
@@ -97,18 +97,18 @@ const {pr: invoice} = await fetchJson(`${callback}?amount=${amount}&nostr=${even
|
||||
|
||||
The lnurl server will need some additional pieces of information so that clients can know that zap invoices are supported:
|
||||
|
||||
1. Add a `nostrPubkey` to the lnurl-pay static endpoint `/.well-known/lnurlp/<user>`, where `nostrPubkey` is the nostr pubkey your server will use to sign `zap receipt` events. Clients will use this to validate `zap receipt`s.
|
||||
1. Add a `nostrPubkey` to the lnurl-pay static endpoint `/.well-known/lnurlp/<user>`, where `nostrPubkey` is the nostr pubkey your server will use to sign `zap receipt` events. Clients will use this to validate zap receipts.
|
||||
2. Add an `allowsNostr` field and set it to true.
|
||||
|
||||
### Appendix D: LNURL Server Zap Request Validation
|
||||
|
||||
When a client sends a `zap request` event to a server's lnurl-pay callback URL, there will be a `nostr` query parameter whose value is that event which is URI- and JSON-encoded. If present, the `zap request` event must be validated in the following ways:
|
||||
When a client sends a zap request event to a server's lnurl-pay callback URL, there will be a `nostr` query parameter where the contents of the event are URI- and JSON-encoded. If present, the zap request event must be validated in the following ways:
|
||||
|
||||
1. It MUST have a valid nostr signature
|
||||
2. It MUST have tags
|
||||
3. It MUST have only one `p` tag
|
||||
4. It MUST have 0 or 1 `e` tags
|
||||
5. There should be a `relays` tag with the relays to send the `zap receipt` to.
|
||||
5. There should be a `relays` tag with the relays to send the `zap` note to.
|
||||
6. If there is an `amount` tag, it MUST be equal to the `amount` query parameter.
|
||||
7. If there is an `a` tag, it MUST be a valid NIP-33 event coordinate
|
||||
|
||||
@@ -116,29 +116,29 @@ The event MUST then be stored for use later, when the invoice is paid.
|
||||
|
||||
### Appendix E: Zap Receipt Event
|
||||
|
||||
A `zap receipt` is created by a lightning node when an invoice generated by a `zap request` is paid. `Zap receipt`s are only created when the invoice description (committed to the description hash) contains a `zap request` note.
|
||||
A `zap receipt` is created by a lightning node when an invoice generated by a `zap request` is paid. Zap receipts are only created when the invoice description (committed to the description hash) contains a zap request note.
|
||||
|
||||
When receiving a payment, the following steps are executed:
|
||||
|
||||
1. Get the description for the invoice. This needs to be saved somewhere during the generation of the description hash invoice. It is saved automatically for you with CLN, which is the reference implementation used here.
|
||||
2. Parse the bolt11 description as a JSON nostr event. This SHOULD be validated based on the requirements in Appendix D, either when it is received, or before the invoice is paid.
|
||||
3. Create a nostr event of kind `9735` as described below, and publish it to the `relays` declared in the `zap request`.
|
||||
3. Create a nostr event of kind `9735` as described below, and publish it to the `relays` declared in the zap request.
|
||||
|
||||
The following should be true of the `zap receipt` event:
|
||||
The following should be true of the zap receipt event:
|
||||
|
||||
- The content SHOULD be empty.
|
||||
- The `created_at` date SHOULD be set to the invoice `paid_at` date for idempotency.
|
||||
- `tags` MUST include the `p` tag AND optional `e` tag from the `zap request`.
|
||||
- The `zap receipt` MUST have a `bolt11` tag containing the description hash bolt11 invoice.
|
||||
- The `zap receipt` MUST contain a `description` tag which is the JSON-encoded invoice description.
|
||||
- `tags` MUST include the `p` tag AND optional `e` tag from the zap request.
|
||||
- The zap receipt MUST have a `bolt11` tag containing the description hash bolt11 invoice.
|
||||
- The zap receipt MUST contain a `description` tag which is the JSON-encoded invoice description.
|
||||
- `SHA256(description)` MUST match the description hash in the bolt11 invoice.
|
||||
- The `zap receipt` MAY contain a `preimage` tag to match against the payment hash of the bolt11 invoice. This isn't really a payment proof, there is no real way to prove that the invoice is real or has been paid. You are trusting the author of the `zap receipt` for the legitimacy of the payment.
|
||||
- The zap receipt MAY contain a `preimage` tag to match against the payment hash of the bolt11 invoice. This isn't really a payment proof, there is no real way to prove that the invoice is real or has been paid. You are trusting the author of the zap receipt for the legitimacy of the payment.
|
||||
|
||||
The `zap receipt` is not a proof of payment, all it proves is that some nostr user fetched an invoice. The existence of the `zap receipt` implies the invoice as paid, but it could be a lie given a rogue implementation.
|
||||
The zap receipt is not a proof of payment, all it proves is that some nostr user fetched an invoice. The existence of the zap receipt implies the invoice as paid, but it could be a lie given a rogue implementation.
|
||||
|
||||
A reference implementation for a zap-enabled lnurl server can be found [here](https://github.com/jb55/cln-nostr-zapper).
|
||||
|
||||
Example `zap receipt`:
|
||||
Example zap receipt:
|
||||
|
||||
```json
|
||||
{
|
||||
@@ -160,7 +160,7 @@ Example `zap receipt`:
|
||||
|
||||
### Appendix F: Validating Zap Receipts
|
||||
|
||||
A client can retrieve `zap receipt`s on events and pubkeys using a NIP-01 filter, for example `{"kinds": [9735], "#e": [...]}`. Zaps MUST be validated using the following steps:
|
||||
A client can retrieve `zap receipts` on events and pubkeys using a NIP-01 filter, for example `{"kinds": [9735], "#e": [...]}`. Zaps MUST be validated using the following steps:
|
||||
|
||||
- The `zap receipt` event's `pubkey` MUST be the same as the recipient's lnurl provider's `nostrPubkey` (retrieved in step 1 of the protocol flow).
|
||||
- The `invoiceAmount` contained in the `bolt11` tag of the `zap receipt` MUST equal the `amount` tag of the `zap request` (if present).
|
||||
@@ -168,7 +168,7 @@ A client can retrieve `zap receipt`s on events and pubkeys using a NIP-01 filter
|
||||
|
||||
### Appendix G: `zap` tag on zapped event
|
||||
|
||||
When an event includes a `zap` tag, clients SHOULD calculate the lnurl pay request based on its value instead of the profile's field. An optional third argument on the tag specifies the type of value, either `lud06` or `lud16`.
|
||||
When an event includes a `zap` tag, clients SHOULD calculate the lnurl pay request based on it's value instead of the profile's field. An optional third argument on the tag specifies the type of value, either `lud06` or `lud16`.
|
||||
|
||||
```json
|
||||
{
|
||||
@@ -180,4 +180,4 @@ When an event includes a `zap` tag, clients SHOULD calculate the lnurl pay reque
|
||||
|
||||
## Future Work
|
||||
|
||||
Zaps can be extended to be more private by encrypting `zap request` notes to the target user, but for simplicity it has been left out of this initial draft.
|
||||
Zaps can be extended to be more private by encrypting zap request notes to the target user, but for simplicity it has been left out of this initial draft.
|
||||
|
||||
116
89.md
116
89.md
@@ -1,116 +0,0 @@
|
||||
NIP-89
|
||||
======
|
||||
|
||||
Recommended Application Handlers
|
||||
--------------------------------
|
||||
|
||||
`draft` `optional` `author:pablof7z`
|
||||
|
||||
This NIP describes `kind:31989` and `kind:31990`: a way to discover applications that can handle unknown event-kinds.
|
||||
|
||||
## Rationale
|
||||
Nostr's discoverability and transparent event interaction is one of its most interesting/novel mechanics.
|
||||
This NIP provides a simple way for clients to discover applications that handle events of a specific kind to ensure smooth cross-client and cross-kind interactions.
|
||||
|
||||
### Parties involved
|
||||
There are three actors to this workflow:
|
||||
|
||||
* application that handles a specific event kind (note that an application doesn't necessarily need to be a distinct entity and it could just be the same pubkey as user A)
|
||||
* Publishes `kind:31990`, detailing how apps should redirect to it
|
||||
* user A, who recommends an app that handles a specific event kind
|
||||
* Publishes `kind:31989`
|
||||
* user B, who seeks a recommendation for an app that handles a specific event kind
|
||||
* Queries for `kind:31989` and, based on results, queries for `kind:31990`
|
||||
|
||||
# Events
|
||||
|
||||
## Recommendation event
|
||||
```json
|
||||
{
|
||||
"kind": 31989,
|
||||
"pubkey": <recommender-user-pubkey>,
|
||||
"tags": [
|
||||
[ "d", <supported-event-kind> ],
|
||||
[ "a", "31990:app1-pubkey:<d-identifier>", "wss://relay1", "ios" ],
|
||||
[ "a", "31990:app2-pubkey:<d-identifier>", "wss://relay2", "web" ]
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
The `d` tag in `kind:31989` is the supported event kind this event is recommending.
|
||||
|
||||
Multiple `a` tags can appear on the same `kind:31989`.
|
||||
|
||||
The second value of the tag SHOULD be a relay hint.
|
||||
The third value of the tag SHOULD be the platform where this recommendation might apply.
|
||||
|
||||
## Handler information
|
||||
```json
|
||||
{
|
||||
"kind": 31990,
|
||||
"pubkey": <pubkey>,
|
||||
"content": "<optional-kind:0-style-metadata>",
|
||||
"tags": [
|
||||
[ "d", <random-id> ],
|
||||
[ "k", <supported-event-kind> ],
|
||||
[ "web", "https://..../a/<bech32>", "nevent" ],
|
||||
[ "web", "https://..../p/<bech32>", "nprofile" ],
|
||||
[ "web", "https://..../e/<bech32>" ],
|
||||
[ "ios", ".../<bech32>" ]
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
* `content` is an optional `set_metadata`-like stringified JSON object, as described in NIP-01. This content is useful when the pubkey creating the `kind:31990` is not an application. If `content` is empty, the `kind:0` of the pubkey should be used to display application information (e.g. name, picture, web, LUD16, etc.)
|
||||
|
||||
* `k` tags' value is the event kind that is supported by this `kind:31990`.
|
||||
Using a `k` tag(s) (instead of having the kind onf the NIP-33 `d` tag) provides:
|
||||
* Multiple `k` tags can exist in the same event if the application supports more than one event kind and their handler URLs are the same.
|
||||
* The same pubkey can have multiple events with different apps that handle the same event kind.
|
||||
|
||||
* `bech32` in a URL MUST be replaced by clients with the NIP-19-encoded entity that should be loaded by the application.
|
||||
|
||||
Multiple tags might be registered by the app, following NIP-19 nomenclature as the second value of the array.
|
||||
|
||||
A tag without a second value in the array SHOULD be considered a generic handler for any NIP-19 entity that is not handled by a different tag.
|
||||
|
||||
# User flow
|
||||
A user A who uses a non-`kind:1`-centric nostr app could choose to announce/recommend a certain kind-handler application.
|
||||
|
||||
When user B sees an unknown event kind, e.g. in a social-media centric nostr client, the client would allow user B to interact with the unknown-kind event (e.g. tapping on it).
|
||||
|
||||
The client MIGHT query for the user's and the user's follows handler.
|
||||
|
||||
# Example
|
||||
|
||||
## User A recommends a `kind:31337`-handler
|
||||
User A might be a user of Zapstr, a `kind:31337`-centric client (tracks). Using Zapstr, user A publishes an event recommending Zapstr as a `kind:31337`-handler.
|
||||
|
||||
```json
|
||||
{
|
||||
"kind": 31989,
|
||||
"tags": [
|
||||
[ "d", "31337" ],
|
||||
[ "a", "31990:1743058db7078661b94aaf4286429d97ee5257d14a86d6bfa54cb0482b876fb0:abcd", <relay-url>, "web" ]
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
## User B interacts with a `kind:31337`-handler
|
||||
User B might see in their timeline an event referring to a `kind:31337` event
|
||||
(e.g. a `kind:1` tagging a `kind:31337`).
|
||||
|
||||
User B's client, not knowing how to handle a `kind:31337` might display the event
|
||||
using its `alt` tag (as described in NIP-31). When the user clicks on the event,
|
||||
the application queries for a handler for this `kind`:
|
||||
|
||||
`["REQ", <id>, '[{ "kinds": [31989], "#d": ["31337"], 'authors': [<user>, <users-contact-list>] }]']`
|
||||
|
||||
User B, who follows User A, sees that `kind:31989` event and fetches the `a`-tagged event for the app and handler information.
|
||||
|
||||
User B's client sees the application's `kind:31990` which includes the information to redirect the user to the relevant URL with the desired entity replaced in the URL.
|
||||
|
||||
## Alternative query bypassing `kind:31989`
|
||||
Alternatively, users might choose to query directly for `kind:31990` for an event kind. Clients SHOULD be careful doing this and use spam-prevention mechanisms to avoid directing users to malicious handlers.
|
||||
|
||||
`["REQ", <id>, '[{ "kinds": [31990], "#k": [<desired-event-kind>], 'authors': [...] }]']`
|
||||
68
98.md
68
98.md
@@ -1,68 +0,0 @@
|
||||
NIP-98
|
||||
======
|
||||
|
||||
HTTP Auth
|
||||
-------------------------
|
||||
|
||||
`draft` `optional` `author:kieran` `author:melvincarvalho`
|
||||
|
||||
This NIP defines an ephemerial event used to authorize requests to HTTP servers using nostr events.
|
||||
|
||||
This is useful for HTTP services which are build for Nostr and deal with Nostr user accounts.
|
||||
|
||||
## Nostr event
|
||||
|
||||
A `kind 27235` (In reference to [RFC 7235](https://www.rfc-editor.org/rfc/rfc7235)) event is used.
|
||||
|
||||
The `content` SHOULD be empty.
|
||||
|
||||
The following tags are defined as REQUIRED.
|
||||
|
||||
* `u` - absolute URL
|
||||
* `method` - HTTP Request Method
|
||||
|
||||
Example event:
|
||||
```json
|
||||
{
|
||||
"id": "fe964e758903360f28d8424d092da8494ed207cba823110be3a57dfe4b578734",
|
||||
"pubkey": "63fe6318dc58583cfe16810f86dd09e18bfd76aabc24a0081ce2856f330504ed",
|
||||
"content": "",
|
||||
"kind": 27235,
|
||||
"created_at": 1682327852,
|
||||
"tags": [
|
||||
[
|
||||
"u",
|
||||
"https://api.snort.social/api/v1/n5sp/list"
|
||||
],
|
||||
[
|
||||
"method",
|
||||
"GET"
|
||||
]
|
||||
],
|
||||
"sig": "5ed9d8ec958bc854f997bdc24ac337d005af372324747efe4a00e24f4c30437ff4dd8308684bed467d9d6be3e5a517bb43b1732cc7d33949a3aaf86705c22184"
|
||||
}
|
||||
```
|
||||
|
||||
Servers MUST perform the following checks in order to validate the event:
|
||||
1. The `kind` MUST be `27235`.
|
||||
2. The `created_at` MUST be within a reasonable time window (suggestion 60 seconds).
|
||||
3. The `u` tag MUST be exactly the same as the absolute request URL (including query parameters).
|
||||
4. The `method` tag MUST be the same HTTP method used for the requested resource.
|
||||
|
||||
When the request contains a body (as in POST/PUT/PATCH methods) clients SHOULD include a SHA256 hash of the request body in a `payload` tag as hex (`["payload", "<sha256-hex>"]`), servers MAY check this to validate that the requested payload is authorized.
|
||||
|
||||
If one of the checks was to fail the server SHOULD respond with a 401 Unauthorized response code.
|
||||
|
||||
All other checks which server MAY do are OPTIONAL, and implementation specific.
|
||||
|
||||
## Request Flow
|
||||
|
||||
Using the `Authorization` header, the `kind 27235` event MUST be `base64` encoded and use the Authorization scheme `Nostr`
|
||||
|
||||
Example HTTP Authorization header:
|
||||
```
|
||||
Authorization: Nostr eyJpZCI6ImZlOTY0ZTc1ODkwMzM2MGYyOGQ4NDI0ZDA5MmRhODQ5NGVkMjA3Y2JhODIzMTEwYmUzYTU3ZGZlNGI1Nzg3MzQiLCJwdWJrZXkiOiI2M2ZlNjMxOGRjNTg1ODNjZmUxNjgxMGY4NmRkMDllMThiZmQ3NmFhYmMyNGEwMDgxY2UyODU2ZjMzMDUwNGVkIiwiY29udGVudCI6IiIsImtpbmQiOjI3MjM1LCJjcmVhdGVkX2F0IjoxNjgyMzI3ODUyLCJ0YWdzIjpbWyJ1cmwiLCJodHRwczovL2FwaS5zbm9ydC5zb2NpYWwvYXBpL3YxL241c3AvbGlzdCJdLFsibWV0aG9kIiwiR0VUIl1dLCJzaWciOiI1ZWQ5ZDhlYzk1OGJjODU0Zjk5N2JkYzI0YWMzMzdkMDA1YWYzNzIzMjQ3NDdlZmU0YTAwZTI0ZjRjMzA0MzdmZjRkZDgzMDg2ODRiZWQ0NjdkOWQ2YmUzZTVhNTE3YmI0M2IxNzMyY2M3ZDMzOTQ5YTNhYWY4NjcwNWMyMjE4NCJ9
|
||||
```
|
||||
|
||||
## Reference Implementations
|
||||
- C# ASP.NET `AuthenticationHandler` [NostrAuth.cs](https://gist.github.com/v0l/74346ae530896115bfe2504c8cd018d3)
|
||||
18
README.md
18
README.md
@@ -1,7 +1,7 @@
|
||||
# NIPs
|
||||
|
||||
NIPs stand for **Nostr Implementation Possibilities**.
|
||||
They exist to document what may be implemented by [Nostr](https://github.com/nostr-protocol/nostr)-compatible _relay_ and _client_ software.
|
||||
They exist to document what may be implemented by [Nostr](https://github.com/fiatjaf/nostr)-compatible _relay_ and _client_ software.
|
||||
|
||||
---
|
||||
|
||||
@@ -45,9 +45,6 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
|
||||
- [NIP-26: Delegated Event Signing](26.md)
|
||||
- [NIP-27: Text Note References](27.md)
|
||||
- [NIP-28: Public Chat](28.md)
|
||||
- [NIP-30: Custom Emoji](30.md)
|
||||
- [NIP-31: Dealing with Unknown Events](31.md)
|
||||
- [NIP-32: Labeling](32.md)
|
||||
- [NIP-33: Parameterized Replaceable Events](33.md)
|
||||
- [NIP-36: Sensitive Content](36.md)
|
||||
- [NIP-39: External Identities in Profiles](39.md)
|
||||
@@ -63,9 +60,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
|
||||
- [NIP-58: Badges](58.md)
|
||||
- [NIP-65: Relay List Metadata](65.md)
|
||||
- [NIP-78: Application-specific data](78.md)
|
||||
- [NIP-89: Recommended Application Handlers](89.md)
|
||||
- [NIP-94: File Metadata](94.md)
|
||||
- [NIP-98: HTTP Auth](98.md)
|
||||
|
||||
## Event Kinds
|
||||
|
||||
@@ -77,10 +72,9 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
|
||||
| `3` | Contacts | [2](02.md) |
|
||||
| `4` | Encrypted Direct Messages | [4](04.md) |
|
||||
| `5` | Event Deletion | [9](09.md) |
|
||||
| `6` | Repost | [18](18.md) |
|
||||
| `6` | Reposts | [18](18.md) |
|
||||
| `7` | Reaction | [25](25.md) |
|
||||
| `8` | Badge Award | [58](58.md) |
|
||||
| `16` | Generic Repost | [18](18.md) |
|
||||
| `40` | Channel Creation | [28](28.md) |
|
||||
| `41` | Channel Metadata | [28](28.md) |
|
||||
| `42` | Channel Message | [28](28.md) |
|
||||
@@ -88,7 +82,6 @@ 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) |
|
||||
| `1984` | Reporting | [56](56.md) |
|
||||
| `1985` | Label | [32](32.md) |
|
||||
| `9734` | Zap Request | [57](57.md) |
|
||||
| `9735` | Zap | [57](57.md) |
|
||||
| `10000` | Mute List | [51](51.md) |
|
||||
@@ -99,7 +92,6 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
|
||||
| `23194` | Wallet Request | [47](47.md) |
|
||||
| `23195` | Wallet Response | [47](47.md) |
|
||||
| `24133` | Nostr Connect | [46](46.md) |
|
||||
| `27235` | HTTP Auth | [98](98.md) |
|
||||
| `30000` | Categorized People List | [51](51.md) |
|
||||
| `30001` | Categorized Bookmark List | [51](51.md) |
|
||||
| `30008` | Profile Badges | [58](58.md) |
|
||||
@@ -108,8 +100,6 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
|
||||
| `30018` | Create or update a product | [15](15.md) |
|
||||
| `30023` | Long-form Content | [23](23.md) |
|
||||
| `30078` | Application-specific Data | [78](78.md) |
|
||||
| `31989` | Handler recommendation | [89](89.md) |
|
||||
| `31990` | Handler information | [89](89.md) |
|
||||
|
||||
### Event Kind Ranges
|
||||
|
||||
@@ -152,13 +142,10 @@ When experimenting with kinds, keep in mind the classification introduced by [NI
|
||||
| name | value | other parameters | NIP |
|
||||
| ----------------- | ------------------------------------ | -------------------- | ------------------------ |
|
||||
| `a` | coordinates to an event | relay URL | [33](33.md), [23](23.md) |
|
||||
| `alt` | Alt tag | -- | [31](31.md) |
|
||||
| `d` | identifier | -- | [33](33.md) |
|
||||
| `e` | event id (hex) | relay URL, marker | [1](01.md), [10](10.md) |
|
||||
| `g` | geohash | -- | [12](12.md) |
|
||||
| `i` | identity | proof | [39](39.md) |
|
||||
| `l` | label, label namespace | annotations | [32](32.md) |
|
||||
| `L` | label namespace | -- | [32](32.md) |
|
||||
| `p` | pubkey (hex) | relay URL | [1](01.md) |
|
||||
| `r` | a reference (URL, etc) | -- | [12](12.md) |
|
||||
| `t` | hashtag | -- | [12](12.md) |
|
||||
@@ -169,7 +156,6 @@ When experimenting with kinds, keep in mind the classification introduced by [NI
|
||||
| `delegation` | pubkey, conditions, delegation token | -- | [26](26.md) |
|
||||
| `description` | badge description | -- | [58](58.md) |
|
||||
| `description` | invoice description | -- | [57](57.md) |
|
||||
| `emoji` | shortcode | image URL | [30](30.md) |
|
||||
| `expiration` | unix timestamp (string) | -- | [40](40.md) |
|
||||
| `image` | image URL | dimensions in pixels | [23](23.md), [58](58.md) |
|
||||
| `lnurl` | `bech32` encoded `lnurl` | -- | [57](57.md) |
|
||||
|
||||
Reference in New Issue
Block a user