Merge branch 'nostr-protocol:master' into master

This commit is contained in:
Vitor Pamplona 2024-10-27 19:48:50 -04:00 committed by GitHub
commit 8b01638bba
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
17 changed files with 630 additions and 194 deletions

6
01.md
View File

@ -77,11 +77,11 @@ This NIP defines 3 standard tags that can be used across all event kinds with th
- The `e` tag, used to refer to an event: `["e", <32-bytes lowercase hex of the id of another event>, <recommended relay URL, optional>]`
- The `p` tag, used to refer to another user: `["p", <32-bytes lowercase hex of a pubkey>, <recommended relay URL, optional>]`
- The `a` tag, used to refer to a (maybe parameterized) replaceable event
- The `a` tag, used to refer to an addressable or replaceable event
- for an addressable event: `["a", <kind integer>:<32-bytes lowercase hex of a pubkey>:<d tag value>, <recommended relay URL, optional>]`
- for a normal replaceable event: `["a", <kind integer>:<32-bytes lowercase hex of a pubkey>:, <recommended relay URL, optional>]`
As a convention, all single-letter (only english alphabet letters: a-z, A-Z) key tags are expected to be indexed by relays, such that it is possible, for example, to query or subscribe to events that reference the event `"5c83da77af1dec6d7289834998ad7aafbd9e2191396d75ec3cc27f5a77226f36"` by using the `{"#e": ["5c83da77af1dec6d7289834998ad7aafbd9e2191396d75ec3cc27f5a77226f36"]}` filter.
As a convention, all single-letter (only english alphabet letters: a-z, A-Z) key tags are expected to be indexed by relays, such that it is possible, for example, to query or subscribe to events that reference the event `"5c83da77af1dec6d7289834998ad7aafbd9e2191396d75ec3cc27f5a77226f36"` by using the `{"#e": ["5c83da77af1dec6d7289834998ad7aafbd9e2191396d75ec3cc27f5a77226f36"]}` filter. Only the first value in any given tag is indexed.
### Kinds
@ -95,7 +95,7 @@ And also a convention for kind ranges that allow for easier experimentation and
- for kind `n` such that `1000 <= n < 10000 || 4 <= n < 45 || n == 1 || n == 2`, events are **regular**, which means they're all expected to be stored by relays.
- for kind `n` such that `10000 <= n < 20000 || n == 0 || n == 3`, events are **replaceable**, which means that, for each combination of `pubkey` and `kind`, only the latest event MUST be stored by relays, older versions MAY be discarded.
- for kind `n` such that `20000 <= n < 30000`, events are **ephemeral**, which means they are not expected to be stored by relays.
- for kind `n` such that `30000 <= n < 40000`, events are **parameterized replaceable**, which means that, for each combination of `pubkey`, `kind` and the `d` tag's first value, only the latest event MUST be stored by relays, older versions MAY be discarded.
- for kind `n` such that `30000 <= n < 40000`, events are **addressable** by their `kind`, `pubkey` and `d` tag value -- which means that, for each combination of `kind`, `pubkey` and the `d` tag value, only the latest event MUST be stored by relays, older versions MAY be discarded.
In case of replaceable events with the same timestamp, the event with the lowest id (first in lexical order) should be retained, and the other discarded.

8
18.md
View File

@ -25,6 +25,14 @@ quote reposted. The `q` tag ensures quote reposts are not pulled and included
as replies in threads. It also allows you to easily pull and count all of the
quotes for a post.
`q` tags should follow the same conventions as NIP 10 `e` tags, with the exception
of the `mark` argument.
`["q", <event-id>, <relay-url>, <pubkey>]`
Quote reposts MUST include the [NIP-21](21.md) `nevent`, `note`, or `naddr` of the
event in the content.
## Generic Reposts
Since `kind 6` reposts are reserved for `kind 1` contents, we use `kind 16`

4
23.md
View File

@ -20,7 +20,7 @@ The `.content` of these events should be a string text in Markdown syntax. To ma
### Metadata
For the date of the last update the `.created_at` field should be used, for "tags"/"hashtags" (i.e. topics about which the event might be of relevance) the `t` tag should be used, as per NIP-12.
For the date of the last update the `.created_at` field should be used, for "tags"/"hashtags" (i.e. topics about which the event might be of relevance) the `t` tag should be used.
Other metadata fields can be added as tags to the event as necessary. Here we standardize 4 that may be useful, although they remain strictly optional:
@ -31,7 +31,7 @@ Other metadata fields can be added as tags to the event as necessary. Here we st
### Editability
These articles are meant to be editable, so they should make use of the parameterized replaceability feature and include a `d` tag with an identifier for the article. Clients should take care to only publish and read these events from relays that implement that. If they don't do that they should also take care to hide old versions of the same article they may receive.
These articles are meant to be editable, so they should include a `d` tag with an identifier for the article. Clients should take care to only publish and read these events from relays that implement that. If they don't do that they should also take care to hide old versions of the same article they may receive.
### Linking

4
32.md
View File

@ -8,7 +8,7 @@ Labeling
This NIP defines two new indexable tags to label events and a new event kind (`kind:1985`) to attach those labels to existing events. This supports several use cases, including distributed moderation, collection management, license assignment, and content classification.
New Tags:
New Tags:
- `L` denotes a label namespace
- `l` denotes a label
@ -146,7 +146,7 @@ Other Notes
-----------
When using this NIP to bulk-label many targets at once, events may be requested for deletion using [NIP-09](09.md) and a replacement
may be published. We have opted not to use parameterizable/replaceable events for this due to the
may be published. We have opted not to use addressable/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.

2
38.md
View File

@ -46,7 +46,7 @@ Two common status types are defined: `general` and `music`. `general` represent
Any other status types can be used but they are not defined by this NIP.
The status MAY include an `r`, `p`, `e` or `a` tag linking to a URL, profile, note, or parameterized replaceable event.
The status MAY include an `r`, `p`, `e` or `a` tag linking to a URL, profile, note, or addressable event.
The `content` MAY include emoji(s), or [NIP-30](30.md) custom emoji(s). If the `content` is an empty string then the client should clear the status.

6
52.md
View File

