mirror of
https://github.com/nostr-protocol/nips.git
synced 2024-11-10 14:19:08 -05:00
Merge branch 'master' into nip89
This commit is contained in:
ATXMJ
GitHub
commit
2e8d4846dd
6
01.md
6
01.md
|
|
@ -22,7 +22,7 @@ The only object type that exists is the `event`, which has the following format
|
|||
"kind": <integer>,
|
||||
"tags": [
|
||||
["e", <32-bytes hex of the id of another event>, <recommended relay URL>],
|
||||
["p", <32-bytes hex of the key>, <recommended relay URL>],
|
||||
["p", <32-bytes hex of a pubkey>, <recommended relay URL>],
|
||||
... // other kinds of tags may be included later
|
||||
],
|
||||
"content": <arbitrary string>,
|
||||
|
|
@ -55,7 +55,7 @@ Clients can send 3 types of messages, which must be JSON arrays, according to th
|
|||
* `["REQ", <subscription_id>, <filters JSON>...]`, used to request events and subscribe to new updates.
|
||||
* `["CLOSE", <subscription_id>]`, used to stop previous subscriptions.
|
||||
|
||||
`<subscription_id>` is a random string that should be used to represent a subscription.
|
||||
`<subscription_id>` is an arbitrary, non-empty string of max length 64 chars, that should be used to represent a subscription.
|
||||
|
||||
`<filters>` is a JSON object that determines what events will be sent in that subscription, it can have the following attributes:
|
||||
|
||||
|
|
@ -98,7 +98,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 text content of a note (anything the user wants to say). Non-plaintext notes should instead use kind 1000-10000 as described in [NIP-16](16.md).
|
||||
- `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.
|
||||
|
|
|
|||
1
02.md
1
02.md
|
|
@ -22,6 +22,7 @@ For example:
|
|||
],
|
||||
"content": "",
|
||||
...other fields
|
||||
}
|
||||
```
|
||||
|
||||
Every new contact list that gets published overwrites the past ones, so it should contain all entries. Relays and clients SHOULD delete past contact lists as soon as they receive a new one.
|
||||
|
|
|
|||
8
04.md
8
04.md
|
|
@ -14,7 +14,7 @@ A special event with kind `4`, meaning "encrypted direct message". It is suppose
|
|||
|
||||
**`tags`** MAY contain an entry identifying the previous message in a conversation or a message we are explicitly replying to (such that contextual, more organized conversations may happen), in the form `["e", "<event_id>"]`.
|
||||
|
||||
**Note**: By default in the [libsecp256k1](https://github.com/bitcoin-core/secp256k1) ECDH implementation, the secret is the SHA256 hash of the shared point (both X and Y coorinates). In Nostr, only the X coordinate of the shared point is used as the secret and it is NOT hashed. If using libsecp256k1, a custom function that copies the X coordinate must be passed as the `hashfp` argument in `secp256k1_ecdh`. See [here](https://github.com/bitcoin-core/secp256k1/blob/master/src/modules/ecdh/main_impl.h#L29).
|
||||
**Note**: By default in the [libsecp256k1](https://github.com/bitcoin-core/secp256k1) ECDH implementation, the secret is the SHA256 hash of the shared point (both X and Y coordinates). In Nostr, only the X coordinate of the shared point is used as the secret and it is NOT hashed. If using libsecp256k1, a custom function that copies the X coordinate must be passed as the `hashfp` argument in `secp256k1_ecdh`. See [here](https://github.com/bitcoin-core/secp256k1/blob/master/src/modules/ecdh/main_impl.h#L29).
|
||||
|
||||
Code sample for generating such an event in JavaScript:
|
||||
|
||||
|
|
@ -23,7 +23,7 @@ import crypto from 'crypto'
|
|||
import * as secp from 'noble-secp256k1'
|
||||
|
||||
let sharedPoint = secp.getSharedSecret(ourPrivateKey, '02' + theirPublicKey)
|
||||
let sharedX = sharedPoint.substr(2, 64)
|
||||
let sharedX = sharedPoint.slice(2, 67)
|
||||
|
||||
let iv = crypto.randomFillSync(new Uint8Array(16))
|
||||
var cipher = crypto.createCipheriv(
|
||||
|
|
@ -43,3 +43,7 @@ let event = {
|
|||
content: encryptedMessage + '?iv=' + ivBase64
|
||||
}
|
||||
```
|
||||
|
||||
## Security Warning
|
||||
|
||||
This standard does not go anywhere near what is considered the state-of-the-art in encrypted communication between peers, and it leaks metadata in the events, therefore it must not be used for anything you really need to keep secret, and only with relays that use `AUTH` to restrict who can read your `kind:4` events.
|
||||
|
|
|
|||
9
07.md
9
07.md
|
|
@ -24,7 +24,8 @@ async window.nostr.nip04.decrypt(pubkey, ciphertext): string // takes ciphertext
|
|||
|
||||
### Implementation
|
||||
|
||||
- [nos2x](https://github.com/fiatjaf/nos2x)
|
||||
- [Alby](https://getalby.com)
|
||||
- [Blockcore](https://www.blockcore.net/wallet)
|
||||
- [nos2x-fox](https://diegogurpegui.com/nos2x-fox/)
|
||||
- [nos2x](https://github.com/fiatjaf/nos2x) (Chrome and derivatives)
|
||||
- [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)
|
||||
|
|
|
|||
2
08.md
2
08.md
|
|
@ -15,3 +15,5 @@ Once a mention is identified, for example, the pubkey `27866e9d854c78ae625b867ee
|
|||
The same process applies for mentioning event IDs.
|
||||
|
||||
A client that receives a `text_note` event with such `#[index]` mentions in its `.content` CAN do a search-and-replace using the actual contents from the `.tags` array with the actual pubkey or event ID that is mentioned, doing any desired context augmentation (for example, linking to the pubkey or showing a preview of the mentioned event contents) it wants in the process.
|
||||
|
||||
Where `#[index]` has an `index` that is outside the range of the tags array or points to a tag that is not an `e` or `p` tag or a tag otherwise declared to support this notation, the client MUST NOT perform such replacement or augmentation, but instead display it as normal text.
|
||||
|
|
|
|||
4
10.md
4
10.md
|
|
@ -43,8 +43,8 @@ They are citings from this event. `root-id` and `reply-id` are as above.
|
|||
Where:
|
||||
|
||||
* `<event-id>` is the id of the event being referenced.
|
||||
* `<relay-url>` is the URL of a recommended relay associated with the reference. It is NOT optional.
|
||||
* `<marker>` is optional and if present is one of `"reply"`, `"root"`, or `"mention"`
|
||||
* `<relay-url>` is the URL of a recommended relay associated with the reference. Clients SHOULD add a valid `<relay-URL>` field, but may instead leave it as `""`.
|
||||
* `<marker>` is optional and if present is one of `"reply"`, `"root"`, or `"mention"`.
|
||||
|
||||
**The order of marked "e" tags is not relevant.** Those marked with `"reply"` denote the id of the reply event being responded to. Those marked with `"root"` denote the root id of the reply thread being responded to. For top level replies (those replying directly to the root event), only the `"root"` marker should be used. Those marked with `"mention"` denote a quoted or reposted event id.
|
||||
|
||||
|
|
|
|||
2
20.md
2
20.md
|
|
@ -82,7 +82,7 @@ Client Handling
|
|||
|
||||
For the `pow:` prefix it may query relay metadata to get the updated difficulty requirement and try again in the background.
|
||||
|
||||
For the `invalid:` and `blocked`: prefix the client may wish to show these as styled error popups.
|
||||
For the `invalid:` and `blocked:` prefix the client may wish to show these as styled error popups.
|
||||
|
||||
The prefixes include a colon so that the message can be cleanly separated from the prefix by taking everything after `:` and trimming it.
|
||||
|
||||
|
|
|
|||
9
28.md
9
28.md
|
|
@ -9,7 +9,7 @@ Public Chat
|
|||
|
||||
This NIP defines new event kinds for public chat channels, channel messages, and basic client-side moderation.
|
||||
|
||||
It reserves five event kinds (40-44) for immediate use and five event kinds (45-49) for future use.
|
||||
It reserves five event kinds (40-44) for immediate use:
|
||||
|
||||
- `40 - channel create`
|
||||
- `41 - channel metadata`
|
||||
|
|
@ -84,6 +84,7 @@ Reply to another message:
|
|||
{
|
||||
"content": <string>,
|
||||
"tags": [
|
||||
["e", <kind_40_event_id>, <relay-url>, "root"],
|
||||
["e", <kind_42_event_id>, <relay-url>, "reply"],
|
||||
["p", <pubkey>, <relay-url>],
|
||||
...
|
||||
|
|
@ -138,12 +139,6 @@ For [NIP-10](10.md) relay recommendations, clients generally SHOULD use the rela
|
|||
Clients MAY recommend any relay URL. For example, if a relay hosting the original kind 40 event for a channel goes offline, clients could instead fetch channel data from a backup relay, or a relay that clients trust more than the original relay.
|
||||
|
||||
|
||||
Future extensibility
|
||||
--------------------
|
||||
|
||||
We reserve event kinds 45-49 for other events related to chat, to potentially include new types of media (photo/video), moderation, or support of private or group messaging.
|
||||
|
||||
|
||||
Motivation
|
||||
----------
|
||||
If we're solving censorship-resistant communication for social media, we may as well solve it also for Telegram-style messaging.
|
||||
|
|
|
|||
162
46.md
Normal file
162
46.md
Normal file
|
|
@ -0,0 +1,162 @@
|
|||
NIP-46
|
||||
======
|
||||
|
||||
Nostr Connect
|
||||
------------------------
|
||||
|
||||
`draft` `optional` `author:tiero` `author:giowe` `author:vforvalerio87`
|
||||
|
||||
## Rationale
|
||||
|
||||
Private keys should be exposed to as few systems - apps, operating systems, devices - as possible as each system adds to the attack surface.
|
||||
|
||||
Entering private keys can also be annoying and requires exposing them to even more systems such as the operating system's clipboard that might be monitored by malicious apps.
|
||||
|
||||
|
||||
## Terms
|
||||
|
||||
* **App**: Nostr app on any platform that *requires* to act on behalf of a nostr account.
|
||||
* **Signer**: Nostr app that holds the private key of a nostr account and *can sign* on its behalf.
|
||||
|
||||
|
||||
## `TL;DR`
|
||||
|
||||
|
||||
**App** and **Signer** sends ephemeral encrypted messages to each other using kind `24133`, using a relay of choice.
|
||||
|
||||
App prompts the Signer to do things such as fetching the public key or signing events.
|
||||
|
||||
The `content` field must be an encrypted JSONRPC-ish **request** or **response**.
|
||||
|
||||
## Signer Protocol
|
||||
|
||||
### Messages
|
||||
|
||||
#### Request
|
||||
|
||||
```json
|
||||
{
|
||||
"id": <random_string>,
|
||||
"method": <one_of_the_methods>,
|
||||
"params": [<anything>, <else>]
|
||||
}
|
||||
```
|
||||
|
||||
#### Response
|
||||
|
||||
```json
|
||||
{
|
||||
"id": <request_id>,
|
||||
"result": <anything>,
|
||||
"error": <reason>
|
||||
}
|
||||
```
|
||||
|
||||
### Methods
|
||||
|
||||
|
||||
#### Mandatory
|
||||
|
||||
These are mandatory methods the remote signer app MUST implement:
|
||||
|
||||
- **describe**
|
||||
- params []
|
||||
- result `["describe", "get_public_key", "sign_event", "connect", "disconnect", "delegate", ...]`
|
||||
- **get_public_key**
|
||||
- params []
|
||||
- result `pubkey`
|
||||
- **sign_event**
|
||||
- params [`event`]
|
||||
- result `signature`
|
||||
|
||||
#### optional
|
||||
|
||||
|
||||
- **connect**
|
||||
- params [`pubkey`]
|
||||
- **disconnect**
|
||||
- params []
|
||||
- **delegate**
|
||||
- params [`delegatee`, `{ kind: number, since: number, until: number }`]
|
||||
- result `{ from: string, to: string, cond: string, sig: string }`
|
||||
- **get_relays**
|
||||
- params []
|
||||
- result `{ [url: string]: {read: boolean, write: boolean} }`
|
||||
- **nip04_encrypt**
|
||||
- params [`pubkey`, `plaintext`]
|
||||
- result `nip4 ciphertext`
|
||||
- **nip04_decrypt**
|
||||
- params [`pubkey`, `nip4 ciphertext`]
|
||||
- result [`plaintext`]
|
||||
|
||||
|
||||
NOTICE: `pubkey` and `signature` are hex-encoded strings.
|
||||
|
||||
|
||||
### Nostr Connect URI
|
||||
|
||||
**Signer** discovers **App** by scanning a QR code, clicking on a deep link or copy-pasting an URI.
|
||||
|
||||
The **App** generates a special URI with prefix `nostrconnect://` and base path the hex-encoded `pubkey` with the following querystring parameters **URL encoded**
|
||||
|
||||
- `relay` URL of the relay of choice where the **App** is connected and the **Signer** must send and listen for messages.
|
||||
- `metadata` metadata JSON of the **App**
|
||||
- `name` human-readable name of the **App**
|
||||
- `url` (optional) URL of the website requesting the connection
|
||||
- `description` (optional) description of the **App**
|
||||
- `icons` (optional) array of URLs for icons of the **App**.
|
||||
|
||||
#### JavaScript
|
||||
|
||||
```js
|
||||
const uri = `nostrconnect://<pubkey>?relay=${encodeURIComponent("wss://relay.damus.io")}&metadata=${encodeURIComponent(JSON.stringify({"name": "Example"}))}`
|
||||
```
|
||||
|
||||
#### Example
|
||||
```sh
|
||||
nostrconnect://b889ff5b1513b641e2a139f661a661364979c5beee91842f8f0ef42ab558e9d4?relay=wss%3A%2F%2Frelay.damus.io&metadata=%7B%22name%22%3A%22Example%22%7D
|
||||
```
|
||||
|
||||
|
||||
|
||||
## Flows
|
||||
|
||||
The `content` field contains encrypted message as specified by [NIP04](https://github.com/nostr-protocol/nips/blob/master/04.md). The `kind` chosen is `24133`.
|
||||
|
||||
### Connect
|
||||
|
||||
1. User clicks on **"Connect"** button on a website or scan it with a QR code
|
||||
2. It will show an URI to open a "nostr connect" enabled **Signer**
|
||||
3. In the URI there is a pubkey of the **App** ie. `nostrconnect://<pubkey>&relay=<relay>&metadata=<metadata>`
|
||||
4. The **Signer** will send a message to ACK the `connect` request, along with his public key
|
||||
|
||||
### Disconnect (from App)
|
||||
|
||||
1. User clicks on **"Disconnect"** button on the **App**
|
||||
2. The **App** will send a message to the **Signer** with a `disconnect` request
|
||||
3. The **Signer** will send a message to ACK the `disconnect` request
|
||||
|
||||
### Disconnect (from Signer)
|
||||
|
||||
1. User clicks on **"Disconnect"** button on the **Signer**
|
||||
2. The **Signer** will send a message to the **App** with a `disconnect` request
|
||||
|
||||
|
||||
### Get Public Key
|
||||
|
||||
1. The **App** will send a message to the **Signer** with a `get_public_key` request
|
||||
3. The **Signer** will send back a message with the public key as a response to the `get_public_key` request
|
||||
|
||||
### Sign Event
|
||||
|
||||
1. The **App** will send a message to the **Signer** with a `sign_event` request along with the **event** to be signed
|
||||
2. The **Signer** will show a popup to the user to inspect the event and sign it
|
||||
3. The **Signer** will send back a message with the schnorr `signature` of the event as a response to the `sign_event` request
|
||||
|
||||
### Delegate
|
||||
|
||||
1. The **App** will send a message with metadata to the **Signer** with a `delegate` request along with the **conditions** query string and the **pubkey** of the **App** to be delegated.
|
||||
2. The **Signer** will show a popup to the user to delegate the **App** to sign on his behalf
|
||||
3. The **Signer** will send back a message with the signed [NIP-26 delegation token](https://github.com/nostr-protocol/nips/blob/master/26.md) or reject it
|
||||
|
||||
|
||||
4
57.md
4
57.md
|
|
@ -30,7 +30,7 @@ Having lightning receipts on nostr allows clients to display lightning payments
|
|||
|
||||
3. Clients may choose to display a lightning zap button on each post or on the users profile, if the user's lnurl pay request endpoint supports nostr, the client SHOULD generate a `zap invoice` instead of a normal lnurl invoice.
|
||||
|
||||
4. To generate a `zap invoice`, call the `callback` url with `amount` set to the milli-satoshi amount value. A `nostr` querystring value MUST be set as well. It is a uri-encoded `zap request` note signed by the user's key. The `zap request` note contains an `e` tag of the note it is zapping, and a `p` tag of the target user's pubkey. The `e` tag is optional which allows profile tipping. The `zap request` note must also have a `relays` tag, which is gathered from the user's configured relays. The `zap request` note SHOULD contain an `amount` tag, which is the milli-satoshi value of the zap which clients SHOULD verify being equal to the amount of the invoice. The `content` MAY be an additional comment from the user which can be displayed when listing zaps on posts and profiles.
|
||||
4. To generate a `zap invoice`, call the `callback` url with `amount` set to the milli-satoshi amount value. A `nostr` querystring value MUST be set as well. It is a uri-encoded `zap request` note signed by the user's key. The `zap request` note contains an `e` tag of the note it is zapping, and a `p` tag of the target user's pubkey. The `e` tag is optional which allows profile tipping. An optional `a` tag allows tipping parameterized replaceable events such as NIP-23 long-form notes. The `zap request` note must also have a `relays` tag, which is gathered from the user's configured relays. The `zap request` note SHOULD contain an `amount` tag, which is the milli-satoshi value of the zap which clients SHOULD verify being equal to the amount of the invoice. The `content` MAY be an additional comment from the user which can be displayed when listing zaps on posts and profiles.
|
||||
|
||||
5. Pay this invoice or pass it to an app that can pay the invoice. Once it's paid, a `zap note` will be created by the `zapper`.
|
||||
|
||||
|
|
@ -58,6 +58,8 @@ The lnurl server will need some additional pieces of information so that clients
|
|||
|
||||
f. If there is an `amount` tag, it MUST be equal to the `amount` query parameter.
|
||||
|
||||
g. If there is an `a` tag, it MUST be a valid NIP-33 event coordinate
|
||||
|
||||
5. If valid, fetch a description hash invoice where the description is this note and this note only. No additional lnurl metadata is included in the description.
|
||||
|
||||
At this point, the lightning node is ready to send the zap note once payment is received.
|
||||
|
|
|
|||
132
58.md
Normal file
132
58.md
Normal file
|
|
@ -0,0 +1,132 @@
|
|||
NIP-58
|
||||
======
|
||||
|
||||
Badges
|
||||
------
|
||||
|
||||
`draft` `optional` `author:cameri`
|
||||
|
||||
Three special events are used to define, award and display badges in
|
||||
user profiles:
|
||||
|
||||
1. A "Badge Definition" event is defined as a parameterized replaceable event
|
||||
with kind `30009` having a `d` tag with a value that uniquely identifies
|
||||
the badge (e.g. `bravery`) published by the badge issuer. Badge definitions can
|
||||
be updated.
|
||||
|
||||
2. A "Badge Award" event is a kind `8` event with a single `a` tag referencing
|
||||
a "Define Badge" event and one or more `p` tags, one for each pubkey the
|
||||
badge issuer wishes to award. The value for the `a` tag MUST follow the format
|
||||
defined in [NIP-33](33.md). Awarded badges are immutable and non-transferrable.
|
||||
|
||||
3. A "Profile Badges" event is defined as a parameterized replaceable event
|
||||
with kind `30008` with a `d` tag with the value `profile_badges`.
|
||||
Profile badges contain an ordered list of pairs of `a` and `e` tags referencing a `Badge Definition` and a `Badge Award` for each badge to be displayed.
|
||||
|
||||
### Badge Definition event
|
||||
|
||||
The following tags MUST be present:
|
||||
|
||||
- `d` tag with the unique name of the badge.
|
||||
|
||||
The following tags MAY be present:
|
||||
|
||||
- A `name` tag with a short name for the badge.
|
||||
- `image` tag whose value is the URL of a high-resolution image representing the badge. The second value optionally specifies the dimensions of the image as `width`x`height` in pixels. Badge recommended dimensions is 1024x1024 pixels.
|
||||
- A `description` tag whose value MAY contain a textual representation of the
|
||||
image, the meaning behind the badge, or the reason of it's issuance.
|
||||
- One or more `thumb` tags whose first value is an URL pointing to a thumbnail version of the image referenced in the `image` tag. The second value optionally specifies the dimensions of the thumbnail as `width`x`height` in pixels.
|
||||
|
||||
### Badge Award event
|
||||
|
||||
The following tags MUST be present:
|
||||
|
||||
- An `a` tag referencing a kind `30009` Badge Definition event.
|
||||
- One or more `p` tags referencing each pubkey awarded.
|
||||
|
||||
### Profile Badges Event
|
||||
|
||||
The number of badges a pubkey can be awarded is unbounded. The Profile Badge
|
||||
event allows individual users to accept or reject awarded badges, as well
|
||||
as choose the display order of badges on their profiles.
|
||||
|
||||
The following tags MUST be present:
|
||||
|
||||
- A `d` tag with the unique identifier `profile_badges`
|
||||
|
||||
The following tags MAY be present:
|
||||
|
||||
- Zero or more ordered consecutive pairs of `a` and `e` tags referencing a kind `30009` Badge Definition and kind `8` Badge Award, respectively. Clients SHOULD
|
||||
ignore `a` without corresponding `e` tag and viceversa. Badge Awards referenced
|
||||
by the `e` tags should contain the same `a` tag.
|
||||
|
||||
### Motivation
|
||||
|
||||
Users MAY be awarded badges (but not limited to) in recognition, in gratitude, for participation, or in appreciation of a certain goal, task or cause.
|
||||
|
||||
Users MAY choose to decorate their profiles with badges for fame, notoriety, recognition, support, etc., from badge issuers they deem reputable.
|
||||
|
||||
### Recommendations
|
||||
|
||||
Badge issuers MAY include some Proof of Work as per [NIP-13](13.md) when minting Badge Definitions or Badge Awards to embed them with a combined energy cost, arguably making them more special and valuable for users that wish to collect them.
|
||||
|
||||
Clients MAY whitelist badge issuers (pubkeys) for the purpose of ensuring they retain a valuable/special factor for their users.
|
||||
|
||||
Badge image recommended aspect ratio is 1:1 with a high-res size of 1024x1024 pixels.
|
||||
|
||||
Badge thumbnail image recommended dimensions are: 512x512 (xl), 256x256 (l), 64x64 (m), 32x32 (s) and 16x16 (xs).
|
||||
|
||||
Clients MAY choose to render less badges than those specified by users in the Profile Badges event or replace the badge image and thumbnails with ones that fits the theme of the client.
|
||||
|
||||
Clients SHOULD attempt to render the most appropriate badge thumbnail according to the number of badges chosen by the user and space available. Clients SHOULD attempt render the high-res version on user action (click, tap, hover).
|
||||
|
||||
### Example of a Badge Definition event
|
||||
|
||||
```json
|
||||
{
|
||||
"pubkey": "alice",
|
||||
"kind": 30009,
|
||||
"tags": [
|
||||
["d", "bravery"],
|
||||
["name", "Medal of Bravery"],
|
||||
["description", "Awarded to users demonstrating bravery"],
|
||||
["image", "https://nostr.academy/awards/bravery.png", "1024x1024"],
|
||||
["thumb", "https://nostr.academy/awards/bravery_256x256.png", "256x256"],
|
||||
],
|
||||
...
|
||||
}
|
||||
```
|
||||
|
||||
### Example of Badge Award event
|
||||
|
||||
```json
|
||||
{
|
||||
"id": "<badge award event id>",
|
||||
"kind": 8,
|
||||
"pubkey": "alice",
|
||||
"tags": [
|
||||
["a", "30009:alice:bravery"],
|
||||
["p", "bob", "wss://relay"],
|
||||
["p", "charlie", "wss://relay"],
|
||||
],
|
||||
...
|
||||
}
|
||||
```
|
||||
|
||||
### Example of a Profile Badges event
|
||||
|
||||
Honorable Bob The Brave:
|
||||
```json
|
||||
{
|
||||
"kind": 30008,
|
||||
"pubkey": "bob",
|
||||
"tags": [
|
||||
["d", "profile_badges"],
|
||||
["a", "30009:alice:bravery"],
|
||||
["e", "<bravery badge award event id>", "wss://nostr.academy"],
|
||||
["a", "30009:alice:honor"],
|
||||
["e", "<honor badge award event id>", "wss://nostr.academy"],
|
||||
],
|
||||
...
|
||||
}
|
||||
```
|
||||
16
65.md
16
65.md
|
|
@ -10,20 +10,26 @@ A special replaceable event meaning "Relay List Metadata" is defined as an event
|
|||
|
||||
The primary purpose of this relay list is to advertise to others, not for configuring one's client.
|
||||
|
||||
The content is not used and SHOULD be blank.
|
||||
The content is not used and SHOULD be an empty string.
|
||||
|
||||
The `r` tags can have a second parameter as either `read` or `write`. If it is omitted, it means the author both reads from and writes to that relay.
|
||||
The `r` tags can have a second parameter as either `read` or `write`. If it is omitted, it means the author uses the relay for both purposes.
|
||||
|
||||
Clients SHOULD, as with all replaceable events, use only the most recent kind-10002 event they can find.
|
||||
|
||||
### The meaning of read and write
|
||||
|
||||
If an author advertises a write relay in a kind `10002` event, that means that feed-related events created by the author, which the author wants their followers to see, will be posted there. Normally these would be kind-1 Text Note events, but are not limited as such.
|
||||
Write relays are for events that are intended for anybody (e.g. your followers). Read relays are for events that address a particular person.
|
||||
|
||||
Clients SHOULD write feed-related events created by their user to their user's write relays.
|
||||
|
||||
Clients SHOULD read feed-related events created by another from at least some of that other person's write relays. Explicitly, they SHOULD NOT expect them to be available at their user's read relays. It SHOULD NOT be presumed that the user's read relays coincide with the write relays of the people the user follows.
|
||||
|
||||
Clients SHOULD read events that tag their user from their user's read relays.
|
||||
|
||||
Clients SHOULD write events that tag a person to at least some of that person's read relays. Explicitly, they SHOULD NOT expect that person will pick them up from their user's write relays. It SHOULD NOT be presumed that the user's write relays coincide with the read relays of the person being tagged.
|
||||
|
||||
Clients SHOULD presume that if their user has a pubkey in their ContactList (kind 3) that it is because they wish to see that author's feed-related events. But clients MAY presume otherwise.
|
||||
|
||||
If an author advertises a read relay in a kind `10002` event, that means that the author may be subscribed to events that tag them on such relays. Clients SHOULD publish events that tag someone on at least some of the read relays of the person being tagged.
|
||||
|
||||
### Motivation
|
||||
|
||||
There is a common nostr use case where users wish to follow the content produced by other users. This is evidenced by the implicit meaning of the Contact List in [NIP-02](02.md)
|
||||
|
|
|
|||
21
78.md
Normal file
21
78.md
Normal file
|
|
@ -0,0 +1,21 @@
|
|||
NIP-78
|
||||
======
|
||||
|
||||
Arbitrary custom app data
|
||||
-------------------------
|
||||
|
||||
`draft` `optional` `author:sandwich` `author:fiatjaf`
|
||||
|
||||
The goal of this NIP is to enable [remoteStorage](https://remotestorage.io/)-like capabilities for custom applications that do not care about interoperability.
|
||||
|
||||
Even though interoperability is great, some apps do not want or do not need interoperability, and it that wouldn't make sense for them. Yet Nostr can still serve as a generalized data storage for these apps in a "bring your own database" way, for example: a user would open an app and somehow input their preferred relay for storage, which would then enable these apps to store application-specific data there.
|
||||
|
||||
## Nostr event
|
||||
|
||||
This NIP specifies the use of event kind `30078` (parameterized replaceable event) with a `d` tag containing some reference to the app name and context -- or any other arbitrary string. `content` and other `tags` can be anything or in any format.
|
||||
|
||||
## Some use cases
|
||||
|
||||
- User personal settings on Nostr clients (and other apps unrelated to Nostr)
|
||||
- A way for client developers to propagate dynamic parameters to users without these having to update
|
||||
- Personal private data generated by apps that have nothing to do with Nostr, but allow users to use Nostr relays as their personal database
|
||||
61
README.md
61
README.md
|
|
@ -30,40 +30,45 @@ NIPs stand for **Nostr Implementation Possibilities**. They exist to document wh
|
|||
- [NIP-36: Sensitive Content](36.md)
|
||||
- [NIP-40: Expiration Timestamp](40.md)
|
||||
- [NIP-42: Authentication of clients to relays](42.md)
|
||||
- [NIP-46: Nostr Connect](46.md)
|
||||
- [NIP-50: Keywords filter](50.md)
|
||||
- [NIP-56: Reporting](56.md)
|
||||
- [NIP-57: Lightning Zaps](57.md)
|
||||
- [NIP-58: Badges](58.md)
|
||||
- [NIP-65: Relay List Metadata](65.md)
|
||||
- [NIP-78: Application-specific data](78.md)
|
||||
- [NIP-89: payto: Payment Targets](89.md)
|
||||
|
||||
## Event Kinds
|
||||
| kind | description | NIP |
|
||||
| ------------- | -------------------------------- | ----------------------- |
|
||||
| 0 | Metadata | [1](01.md), [5](05.md) |
|
||||
| 1 | Short Text Note | [1](01.md) |
|
||||
| 2 | Recommend Relay | [1](01.md) |
|
||||
| 3 | Contacts | [2](02.md) |
|
||||
| 4 | Encrypted Direct Messages | [4](04.md) |
|
||||
| 5 | Event Deletion | [9](09.md) |
|
||||
| 7 | Reaction | [25](25.md) |
|
||||
| 40 | Channel Creation | [28](28.md) |
|
||||
| 41 | Channel Metadata | [28](28.md) |
|
||||
| 42 | Channel Message | [28](28.md) |
|
||||
| 43 | Channel Hide Message | [28](28.md) |
|
||||
| 44 | Channel Mute User | [28](28.md) |
|
||||
| 45-49 | Public Chat Reserved | [28](28.md) |
|
||||
| 1984 | Reporting | [56](56.md) |
|
||||
| 9734 | Zap Request | [57](57.md) |
|
||||
| 9735 | Zap | [57](57.md) |
|
||||
| 10002 | Relay List Metadata | [65](65.md) |
|
||||
| 22242 | Client Authentication | [42](42.md) |
|
||||
| 30023 | Long-form Content | [23](23.md) |
|
||||
| 1000-9999 | Regular Events | [16](16.md) |
|
||||
| 10000-19999 | Replaceable Events | [16](16.md) |
|
||||
| 20000-29999 | Ephemeral Events | [16](16.md) |
|
||||
| 30000-39999 | Parameterized Replaceable Events | [33](33.md) |
|
||||
|
||||
|
||||
| kind | description | NIP |
|
||||
| ------------- | -------------------------------- | ----------- |
|
||||
| 0 | Metadata | [1](01.md) |
|
||||
| 1 | Short Text Note | [1](01.md) |
|
||||
| 2 | Recommend Relay | [1](01.md) |
|
||||
| 3 | Contacts | [2](02.md) |
|
||||
| 4 | Encrypted Direct Messages | [4](04.md) |
|
||||
| 5 | Event Deletion | [9](09.md) |
|
||||
| 7 | Reaction | [25](25.md) |
|
||||
| 8 | Badge Award | [58](58.md) |
|
||||
| 40 | Channel Creation | [28](28.md) |
|
||||
| 41 | Channel Metadata | [28](28.md) |
|
||||
| 42 | Channel Message | [28](28.md) |
|
||||
| 43 | Channel Hide Message | [28](28.md) |
|
||||
| 44 | Channel Mute User | [28](28.md) |
|
||||
| 1984 | Reporting | [56](56.md) |
|
||||
| 9734 | Zap Request | [57](57.md) |
|
||||
| 9735 | Zap | [57](57.md) |
|
||||
| 10002 | Relay List Metadata | [65](65.md) |
|
||||
| 22242 | Client Authentication | [42](42.md) |
|
||||
| 24133 | Nostr Connect | [46](46.md) |
|
||||
| 30008 | Profile Badges | [58](58.md) |
|
||||
| 30009 | Badge Definition | [58](58.md) |
|
||||
| 30023 | Long-form Content | [23](23.md) |
|
||||
| 30078 | Application-specific Data | [78](78.md) |
|
||||
| 1000-9999 | Regular Events | [16](16.md) |
|
||||
| 10000-19999 | Replaceable Events | [16](16.md) |
|
||||
| 20000-29999 | Ephemeral Events | [16](16.md) |
|
||||
| 30000-39999 | Parameterized Replaceable Events | [33](33.md) |
|
||||
|
||||
## Message types
|
||||
|
||||
|
|
@ -81,7 +86,7 @@ NIPs stand for **Nostr Implementation Possibilities**. They exist to document wh
|
|||
| EVENT | used to send events requested to clients | [1](01.md) |
|
||||
| NOTICE | used to send human-readable messages to clients | [1](01.md) |
|
||||
| EOSE | used to notify clients all stored events have been sent | [15](15.md) |
|
||||
| OK | used to notify clients if an EVENT was successuful | [20](20.md) |
|
||||
| OK | used to notify clients if an EVENT was successful | [20](20.md) |
|
||||
| AUTH | used to send authentication challenges | [42](42.md) |
|
||||
|
||||
Please update these lists when proposing NIPs introducing new event kinds.
|
||||
|
|
|
|||
Loading…
Reference in New Issue
Block a user