mirror of
https://github.com/nostr-protocol/nips.git
synced 2024-12-22 00:25:50 -05:00
Rebase and add notification details
This commit is contained in:
parent
298386f0fa
commit
d5e23cf753
21
47.md
21
47.md
|
@ -25,7 +25,7 @@ This NIP describes a way for clients to access a remote lightning wallet through
|
|||
|
||||
4. Once the payment is complete the **wallet service** will send an encrypted `response` (kind 23195) to the **user** over the relay(s) in the URI.
|
||||
|
||||
5. The **wallet service** may send encrypted notifications (kind 23196) of wallet events (such as a received payment) to the **client**.
|
||||
5. The **wallet service** may send encrypted notifications (kind 23197 or 23196) of wallet events (such as a received payment) to the **client**.
|
||||
|
||||
## Events
|
||||
|
||||
|
@ -33,7 +33,7 @@ There are four event kinds:
|
|||
- `NIP-47 info event`: 13194
|
||||
- `NIP-47 request`: 23194
|
||||
- `NIP-47 response`: 23195
|
||||
- `NIP-47 notification event`: 23196
|
||||
- `NIP-47 notification event`: 23197 (23196 in v0)
|
||||
|
||||
### Info Event
|
||||
|
||||
|
@ -115,9 +115,9 @@ If the command was successful, the `error` field must be null.
|
|||
|
||||
### Notification Events
|
||||
|
||||
The notification event SHOULD contain one `p` tag, the public key of the **user**.
|
||||
The notification event is a kind 23197 event (23196 in v0) SHOULD contain one `p` tag, the public key of the **user**.
|
||||
|
||||
The content of notifications is encrypted with [NIP04](https://github.com/nostr-protocol/nips/blob/master/04.md), and is a JSON-RPCish object with a semi-fixed structure:
|
||||
The content of notifications is encrypted with [NIP44](https://github.com/nostr-protocol/nips/blob/master/44.md) (or NIP-04 in v0), and is a JSON-RPCish object with a semi-fixed structure:
|
||||
|
||||
```jsonc
|
||||
{
|
||||
|
@ -128,6 +128,7 @@ The content of notifications is encrypted with [NIP04](https://github.com/nostr-
|
|||
}
|
||||
```
|
||||
|
||||
_Note on backwards-compatibility:_ If a **wallet service** supports both v0 (or no version tag) and v1+ of the protocol, it should publish both notification events for each notification - kind 23196 encrypted with NIP-04 for v0, and kind 23197 encrypted with NIP-44 for v1. It is up to the **client** to decide which event to listen to based on its supported version and declared supported versions of the **wallet service** in the `info` event.
|
||||
|
||||
### Error codes
|
||||
- `RATE_LIMITED`: The client is sending commands too fast. It should retry in a few seconds.
|
||||
|
@ -530,7 +531,7 @@ Versioning for NIP-47 allows the protocol to evolve and even make breaking chang
|
|||
Major version bumps imply breaking changes that are incompatible with the previous major version. Minor version bumps, however, only include non-breaking feature additions or improvements which
|
||||
can maintain full compatibility with the previous minor version.
|
||||
|
||||
**Note:** Version 0.0 or absence of a version specification implies the version of NIP-47 prior to adding the versioning system. This is the protocol as defined at commit hash `e655247`.
|
||||
**Note:** Version 0.0 or absence of a version specification implies the version of NIP-47 prior to adding the versioning system. This is the protocol as defined at commit hash `32b9f3f`.
|
||||
|
||||
Versioning works as follows.
|
||||
|
||||
|
@ -581,13 +582,20 @@ the request event might look like:
|
|||
|
||||
If the **wallet service** does not support the specified version, it will return an `UNSUPPORTED_VERSION` error. Absence of the `v` tag indicates use of version 0.
|
||||
|
||||
### Notification events
|
||||
|
||||
As described above in the [Notifications](#notifications) section, if a **wallet service** supports both v0 and v1+ of the protocol, it should publish two notification events for each notification - kind 23196 encrypted with NIP-04 for v0, and kind 23197 encrypted with NIP-44 for v1. If the **wallet service** only supports v1+, it should only publish kind 23197 events.
|
||||
|
||||
The **client** should check the `v` tag in the `info` event to determine which version of the protocol the **wallet service** supports, and listen to the appropriate notification event. Clients that support both v0 and v1+ can choose to only listen to 23197 events for simplicity.
|
||||
|
||||
### Changelog
|
||||
|
||||
- **0.0**:
|
||||
- Initial version using the protocol as defined at commit hash `e655247`. Uses NIP-04 for encryption.
|
||||
- Initial version using the protocol as defined at commit hash `32b9f3f`. Uses NIP-04 for encryption and kind 23196 for notifications.
|
||||
- **1.0**
|
||||
- Adds versioning system.
|
||||
- Uses NIP-44 for encryption.
|
||||
- Moves to kind-23197 notification events, encrypted with NIP-44.
|
||||
|
||||
## Using a dedicated relay
|
||||
This NIP does not specify any requirements on the type of relays used. However, if the user is using a custodial service it might make sense to use a relay that is hosted by the custodial service. The relay may then enforce authentication to prevent metadata leaks. Not depending on a 3rd party relay would also improve reliability in this case.
|
||||
|
@ -603,6 +611,7 @@ This NIP does not specify any requirements on the type of relays used. However,
|
|||
"created_at": 1713883677,
|
||||
"kind": 13194,
|
||||
"tags": [
|
||||
[ "v", "1.3 0.0"],
|
||||
[
|
||||
"notifications",
|
||||
"payment_received payment_sent"
|
||||
|
|
|
@ -180,6 +180,8 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
|
|||
| `22242` | Client Authentication | [42](42.md) |
|
||||
| `23194` | Wallet Request | [47](47.md) |
|
||||
| `23195` | Wallet Response | [47](47.md) |
|
||||
| `23196` | NWC Notification (v0) | [47](47.md) |
|
||||
| `23197` | NWC Notification (v1+) | [47](47.md) |
|
||||
| `24133` | Nostr Connect | [46](46.md) |
|
||||
| `24242` | Blobs stored on mediaservers | [Blossom][blossom] |
|
||||
| `27235` | HTTP Auth | [98](98.md) |
|
||||
|
|
Loading…
Reference in New Issue
Block a user