@ -20,7 +20,7 @@ This kind of calendar event starts on a date and ends before a different date in
#### Format
The format uses a parameterized replaceable event kind `31922`.
The format uses an _addressable event_ of `kind:31922`.
The `.content` of these events should be a detailed description of the calendar event. It is required but can be an empty string.
@ -79,7 +79,7 @@ This kind of calendar event spans between a start time and end time.
#### Format
The format uses a parameterized replaceable event kind `31923`.
The format uses an _addressable event_ kind `31923`.
The `.content` of these events should be a detailed description of the calendar event. It is required but can be an empty string.
@ -193,7 +193,7 @@ The RSVP MAY tag the author of the calendar event it is in response to using a `
### Format
The format uses a parameterized replaceable event kind `31925`.
The format uses an _addressable event_ kind `31925`.
The `.content` of these events is optional and should be a free-form note that adds more context to this calendar event response.

178
55.md
View File

@ -53,8 +53,8 @@ val launcher = rememberLauncherForActivityResult(
Toast.LENGTH_SHORT
).show()
} else {
val signature = activityResult.data?.getStringExtra("signature")
// Do something with signature ...
val result = activityResult.data?.getStringExtra("result")
// Do something with result ...
}
}
)
@ -101,10 +101,10 @@ launcher.launch(intent)
context.startActivity(intent)
```
- result:
- If the user approved intent it will return the **npub** in the signature field
- If the user approved intent it will return the **pubkey** in the result field
```kotlin
val npub = intent.data?.getStringExtra("signature")
val pubkey = intent.data?.getStringExtra("result")
// The package name of the signer application
val packageName = intent.data?.getStringExtra("package")
```
@ -118,16 +118,16 @@ launcher.launch(intent)
intent.putExtra("type", "sign_event")
// To handle results when not waiting between intents
intent.putExtra("id", event.id)
// Send the current logged in user npub
intent.putExtra("current_user", npub)
// Send the current logged in user pubkey
intent.putExtra("current_user", pubkey)
context.startActivity(intent)
```
- result:
- If the user approved intent it will return the **signature**, **id** and **event** fields
- If the user approved intent it will return the **result**, **id** and **event** fields
```kotlin
val signature = intent.data?.getStringExtra("signature")
val signature = intent.data?.getStringExtra("result")
// The id you sent
val id = intent.data?.getStringExtra("id")
val signedEventJson = intent.data?.getStringExtra("event")
@ -142,18 +142,18 @@ launcher.launch(intent)
intent.putExtra("type", "nip04_encrypt")
// to control the result in your application in case you are not waiting the result before sending another intent
intent.putExtra("id", "some_id")
// Send the current logged in user npub
intent.putExtra("current_user", account.keyPair.pubKey.toNpub())
// Send the hex pubKey that will be used for encrypting the data
intent.putExtra("pubKey", pubKey)
// Send the current logged in user pubkey
intent.putExtra("current_user", account.keyPair.pubkey)
// Send the hex pubkey that will be used for encrypting the data
intent.putExtra("pubkey", pubkey)
context.startActivity(intent)
```
- result:
- If the user approved intent it will return the **signature** and **id** fields
- If the user approved intent it will return the **result** and **id** fields
```kotlin
val encryptedText = intent.data?.getStringExtra("signature")
val encryptedText = intent.data?.getStringExtra("result")
// the id you sent
val id = intent.data?.getStringExtra("id")
```
@ -167,10 +167,10 @@ launcher.launch(intent)
intent.putExtra("type", "nip44_encrypt")
// to control the result in your application in case you are not waiting the result before sending another intent
intent.putExtra("id", "some_id")
// Send the current logged in user npub
intent.putExtra("current_user", account.keyPair.pubKey.toNpub())
// Send the hex pubKey that will be used for encrypting the data
intent.putExtra("pubKey", pubKey)
// Send the current logged in user pubkey
intent.putExtra("current_user", account.keyPair.pubkey)
// Send the hex pubkey that will be used for encrypting the data
intent.putExtra("pubkey", pubkey)
context.startActivity(intent)
```
@ -192,18 +192,18 @@ launcher.launch(intent)
intent.putExtra("type", "nip04_decrypt")
// to control the result in your application in case you are not waiting the result before sending another intent
intent.putExtra("id", "some_id")
// Send the current logged in user npub
intent.putExtra("current_user", account.keyPair.pubKey.toNpub())
// Send the hex pubKey that will be used for decrypting the data
intent.putExtra("pubKey", pubKey)
// Send the current logged in user pubkey
intent.putExtra("current_user", account.keyPair.pubkey)
// Send the hex pubkey that will be used for decrypting the data
intent.putExtra("pubkey", pubkey)
context.startActivity(intent)
```
- result:
- If the user approved intent it will return the **signature** and **id** fields
- If the user approved intent it will return the **result** and **id** fields
```kotlin
val plainText = intent.data?.getStringExtra("signature")
val plainText = intent.data?.getStringExtra("result")
// the id you sent
val id = intent.data?.getStringExtra("id")
```
@ -217,18 +217,41 @@ launcher.launch(intent)
intent.putExtra("type", "nip04_decrypt")
// to control the result in your application in case you are not waiting the result before sending another intent
intent.putExtra("id", "some_id")
// Send the current logged in user npub
intent.putExtra("current_user", account.keyPair.pubKey.toNpub())
// Send the hex pubKey that will be used for decrypting the data
intent.putExtra("pubKey", pubKey)
// Send the current logged in user pubkey
intent.putExtra("current_user", account.keyPair.pubkey)
// Send the hex pubkey that will be used for decrypting the data
intent.putExtra("pubkey", pubkey)
context.startActivity(intent)
```
- result:
- If the user approved intent it will return the **signature** and **id** fields
- If the user approved intent it will return the **result** and **id** fields
```kotlin
val plainText = intent.data?.getStringExtra("signature")
val plainText = intent.data?.getStringExtra("result")
// the id you sent
val id = intent.data?.getStringExtra("id")
```
- **get_relays**
- params:
```kotlin
val intent = Intent(Intent.ACTION_VIEW, Uri.parse("nostrsigner:"))
intent.`package` = "com.example.signer"
intent.putExtra("type", "get_relays")
// to control the result in your application in case you are not waiting the result before sending another intent
intent.putExtra("id", "some_id")
// Send the current logged in user pubkey
intent.putExtra("current_user", account.keyPair.pubkey)
context.startActivity(intent)
```
- result:
- If the user approved intent it will return the **result** and **id** fields
```kotlin
val relayJsonText = intent.data?.getStringExtra("result")
// the id you sent
val id = intent.data?.getStringExtra("id")
```
@ -242,15 +265,15 @@ launcher.launch(intent)
intent.putExtra("type", "decrypt_zap_event")
// to control the result in your application in case you are not waiting the result before sending another intent
intent.putExtra("id", "some_id")
// Send the current logged in user npub
intent.putExtra("current_user", account.keyPair.pubKey.toNpub())
// Send the current logged in user pubkey
intent.putExtra("current_user", account.keyPair.pubkey)
context.startActivity(intent)
```
- result:
- If the user approved intent it will return the **signature** and **id** fields
- If the user approved intent it will return the **result** and **id** fields
```kotlin
val eventJson = intent.data?.getStringExtra("signature")
val eventJson = intent.data?.getStringExtra("result")
// the id you sent
val id = intent.data?.getStringExtra("id")
```
@ -259,11 +282,11 @@ launcher.launch(intent)
To get the result back from Signer Application you should use contentResolver.query in Kotlin. If you are using another framework check the documentation of your framework or a third party library to get the result.
If the user did not check the "remember my choice" option, the npub is not in Signer Application or the signer type is not recognized the `contentResolver` will return null
If the user did not check the "remember my choice" option, the pubkey is not in Signer Application or the signer type is not recognized the `contentResolver` will return null
For the SIGN_EVENT type Signer Application returns two columns "signature" and "event". The column event is the signed event json
For the SIGN_EVENT type Signer Application returns two columns "result" and "event". The column event is the signed event json
For the other types Signer Application returns the column "signature"
For the other types Signer Application returns the column "result"
If the user chose to always reject the event, signer application will return the column "rejected" and you should not open signer application
@ -282,15 +305,15 @@ If the user chose to always reject the event, signer application will return the
)
```
- result:
- Will return the **npub** in the signature column
- Will return the **pubkey** in the result column
```kotlin
if (result == null) return
if (result.moveToFirst()) {
val index = it.getColumnIndex("signature")
val index = it.getColumnIndex("result")
if (index < 0) return
val npub = it.getString(index)
val pubkey = it.getString(index)
}
```
@ -300,20 +323,20 @@ If the user chose to always reject the event, signer application will return the
```kotlin
val result = context.contentResolver.query(
Uri.parse("content://com.example.signer.SIGN_EVENT"),
listOf("$eventJson", "", "${logged_in_user_npub}"),
listOf("$eventJson", "", "${logged_in_user_pubkey}"),
null,
null,
null
)
```
- result:
- Will return the **signature** and the **event** columns
- Will return the **result** and the **event** columns
```kotlin
if (result == null) return
if (result.moveToFirst()) {
val index = it.getColumnIndex("signature")
val index = it.getColumnIndex("result")
val indexJson = it.getColumnIndex("event")
val signature = it.getString(index)
val eventJson = it.getString(indexJson)
@ -326,20 +349,20 @@ If the user chose to always reject the event, signer application will return the
```kotlin
val result = context.contentResolver.query(
Uri.parse("content://com.example.signer.NIP04_ENCRYPT"),
listOf("$plainText", "${hex_pub_key}", "${logged_in_user_npub}"),
listOf("$plainText", "${hex_pub_key}", "${logged_in_user_pubkey}"),
null,
null,
null
)
```
- result:
- Will return the **signature** column
- Will return the **result** column
```kotlin
if (result == null) return
if (result.moveToFirst()) {
val index = it.getColumnIndex("signature")
val index = it.getColumnIndex("result")
val encryptedText = it.getString(index)
}
```
@ -350,20 +373,20 @@ If the user chose to always reject the event, signer application will return the
```kotlin
val result = context.contentResolver.query(
Uri.parse("content://com.example.signer.NIP44_ENCRYPT"),
listOf("$plainText", "${hex_pub_key}", "${logged_in_user_npub}"),
listOf("$plainText", "${hex_pub_key}", "${logged_in_user_pubkey}"),
null,
null,
null
)
```
- result:
- Will return the **signature** column
- Will return the **result** column
```kotlin
if (result == null) return
if (result.moveToFirst()) {
val index = it.getColumnIndex("signature")
val index = it.getColumnIndex("result")
val encryptedText = it.getString(index)
}
```
@ -374,20 +397,20 @@ If the user chose to always reject the event, signer application will return the
```kotlin
val result = context.contentResolver.query(
Uri.parse("content://com.example.signer.NIP04_DECRYPT"),
listOf("$encryptedText", "${hex_pub_key}", "${logged_in_user_npub}"),
listOf("$encryptedText", "${hex_pub_key}", "${logged_in_user_pubkey}"),
null,
null,
null
)
```
- result:
- Will return the **signature** column
- Will return the **result** column
```kotlin
if (result == null) return
if (result.moveToFirst()) {
val index = it.getColumnIndex("signature")
val index = it.getColumnIndex("result")
val encryptedText = it.getString(index)
}
```
@ -398,44 +421,68 @@ If the user chose to always reject the event, signer application will return the
```kotlin
val result = context.contentResolver.query(
Uri.parse("content://com.example.signer.NIP44_DECRYPT"),
listOf("$encryptedText", "${hex_pub_key}", "${logged_in_user_npub}"),
listOf("$encryptedText", "${hex_pub_key}", "${logged_in_user_pubkey}"),
null,
null,
null
)
```
- result:
- Will return the **signature** column
- Will return the **result** column
```kotlin
if (result == null) return
if (result.moveToFirst()) {
val index = it.getColumnIndex("signature")
val index = it.getColumnIndex("result")
val encryptedText = it.getString(index)
}
```
- **get_relays**
- params:
```kotlin
val result = context.contentResolver.query(
Uri.parse("content://com.example.signer.GET_RELAYS"),
listOf("${logged_in_user_pubkey}"),
null,
null,
null
)
```
- result:
- Will return the **result** column
```kotlin
if (result == null) return
if (result.moveToFirst()) {
val index = it.getColumnIndex("result")
val relayJsonText = it.getString(index)
}
```
- **decrypt_zap_event**
- params:
```kotlin
val result = context.contentResolver.query(
Uri.parse("content://com.example.signer.DECRYPT_ZAP_EVENT"),
listOf("$eventJson", "", "${logged_in_user_npub}"),
listOf("$eventJson", "", "${logged_in_user_pubkey}"),
null,
null,
null
)
```
- result:
- Will return the **signature** column
- Will return the **result** column
```kotlin
if (result == null) return
if (result.moveToFirst()) {
val index = it.getColumnIndex("signature")
val index = it.getColumnIndex("result")
val eventJson = it.getString(index)
}
```
@ -472,28 +519,35 @@ Android intents and browser urls have limitations, so if you are using the `retu
- params:
```js
window.href = `nostrsigner:${plainText}?pubKey=${hex_pub_key}&compressionType=none&returnType=signature&type=nip04_encrypt&callbackUrl=https://example.com/?event=`;
window.href = `nostrsigner:${plainText}?pubkey=${hex_pub_key}&compressionType=none&returnType=signature&type=nip04_encrypt&callbackUrl=https://example.com/?event=`;
```
- **nip44_encrypt**
- params:
```js
window.href = `nostrsigner:${plainText}?pubKey=${hex_pub_key}&compressionType=none&returnType=signature&type=nip44_encrypt&callbackUrl=https://example.com/?event=`;
window.href = `nostrsigner:${plainText}?pubkey=${hex_pub_key}&compressionType=none&returnType=signature&type=nip44_encrypt&callbackUrl=https://example.com/?event=`;
```
- **nip04_decrypt**
- params:
```js
window.href = `nostrsigner:${encryptedText}?pubKey=${hex_pub_key}&compressionType=none&returnType=signature&type=nip04_decrypt&callbackUrl=https://example.com/?event=`;
window.href = `nostrsigner:${encryptedText}?pubkey=${hex_pub_key}&compressionType=none&returnType=signature&type=nip04_decrypt&callbackUrl=https://example.com/?event=`;
```
- **nip44_decrypt**
- params:
```js
window.href = `nostrsigner:${encryptedText}?pubKey=${hex_pub_key}&compressionType=none&returnType=signature&type=nip44_decrypt&callbackUrl=https://example.com/?event=`;
window.href = `nostrsigner:${encryptedText}?pubkey=${hex_pub_key}&compressionType=none&returnType=signature&type=nip44_decrypt&callbackUrl=https://example.com/?event=`;
```
- **get_relays**
- params:
```js
window.href = `nostrsigner:?compressionType=none&returnType=signature&type=get_relays&callbackUrl=https://example.com/?event=`;
```
- **decrypt_zap_event**

3
58.md
View File

@ -13,8 +13,7 @@ user profiles:
2. A "Badge Award" event is a kind `8` event with a single `a` tag referencing a "Badge Definition" event and one or more `p` tags, one for each pubkey the badge issuer wishes to award. 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`.
3. A "Profile Badges" event is defined as an _addressable 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

