Compare commits

..

7 Commits

Author SHA1 Message Date
fiatjaf
7b79ab040a nip22: what is an I-tag 2025-02-07 10:56:24 -03:00
Nostr.Band
f1dee4a050 Make description_hash verification optional (#1705) 2025-02-07 12:53:30 +01:00
P. Reis
e286001789 NIP-61: nitpicks (#1754) 2025-02-07 00:28:23 +09:00
Vitor Pamplona
63d1e89f53 Revert "Revert "NIP-01: Adds the author information to e tags (#1749)""
This reverts commit f2e89b130d.
2025-02-05 13:29:07 -03:00
Vitor Pamplona
f2e89b130d Revert "NIP-01: Adds the author information to e tags (#1749)"
This reverts commit 3bbfbb26aa.
2025-02-05 13:25:01 -03:00
Vitor Pamplona
3bbfbb26aa NIP-01: Adds the author information to e tags (#1749) 2025-02-05 13:10:48 -03:00
P. Reis
a0cd05f013 NIP-61: get rid of 'a' tag (#1742) 2025-02-04 22:35:15 -03:00
5 changed files with 7 additions and 12 deletions

2
01.md
View File

@@ -75,7 +75,7 @@ The first element of the tag array is referred to as the tag _name_ or _key_ and
This NIP defines 3 standard tags that can be used across all event kinds with the same meaning. They are as follows:
- 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 `e` tag, used to refer to an event: `["e", <32-bytes lowercase hex of the id of another event>, <recommended relay URL, optional>, <32-bytes lowercase hex of the author's pubkey, optional>]`
- The `p` tag, used to refer to another user: `["p", <32-bytes lowercase hex of a pubkey>, <recommended relay URL, optional>]`
- The `a` tag, used to refer to an addressable or replaceable event
- for an addressable event: `["a", <kind integer>:<32-bytes lowercase hex of a pubkey>:<d tag value>, <recommended relay URL, optional>]`

3
22.md
View File

@@ -6,7 +6,7 @@ Comment
`draft` `optional`
A comment is a threading note always scoped to a root event or an `I`-tag.
A comment is a threading note always scoped to a root event or an [`I`-tag](73.md).
It uses `kind:1111` with plaintext `.content` (no HTML, Markdown, or other formatting).
@@ -198,4 +198,3 @@ A reply to a podcast comment:
// other fields
}
```

2
57.md
View File

@@ -132,7 +132,7 @@ The following should be true of the `zap receipt` event:
- `tags` MUST include the `p` tag (zap recipient) AND optional `e` tag from the `zap request` AND optional `a` tag from the `zap request` AND optional `P` tag from the pubkey of the zap request (zap sender).
- 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 zap request.
- `SHA256(description)` MUST match the description hash in the bolt11 invoice.
- `SHA256(description)` SHOULD 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` 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.

5
60.md
View File

@@ -28,9 +28,7 @@ This NIP doesn't deal with users' *receiving* money from someone else, it's just
"content": nip44_encrypt([
[ "privkey", "hexkey" ],
[ "mint", "https://mint1" ],
[ "mint", "https://mint2" ],
[ "relay", "wss://relay1" ],
[ "relay", "wss://relay2" ]
[ "mint", "https://mint2" ]
]),
"tags": []
}
@@ -41,7 +39,6 @@ The wallet event is an replaceable event `kind:17375`.
Tags:
* `mint` - Mint(s) this wallet uses -- there MUST be one or more mint tags.
* `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 for receiving [NIP-61](61.md) nutzaps.
* `relay` - Relay(s) where wallet events should be published. If present, clients SHOULD publish all wallet-related events (`kind:7375`, `kind:7376`, etc.) to these relays. There MAY be multiple `relay` entries. If no `relay` entries are present, clients SHOULD fall back to using the user's [NIP-65](65.md) relays.
## Token Event
Token events are used to record unspent proofs.

7
61.md
View File

@@ -94,12 +94,11 @@ Multiple `kind:9321` events can be tagged in the same `kind:7376` event.
"content": nip44_encrypt([
[ "direction", "in" ], // in = received, out = sent
[ "amount", "1" ],
[ "e", "<7375-event-id>", "relay-hint", "created" ] // new token event that was created
[ "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)
[ "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)
]
}
```