205
60.md Normal file
View File

@ -0,0 +1,205 @@
# NIP-60
## Cashu Wallet
`draft` `optional`
This NIP defines the operations of a cashu-based wallet.
A cashu wallet is a wallet which information is stored in relays to make it accessible across applications.
The purpose of this NIP is:
* ease-of-use: new users immediately are able to receive funds without creating accounts with other services.
* interoperability: users' wallets follows them across applications.
This NIP doesn't deal with users' *receiving* money from someone else, it's just to keep state of the user's wallet.
# High-level flow
1. A user has a `kind:37375` event that represents a wallet.
2. A user has `kind:7375` events that represent the unspent proofs of the wallet. -- The proofs are encrypted with the user's private key.
3. A user has `kind:7376` events that represent the spending history of the wallet -- This history is for informational purposes only and is completely optional.
## Wallet Event
```jsonc
{
"kind": 37375,
"content": nip44_encrypt([
[ "balance", "100", "sat" ],
[ "privkey", "hexkey" ] // explained in NIP-61
]),
"tags": [
[ "d", "my-wallet" ],
[ "mint", "https://mint1" ],
[ "mint", "https://mint2" ],
[ "mint", "https://mint3" ],
[ "name", "my shitposting wallet" ],
[ "unit", "sat" ],
[ "description", "a wallet for my day-to-day shitposting" ],
[ "relay", "wss://relay1" ],
[ "relay", "wss://relay2" ],
]
}
```
The wallet event is a parameterized replaceable event `kind:37375`.
Tags:
* `d` - wallet ID.
* `mint` - Mint(s) this wallet uses -- there MUST be one or more mint tags.
* `relay` - Relays where the wallet and related events can be found. -- one ore more relays SHOULD be specified. If missing, clients should follow [[NIP-65]].
* `unit` - Base unit of the wallet (e.g. "sat", "usd", etc).
* `name` - Optional human-readable name for the wallet.
* `description` - Optional human-readable description of the wallet.
* `balance` - Optional best-effort balance of the wallet that can serve as a placeholder while an accurate balance is computed from fetching all unspent proofs.
* `privkey` - Private key used to unlock P2PK ecash. MUST be stored encrypted in the `.content` field. **This is a different private key exclusively used for the wallet, not associated in any way to the user's nostr private key** -- This is only used when receiving funds from others, described in NIP-61.
Any tag, other than the `d` tag, can be [[NIP-44]] encrypted into the `.content` field.
### Deleting a wallet event
Due to PRE being hard to delete, if a user wants to delete a wallet, they should empty the event and keep just the `d` identifier and add a `deleted` tag.
## Token Event
Token events are used to record the unspent proofs that come from the mint.
There can be multiple `kind:7375` events for the same mint, and multiple proofs inside each `kind:7375` event.
```jsonc
{
"kind": 7375,
"content": nip44_encrypt({
"mint": "https://stablenut.umint.cash",
"proofs": [
{
"id": "005c2502034d4f12",
"amount": 1,
"secret": "z+zyxAVLRqN9lEjxuNPSyRJzEstbl69Jc1vtimvtkPg=",
"C": "0241d98a8197ef238a192d47edf191a9de78b657308937b4f7dd0aa53beae72c46"
}
]
}),
"tags": [
[ "a", "37375:<pubkey>:my-wallet" ]
]
}
```
`.content` is a [[NIP-44]] encrypted payload storing the mint and the unencoded proofs.
* `a` an optional tag linking the token to a specific wallet.
### Spending proofs
When one or more proofs of a token are spent, the token event should be [[NIP-09]]-deleted and, if some proofs are unspent from the same token event, a new token event should be created rolling over the unspent proofs and adding any change outputs to the new token event.
## Spending History Event
Clients SHOULD publish `kind:7376` events to create a transaction history when their balance changes.
```jsonc
{
"kind": 7376,
"content": nip44_encrypt([
[ "direction", "in" ], // in = received, out = sent
[ "amount", "1", "sat" ],
[ "e", "<event-id-of-spent-token>", "<relay-hint>", "created" ],
]),
"tags": [
[ "a", "37375:<pubkey>:my-wallet" ],
]
}
```
* `direction` - The direction of the transaction; `in` for received funds, `out` for sent funds.
* `a` - The wallet the transaction is related to.
Clients MUST add `e` tags to create references of destroyed and created token events along with the marker of the meaning of the tag:
* `created` - A new token event was created.
* `destroyed` - A token event was destroyed.
* `redeemed` - A [[NIP-61]] nutzap was redeemed.
All tags can be [[NIP-44]] encrypted. Clients SHOULD leave `e` tags with a `redeemed` marker unencrypted.
Multiple `e` tags can be added to a `kind:7376` event.
# Flow
A client that wants to check for user's wallets information starts by fetching `kind:10019` events from the user's relays, if no event is found, it should fall back to using the user's [[NIP-65]] relays.
## Fetch wallet and token list
From those relays, the client should fetch wallet and token events.
`"kinds": [37375, 7375], "authors": ["<my-pubkey>"]`
## Fetch proofs
While the client is fetching (and perhaps validating) proofs it can use the optional `balance` tag of the wallet event to display a estimate of the balance of the wallet.
## Spending token
If Alice spends 4 sats from this token event
```jsonconc
{
"kind": 7375,
"id": "event-id-1",
"content": nip44_encrypt({
"mint": "https://stablenut.umint.cash",
"proofs": [
{ "id": "1", "amount": 1 },
{ "id": "2", "amount": 2 },
{ "id": "3", "amount": 4 },
{ "id": "4", "amount": 8 },
]
}),
"tags": [
[ "a", "37375:<pubkey>:my-wallet" ]
]
}
```
Her client:
* MUST roll over the unspent proofs:
```jsonconc
{
"kind": 7375,
"id": "event-id-2",
"content": nip44_encrypt({
"mint": "https://stablenut.umint.cash",
"proofs": [
{ "id": "1", "amount": 1 },
{ "id": "2", "amount": 2 },
{ "id": "8", "amount": 8 },
]
}),
"tags": [
[ "a", "37375:<pubkey>:my-wallet" ]
]
}
```
* MUST delete event `event-id-1`
* SHOULD create a `kind:7376` event to record the spend
```jsonconc
{
"kind": 7376,
"content": nip44_encrypt([
[ "direction", "out" ],
[ "amount", "4", "sats" ],
[ "e", "<event-id-1>", "<relay-hint>", "destroyed" ],
[ "e", "<event-id-2>", "<relay-hint>", "created" ],
]),
"tags": [
[ "a", "37375:<pubkey>:my-wallet" ],
]
}
```
## Redeeming a quote (optional)
When creating a quote at a mint, an event can be used to keep the state of the quote ID, which will be used to check when the quote has been paid. These events should be created with an expiration tag [[NIP-40]] matching the expiration of the bolt11 received from the mint; this signals to relays when they can safely discard these events.
Application developers are encouraged to use local state when possible and only publish this event when it makes sense in the context of their application.
```jsonc
{
"kind": 7374,
"content": nip44_encrypt("quote-id"),
"tags": [
[ "expiration", "<expiration-timestamp>" ],
[ "mint", "<mint-url>" ],
[ "a", "37375:<pubkey>:my-wallet" ]
]
}
```
## Appendix 1: Validating proofs
Clients can optionally validate proofs to make sure they are not working from an old state; this logic is left up to particular implementations to decide when and why to do it, but if some proofs are checked and deemed to have been spent, the client should delete the token and roll over any unspent proof.

132
61.md Normal file
View File

@ -0,0 +1,132 @@
# NIP-61:
## Nut Zaps
A Nut Zap is a P2PK cashu token where the payment itself is the receipt.
# High-level flow
Alice wants to nutzap 1 sat to Bob because of an event `event-id-1` she liked.
## Alice nutzaps Bob
1. Alice fetches event `kind:10019` from Bob to see the mints Bob trusts.
2. She mints a token at that mint (or swaps some tokens she already had in that mint) p2pk-locked to the pubkey Bob has listed in his `kind:10019`.
3. She publishes a `kind:9321` event to the relays Bob indicated with the proofs she minted.
## Bob receives the nutzap
1. At some point, Bob's client fetches `kind:9321` events p-tagging him from his relays.
2. Bob's client swaps the token into his wallet.
# Nutzap informational event
```jsonc
{
"kind": 10019,
"tags": [
[ "relay", "wss://relay1" ],
[ "relay", "wss://relay2" ],
[ "mint", "https://mint1", "usd", "sat" ],
[ "mint", "https://mint2", "sat" ],
[ "pubkey", "<p2pk-pubkey>" ]
]
}
```
`kind:10019` is an event that is useful for others to know how to send money to the user.
* `relay` - Relays where the user will be reading token events from. If a user wants to send money to the user, they should write to these relays.
* `mint` - Mints the user is explicitly agreeing to use to receive funds on. Clients SHOULD not send money on mints not listed here or risk burning their money. Additional markers can be used to list the supported base units of the mint.
* `pubkey` - Pubkey that SHOULD be used to P2PK-lock receiving nutzaps. If not present, clients SHOULD use the pubkey of the recipient. This is explained in Appendix 1.
## Nutzap event
Event `kind:9321` is a nutzap event published by the sender, p-tagging the recipient. The outputs are P2PK-locked to the pubkey the recipient indicated in their `kind:10019` event or to the recipient pubkey if the `kind:10019` event doesn't have a explicit pubkey.
Clients MUST prefix the pubkey they p2pk-lock with `"02"` (for nostr<>cashu pubkey compatibility).
```jsonc
{
kind: 9321,
content: "Thanks for this great idea.",
pubkey: "sender-pubkey",
tags: [
[ "amount", "1" ],
[ "unit", "sat" ],
[ "proof", "{\"amount\":1,\"C\":\"02277c66191736eb72fce9d975d08e3191f8f96afb73ab1eec37e4465683066d3f\",\"id\":\"000a93d6f8a1d2c4\",\"secret\":\"[\\\"P2PK\\\",{\\\"nonce\\\":\\\"b00bdd0467b0090a25bdf2d2f0d45ac4e355c482c1418350f273a04fedaaee83\\\",\\\"data\\\":\\\"02eaee8939e3565e48cc62967e2fde9d8e2a4b3ec0081f29eceff5c64ef10ac1ed\\\"}]\"}" ],
[ "u", "https://stablenut.umint.cash", ],
[ "e", "<zapped-event-id>", "<relay-hint>" ],
[ "p", "e9fbced3a42dcf551486650cc752ab354347dd413b307484e4fd1818ab53f991" ], // recipient of nut zap
]
}
```
* `.content` is an optional comment for the nutzap
* `amount` is a shorthand for the combined amount of all outputs. -- Clients SHOULD validate that the sum of the amounts in the outputs matches.
* `unit` is the base unit of the amount.
* `proof` is one ore more proofs p2pk-locked to the pubkey the recipient specified in their `kind:10019` event.
* `u` is the mint the URL of the mint EXACTLY as specified by the recipient's `kind:10019`.
* `e` zero or one event that is being nutzapped.
* `p` exactly one pubkey, specifying the recipient of the nutzap.
WIP: Clients SHOULD embed a DLEQ proof in the nutzap event to make it possible to verify nutzaps without talking to the mint.
# Sending a nutzap
* The sender fetches the recipient's `kind:10019`.
* The sender mints/swaps ecash on one of the recipient's listed mints.
* The sender p2pk locks to the recipient's specified pubkey in their
# Receiving nutzaps
Clients should REQ for nut zaps:
* Filtering with `#u` for mints they expect to receive ecash from.
* this is to prevent even interacting with mints the user hasn't explicitly signaled.
* Filtering with `since` of the most recent `kind:7376` event the same user has created.
* this can be used as a marker of the nut zaps that have already been swaped by the user -- clients might choose to use other kinds of markers, including internal state -- this is just a guidance of one possible approach.
Clients MIGHT choose to use some kind of filtering (e.g. WoT) to ignore spam.
`{ "kinds": [9321], "#p": "my-pubkey", "#u": [ "<mint-1>", "<mint-2>"], "since": <latest-created_at-of-kind-7376> }`.
Upon receiving a new nut zap, the client should swap the tokens into a wallet the user controls, either a [[NIP-60]] wallet, their own LN wallet or anything else.
## Updating nutzap-redemption history
When claiming a token the client SHOULD create a `kind:7376` event and `e` tag the original nut zap event. This is to record that this token has already been claimed (and shouldn't be attempted again) and as signaling to the recipient that the ecash has been redeemed.
Multiple `kind:9321` events can be tagged in the same `kind:7376` event.
```jsonc
{
"kind": 7376,
"content": nip44_encrypt([
[ "direction", "in" ], // in = received, out = sent
[ "amount", "1", "sat" ],
[ "e", "<7375-event-id>", "relay-hint", "created" ] // new token event that was created
]),
"tags": [
[ "a", "37375:<pubkey>:my-wallet" ], // an optional wallet tag
[ "e", "<9321-event-id>", "relay-hint", "redeemed" ], // nutzap event that has been redeemed
[ "p", "sender-pubkey" ] // pubkey of the author of the 9321 event (nutzap sender)
]
}
```
Events that redeem a nutzap SHOULD be published to the sender's [[NIP-65]] relays.
## Verifying a Cashu Zap
* Clients SHOULD check that the receiving user has issued a `kind:10019` tagging the mint where the cashu has been minted.
* Clients SHOULD check that the token is locked to the pubkey the user has listed in their `kind:10019`.
## Final Considerations
1. Clients SHOULD guide their users to use NUT-11 (P2PK) compatible-mints in their `kind:10019` event to avoid receiving nut zaps anyone can spend
2. Clients SHOULD normalize and deduplicate mint URLs as described in NIP-65.
3. A nut zap MUST be sent to a mint the recipient has listed in their `kind:10019` event or to the NIP-65 relays of the recipient, failure to do so may result in the recipient donating the tokens to the mint since the recipient might never see the event.
## Appendix 1: Alternative P2PK pubkey
Clients might not have access to the user's private key (i.e. NIP-07, NIP-46 signing) and, as such, the private key to sign cashu spends might not be available, which would make spending the P2PK incoming nutzaps impossible.
For this scenarios clients can:
* add a `pubkey` tag to the `kind:10019` (indicating which pubkey senders should P2PK to)
* store the private key in the `kind:37375` event in the nip44-encrypted `content` field.
This is to avoid depending on NIP-07/46 adaptations to sign cashu payloads.

119
71.md
View File

@ -16,25 +16,64 @@ There are two types of video events represented by different kinds: horizontal a
#### Format
The format uses a parameterized replaceable event kind `34235` for horizontal videos and `34236` for vertical videos.
The format uses an _addressable event_ kind `34235` for horizontal videos and `34236` for vertical videos.
The `.content` of these events is a summary or description on the video content.
The list of tags are as follows:
* `d` (required) universally unique identifier (UUID). Generated by the client creating the video event.
* `url` (required) the url to the video file
* `m` a string indicating the data type of the file. The [MIME types](https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types/Common_types) format must be used, and they should be lowercase.
The primary source of video information is the `imeta` tags which is defined in [NIP-92](92.md)
Each `imeta` tag can be used to specify a variant of the video by the `dim` & `m` properties.
Example:
```json
[
["imeta",
"dim 1920x1080",
"url https://myvideo.com/1080/12345.mp4",
"x 3093509d1e0bc604ff60cb9286f4cd7c781553bc8991937befaacfdc28ec5cdc",
"m video/mp4",
"image https://myvideo.com/1080/12345.jpg",
"image https://myotherserver.com/1080/12345.jpg",
"fallback https://myotherserver.com/1080/12345.mp4",
"fallback https://andanotherserver.com/1080/12345.mp4",
"service nip96",
],
["imeta",
"dim 1280x720",
"url https://myvideo.com/720/12345.mp4",
"x e1d4f808dae475ed32fb23ce52ef8ac82e3cc760702fca10d62d382d2da3697d",
"m video/mp4",
"image https://myvideo.com/720/12345.jpg",
"image https://myotherserver.com/720/12345.jpg",
"fallback https://myotherserver.com/720/12345.mp4",
"fallback https://andanotherserver.com/720/12345.mp4",
"service nip96",
],
["imeta",
"dim 1280x720",
"url https://myvideo.com/720/12345.m3u8",
"x 704e720af2697f5d6a198ad377789d462054b6e8d790f8a3903afbc1e044014f",
"m application/x-mpegURL",
"image https://myvideo.com/720/12345.jpg",
"image https://myotherserver.com/720/12345.jpg",
"fallback https://myotherserver.com/720/12345.m3u8",
"fallback https://andanotherserver.com/720/12345.m3u8",
"service nip96",
],
]
```
Where `url` is the primary server url and `fallback` are other servers hosting the same file, both `url` and `fallback` should be weighted equally and clients are recommended to use any of the provided video urls.
The `image` tag contains a preview image (at the same resolution). Multiple `image` tags may be used to specify fallback copies in the same way `fallback` is used for `url`.
Additionally `service nip96` may be included to allow clients to search the authors NIP-96 server list to find the file using the hash.
### Other tags:
* `title` (required) title of the video
* `"published_at"`, for the timestamp in unix seconds (stringified) of the first time the video was published
* `x` containing the SHA-256 hexencoded string of the file.
* `size` (optional) size of file in bytes
* `dim` (optional) size of file in pixels in the form `<width>x<height>`
* `published_at`, for the timestamp in unix seconds (stringified) of the first time the video was published
* `duration` (optional) video duration in seconds
* `magnet` (optional) URI to magnet file
* `i` (optional) torrent infohash
* `text-track` (optional, repeated) link to WebVTT file for video, type of supplementary information (captions/subtitles/chapters/metadata), optional language code
* `thumb` (optional) url of thumbnail with same aspect ratio
* `image` (optional) url of preview image with same dimensions
* `content-warning` (optional) warning about content of NSFW video
* `alt` (optional) description for accessibility
* `segment` (optional, repeated) start timestamp in format `HH:MM:SS.sss`, end timestamp in format `HH:MM:SS.sss`, chapter/segment title, chapter thumbnail-url
@ -53,19 +92,23 @@ The list of tags are as follows:
["d", "<UUID>"],
["title", "<title of video>"],
["thumb", "<thumbnail image for video>"],
["published_at", "<unix timestamp>"],
["alt", <description>],
// Video Data
["url",<string with URI of file>],
["m", <MIME type>],
["x",<Hash SHA-256>],
["size", <size of file in bytes>],
["imeta",
"dim 1920x1080",
"url https://myvideo.com/1080/12345.mp4",
"x 3093509d1e0bc604ff60cb9286f4cd7c781553bc8991937befaacfdc28ec5cdc",
"m video/mp4",
"image https://myvideo.com/1080/12345.jpg",
"image https://myotherserver.com/1080/12345.jpg",
"fallback https://myotherserver.com/1080/12345.mp4",
"fallback https://andanotherserver.com/1080/12345.mp4",
"service nip96",
],
["duration", <duration of video in seconds>],
["dim", <size of file in pixels>],
["magnet",<magnet URI> ],
["i",<torrent infohash>],
["text-track", "<encoded `kind 6000` event>", "<recommended relay urls>"],
["content-warning", "<reason>"],
["segment", <start>, <end>, "<title>", "<thumbnail URL>"],
@ -83,36 +126,4 @@ The list of tags are as follows:
["r", "<url>"]
]
}
```
## Video View
A video event view is a response to a video event to track a user's view or progress viewing the video.
### Format
The format uses a parameterized replaceable event kind `34237`.
The `.content` of these events is optional and could be a free-form note that acts like a bookmark for the user.
The list of tags are as follows:
* `a` (required) reference tag to kind `34235` or `34236` video event being viewed
* `d` (required) same as `a` reference tag value
* `viewed` (optional, repeated) timestamp of the user's start time in seconds, timestamp of the user's end time in seconds
```json
{
"id": <32-bytes lowercase hex-encoded SHA-256 of the the serialized event data>,
"pubkey": <32-bytes lowercase hex-encoded public key of the event creator>,
"created_at": <Unix timestamp in seconds>,
"kind": 34237,
"content": "<note>",
"tags": [
["a", "<34235 | 34236>:<video event author pubkey>:<d-identifier of video event>", "<optional relay url>"],
["e", "<event-id", "<relay-url>"]
["d", "<34235 | 34236>:<video event author pubkey>:<d-identifier of video event>"],
["viewed", <start>, <end>],
]
}
```
```

24
73.md
View File

@ -6,17 +6,29 @@ External Content IDs
`draft` `optional`
There are certain established global content identifiers that would be useful to reference in nostr events so that clients can query all events assosiated with these ids.
There are certain established global content identifiers such as [Book ISBNs](https://en.wikipedia.org/wiki/ISBN), [Podcast GUIDs](https://podcastnamespace.org/tag/guid), and [Movie ISANs](https://en.wikipedia.org/wiki/International_Standard_Audiovisual_Number) that are useful to reference in nostr events so that clients can query all the events assosiated with these ids.
- Book [ISBNs](https://en.wikipedia.org/wiki/ISBN)
- Podcast [GUIDs](https://podcastnamespace.org/tag/guid)
- Movie [ISANs](https://en.wikipedia.org/wiki/International_Standard_Audiovisual_Number)
Since the `i` tag is already used for similar references in kind-0 metadata events it makes sense to use it for these content ids as well.
`i` tags are used for referencing these external content ids, with `k` tags representing the external content id kind so that clients can query all the events for a specific kind.
## Supported IDs
| Type | `i` tag | `k` tag |
|- | - | - |
| URLs | "`<URL, normalized, no fragment>`" | "`<scheme-host, normalized>`" |
| Hashtags | "#`<topic, lowercase>`" | "#" |
| Geohashes| "geo:`<geohash, lowercase>`" | "geo" |
| Books | "isbn:`<id, without hyphens>`" | "isbn" |
| Podcast Feeds | "podcast:guid:`<guid>`" | "podcast:guid" |
| Podcast Episodes | "podcast:item:guid:`<guid>`" | "podcast:item:guid" |
| Podcast Publishers | "podcast:publisher:guid:`<guid>`" | "podcast:publisher:guid" |
| Movies | "isan:`<id, without version part>`" | "isan" |
| Papers | "doi:`<id, lowercase>`" | "doi" |
---
## Examples
### Books:
- Book ISBN: `["i", "isbn:9780765382030"]` - https://isbnsearch.org/isbn/9780765382030

2
75.md
View File

@ -77,7 +77,7 @@ Clients MAY display funding goals on user profiles.
When zapping a goal event, clients MUST include the relays in the `relays` tag of the goal event in the zap request `relays` tag.
When zapping a parameterized replaceable event with a `goal` tag, clients SHOULD tag the goal event id in the `e` tag of the zap request.
When zapping an addressable event with a `goal` tag, clients SHOULD tag the goal event id in the `e` tag of the zap request.
## Use cases

13
94.md
View File

@ -26,6 +26,7 @@ This NIP specifies the use of the `1063` event type, having in `content` a descr
* `summary` (optional) text excerpt
* `alt` (optional) description for accessibility
* `fallback` (optional) zero or more fallback file sources in case `url` fails
* `service` (optional) service type which is serving the file (eg. [NIP-96](96.md))
```jsonc
{
@ -33,15 +34,15 @@ This NIP specifies the use of the `1063` event type, having in `content` a descr
"tags": [
["url",<string with URI of file>],
["m", <MIME type>],
["x",<Hash SHA-256>],
["ox",<Hash SHA-256>],
["x", <Hash SHA-256>],
["ox", <Hash SHA-256>],
["size", <size of file in bytes>],
["dim", <size of file in pixels>],
["magnet",<magnet URI> ],
["i",<torrent infohash>],
["magnet", <magnet URI> ],
["i", <torrent infohash>],
["blurhash", <value>],
["thumb", <string with thumbnail URI>],
["image", <string with preview URI>],
["thumb", <string with thumbnail URI>, <Hash SHA-256>],
["image", <string with preview URI>, <Hash SHA-256>],
["summary", <excerpt>],
["alt", <description>]
],

2
99.md
View File

@ -26,7 +26,7 @@ The `.pubkey` field of these events are treated as the party creating the listin
### Metadata
- For "tags"/"hashtags" (i.e. categories or keywords of relevance for the listing) the `"t"` event tag should be used, as per [NIP-12](12.md).
- For "tags"/"hashtags" (i.e. categories or keywords of relevance for the listing) the `"t"` event tag should be used.
- For images, whether included in the markdown content or not, clients SHOULD use `image` tags as described in [NIP-58](58.md). This allows clients to display images in carousel format more easily.
The following tags, used for structured metadata, are standardized and SHOULD be included. Other tags may be added as necessary.

View File

@ -5,6 +5,9 @@ reverse chronological order.
| Date | Commit | NIP | Change |
| ----------- | --------- | -------- | ------ |
| 2024-10-15 | [1cda2dcc](https://github.com/nostr-protocol/nips/commit/1cda2dcc) | [NIP-71](71.md) | some tags were replaced with `imeta` tag |
| 2024-10-15 | [1cda2dcc](https://github.com/nostr-protocol/nips/commit/1cda2dcc) | [NIP-71](71.md) | `kind: 34237` was dropped |
| 2024-10-07 | [7bb8997b](https://github.com/nostr-protocol/nips/commit/7bb8997b) | [NIP-55](55.md) | some fields and passing data were changed |
| 2024-08-18 | [3aff37bd](https://github.com/nostr-protocol/nips/commit/3aff37bd) | [NIP-54](54.md) | content should be Asciidoc |
| 2024-07-31 | [3ea2f1a4](https://github.com/nostr-protocol/nips/commit/3ea2f1a4) | [NIP-45](45.md) | [444ad28d](https://github.com/nostr-protocol/nips/commit/444ad28d) was reverted |
| 2024-07-30 | [444ad28d](https://github.com/nostr-protocol/nips/commit/444ad28d) | [NIP-45](45.md) | NIP-45 was deprecated |

113
README.md
View File

@ -73,6 +73,8 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
- [NIP-57: Lightning Zaps](57.md)
- [NIP-58: Badges](58.md)
- [NIP-59: Gift Wrap](59.md)
- [NIP-60: Cashu Wallet](60.md)
- [NIP-61: Nutzaps](61.md)
- [NIP-64: Chess (PGN)](64.md)
- [NIP-65: Relay List Metadata](65.md)
- [NIP-70: Protected Events](70.md)
@ -140,8 +142,12 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
| `5000`-`5999` | Job Request | [90](90.md) |
| `6000`-`6999` | Job Result | [90](90.md) |
| `7000` | Job Feedback | [90](90.md) |
| `7374` | Reserved Cashu Wallet Tokens | [60](60.md) |
| `7375` | Cashu Wallet Tokens | [60](60.md) |
| `7376` | Cashu Wallet History | [60](60.md) |
| `9000`-`9030` | Group Control Events | [29](29.md) |
| `9041` | Zap Goal | [75](75.md) |
| `9321` | Nutzap | [61](61.md) |
| `9467` | Tidal login | [Tidal-nostr] |
| `9734` | Zap Request | [57](57.md) |
| `9735` | Zap | [57](57.md) |
@ -156,6 +162,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
| `10007` | Search relays list | [51](51.md) |
| `10009` | User groups | [51](51.md), [29](29.md) |
| `10015` | Interests list | [51](51.md) |
| `10019` | Nutzap Mint Recommendation | [61](61.md) |
| `10030` | User emoji list | [51](51.md) |
| `10050` | Relay list to receive DMs | [51](51.md), [17](17.md) |
| `10063` | User server list | [Blossom][blossom] |
@ -191,12 +198,14 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
| `30078` | Application-specific Data | [78](78.md) |
| `30311` | Live Event | [53](53.md) |
| `30315` | User Statuses | [38](38.md) |
| `30388` | Slide Set | [Corny Chat][cornychat-slideset] |
| `30402` | Classified Listing | [99](99.md) |
| `30403` | Draft Classified Listing | [99](99.md) |
| `30617` | Repository announcements | [34](34.md) |
| `30618` | Repository state announcements | [34](34.md) |
| `30818` | Wiki article | [54](54.md) |
| `30819` | Redirects | [54](54.md) |
| `31388` | Link Set | [Corny Chat][cornychat-linkset] |
| `31890` | Feed | [NUD: Custom Feeds][NUD: Custom Feeds] |
| `31922` | Date-Based Calendar Event | [52](52.md) |
| `31923` | Time-Based Calendar Event | [52](52.md) |
@ -206,13 +215,15 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
| `31990` | Handler information | [89](89.md) |
| `34235` | Video Event | [71](71.md) |
| `34236` | Short-form Portrait Video Event | [71](71.md) |
| `34237` | Video View Event | [71](71.md) |
| `34550` | Community Definition | [72](72.md) |
| `37375` | Cashu Wallet Event | [60](60.md) |
| `39000-9` | Group metadata events | [29](29.md) |
[NUD: Custom Feeds]: https://wikifreedia.xyz/cip-01/
[nostrocket]: https://github.com/nostrocket/NIPS/blob/main/Problems.md
[lnpub]: https://github.com/shocknet/Lightning.Pub/blob/master/proto/autogenerated/client.md
[cornychat-slideset]: https://cornychat.com/datatypes#kind30388slideset
[cornychat-linkset]: https://cornychat.com/datatypes#kind31388linkset
[joinstr]: https://gitlab.com/1440000bytes/joinstr/-/blob/main/NIP.md
[NKBIP-01]: https://wikistr.com/nkbip-01
[NKBIP-02]: https://wikistr.com/nkbip-02
@ -245,56 +256,56 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
## Standardized Tags
| name | value | other parameters | NIP |
| ----------------- | ------------------------------------ | ------------------------------- | ------------------------------------- |
| `e` | event id (hex) | relay URL, marker, pubkey (hex) | [01](01.md), [10](10.md) |
| `p` | pubkey (hex) | relay URL, petname | [01](01.md), [02](02.md) |
| `a` | coordinates to an event | relay URL | [01](01.md) |
| `d` | identifier | -- | [01](01.md) |
| `-` | -- | -- | [70](70.md) |
| `g` | geohash | -- | [52](52.md) |
| `h` | group id | -- | [29](29.md) |
| `i` | external identity | proof, url hint | [39](39.md), [73](73.md) |
| `k` | kind number (string) | -- | [18](18.md), [25](25.md), [72](72.md) |
| `l` | label, label namespace | -- | [32](32.md) |
| `L` | label namespace | -- | [32](32.md) |
| `m` | MIME type | -- | [94](94.md) |
| `q` | event id (hex) | relay URL | [18](18.md) |
| `r` | a reference (URL, etc) | -- | [24](24.md), [25](25.md) |
| `r` | relay url | marker | [65](65.md) |
| `t` | hashtag | -- | [24](24.md), [34](34.md) |
| `alt` | summary | -- | [31](31.md) |
| `amount` | millisatoshis, stringified | -- | [57](57.md) |
| `bolt11` | `bolt11` invoice | -- | [57](57.md) |
| `challenge` | challenge string | -- | [42](42.md) |
| `client` | name, address | relay URL | [89](89.md) |
| `clone` | git clone URL | -- | [34](34.md) |
| `content-warning` | reason | -- | [36](36.md) |
| `delegation` | pubkey, conditions, delegation token | -- | [26](26.md) |
| `description` | description | -- | [34](34.md), [57](57.md), [58](58.md) |
| `emoji` | shortcode, image URL | -- | [30](30.md) |
| `encrypted` | -- | -- | [90](90.md) |
| `expiration` | unix timestamp (string) | -- | [40](40.md) |
| `goal` | event id (hex) | relay URL | [75](75.md) |
| `image` | image URL | dimensions in pixels | [23](23.md), [52](52.md), [58](58.md) |
| `imeta` | inline metadata | -- | [92](92.md) |
| `lnurl` | `bech32` encoded `lnurl` | -- | [57](57.md) |
| `location` | location string | -- | [52](52.md), [99](99.md) |
| `name` | name | -- | [34](34.md), [58](58.md), [72](72.md) |
| `nonce` | random | difficulty | [13](13.md) |
| `preimage` | hash of `bolt11` invoice | -- | [57](57.md) |
| `price` | price | currency, frequency | [99](99.md) |
| `proxy` | external ID | protocol | [48](48.md) |
| `published_at` | unix timestamp (string) | -- | [23](23.md) |
| `relay` | relay url | -- | [42](42.md), [17](17.md) |
| `relays` | relay list | -- | [57](57.md) |
| `server` | file storage server url | -- | [96](96.md) |
| `subject` | subject | -- | [14](14.md), [17](17.md), [34](34.md) |
| `summary` | summary | -- | [23](23.md), [52](52.md) |
| `thumb` | badge thumbnail | dimensions in pixels | [58](58.md) |
| `title` | article title | -- | [23](23.md) |
| `web` | webpage URL | -- | [34](34.md) |
| `zap` | pubkey (hex), relay URL | weight | [57](57.md) |
| name | value | other parameters | NIP |
| ----------------- | ------------------------------------ | ------------------------------- | -------------------------------------------------- |
| `e` | event id (hex) | relay URL, marker, pubkey (hex) | [01](01.md), [10](10.md) |
| `p` | pubkey (hex) | relay URL, petname | [01](01.md), [02](02.md) |
| `a` | coordinates to an event | relay URL | [01](01.md) |
| `d` | identifier | -- | [01](01.md) |
| `-` | -- | -- | [70](70.md) |
| `g` | geohash | -- | [52](52.md) |
| `h` | group id | -- | [29](29.md) |
| `i` | external identity | proof, url hint | [39](39.md), [73](73.md) |
| `k` | kind | -- | [18](18.md), [25](25.md), [72](72.md), [73](73.md) |
| `l` | label, label namespace | -- | [32](32.md) |
| `L` | label namespace | -- | [32](32.md) |
| `m` | MIME type | -- | [94](94.md) |
| `q` | event id (hex) | relay URL, pubkey (hex) | [18](18.md) |
| `r` | a reference (URL, etc) | -- | [24](24.md), [25](25.md) |
| `r` | relay url | marker | [65](65.md) |
| `t` | hashtag | -- | [24](24.md), [34](34.md) |
| `alt` | summary | -- | [31](31.md) |
| `amount` | millisatoshis, stringified | -- | [57](57.md) |
| `bolt11` | `bolt11` invoice | -- | [57](57.md) |
| `challenge` | challenge string | -- | [42](42.md) |
| `client` | name, address | relay URL | [89](89.md) |
| `clone` | git clone URL | -- | [34](34.md) |
| `content-warning` | reason | -- | [36](36.md) |
| `delegation` | pubkey, conditions, delegation token | -- | [26](26.md) |
| `description` | description | -- | [34](34.md), [57](57.md), [58](58.md) |
| `emoji` | shortcode, image URL | -- | [30](30.md) |
| `encrypted` | -- | -- | [90](90.md) |
| `expiration` | unix timestamp (string) | -- | [40](40.md) |
| `goal` | event id (hex) | relay URL | [75](75.md) |
| `image` | image URL | dimensions in pixels | [23](23.md), [52](52.md), [58](58.md) |
| `imeta` | inline metadata | -- | [92](92.md) |
| `lnurl` | `bech32` encoded `lnurl` | -- | [57](57.md) |
| `location` | location string | -- | [52](52.md), [99](99.md) |
| `name` | name | -- | [34](34.md), [58](58.md), [72](72.md) |
| `nonce` | random | difficulty | [13](13.md) |
| `preimage` | hash of `bolt11` invoice | -- | [57](57.md) |
| `price` | price | currency, frequency | [99](99.md) |
| `proxy` | external ID | protocol | [48](48.md) |
| `published_at` | unix timestamp (string) | -- | [23](23.md) |
| `relay` | relay url | -- | [42](42.md), [17](17.md) |
| `relays` | relay list | -- | [57](57.md) |
| `server` | file storage server url | -- | [96](96.md) |
| `subject` | subject | -- | [14](14.md), [17](17.md), [34](34.md) |
| `summary` | summary | -- | [23](23.md), [52](52.md) |
| `thumb` | badge thumbnail | dimensions in pixels | [58](58.md) |
| `title` | article title | -- | [23](23.md) |
| `web` | webpage URL | -- | [34](34.md) |
| `zap` | pubkey (hex), relay URL | weight | [57](57.md) |
Please update these lists when proposing new NIPs.