mirror of
https://github.com/nostr-protocol/nips.git
synced 2026-10-05 10:48:23 +00:00
rewrite NIP-A3 because jesus christ.
This commit is contained in:
fiatjaf
@@ -1,48 +1,27 @@
|
||||
# NIP-A3
|
||||
|
||||
## payto: Payment Targets (RFC-8905)
|
||||
## payto: Payment Targets
|
||||
|
||||
### Event Kind
|
||||
`draft` `optional`
|
||||
|
||||
This NIP defines `kind:10133` for payment target events. This kind is **replaceable**.
|
||||
|
||||
`optional` `author:atxmj`
|
||||
|
||||
This NIP standardizes payment and tip invocations using the [RFC-8905 (payto:) URI scheme](https://www.rfc-editor.org/rfc/rfc8905.html) for payment targets.
|
||||
|
||||
### Broadcasting
|
||||
|
||||
Clients *may* allow users to specify payment targets consisting of `type` and `authority` values to generate a kind `10133` event with `payto` tags for payment or tip invocations.
|
||||
|
||||
**Client Implementation:**
|
||||
1. Allow users to input `type` and `authority` pairs
|
||||
2. Validate inputs according to the rules below
|
||||
3. Optionally warn users if a `type` is not recognized (but allow submission)
|
||||
4. Broadcast the event with `payto` tags
|
||||
This NIP standardizes how payment addresses are declared across any network or platform.
|
||||
|
||||
#### Tag Format
|
||||
|
||||
Payment targets are specified using `payto` tags with the following structure:
|
||||
|
||||
```text
|
||||
["payto", "<type>", "<authority>", "<optional_extra_1>", "<optional_extra_2>", ...]
|
||||
["payto", "<type>", "<address>"]
|
||||
```
|
||||
|
||||
Where:
|
||||
- The first element is always the literal string `"payto"`
|
||||
- The second element is the payment `type` (e.g., `"bitcoin"`, `"lightning"`)
|
||||
- The third element is the `authority` (e.g., address, username)
|
||||
- Additional elements are optional and reserved for future RFC-8905 features
|
||||
- The second element is the payment `type` (e.g., `"bitcoin"`, `"lightning"`), always lowercase.
|
||||
- The third element is the `address` (e.g., address, username)
|
||||
|
||||
Clients **must** understand elements 0–2; they **may ignore** any additional elements for forward compatibility.
|
||||
Clients may perform additional network- or platform-specific validation for recognized types.
|
||||
|
||||
#### Validation
|
||||
|
||||
- `type`: Lowercase letters (a-z), digits (0-9), and hyphens (-). Types are case-insensitive; normalize to lowercase.
|
||||
- `authority`: URL-safe; URL-encode special characters. Format depends on the payment system.
|
||||
- Clients may perform additional payment-system-specific validation for recognized types.
|
||||
|
||||
### Broadcasting Example
|
||||
### Example
|
||||
|
||||
```json
|
||||
{
|
||||
@@ -58,75 +37,28 @@ Clients **must** understand elements 0–2; they **may ignore** any additional e
|
||||
}
|
||||
```
|
||||
|
||||
### Recommended Payment Target Types
|
||||
For each `payto` tag in kind `10133` events, clients can render the payment address as a button or link. Clients may use a specific URI scheme when one is available, such as `bitcoin:<address>` or `ethereum:<address>`. Otherwise fall back to the `payto` URI scheme defined by [RFC-8905](https://www.rfc-editor.org/rfc/rfc8905.html): `payto://<type>/<address>`.
|
||||
|
||||
| Payment Target Type | Long Stylization | Short Stylization | Symbol | References |
|
||||
| :------------------ | :---------------- | :---------------- | :----- | :--------- |
|
||||
| bitcoin | Bitcoin | BTC | ₿ | https://bitcoin.design/ |
|
||||
| cashme | Cash App | Cash App | $,£ | https://cash.app/press |
|
||||
| ethereum | Ethereum | ETH | Ξ | https://ethereum.org/assets/#brand |
|
||||
| lightning | Lightning Network | LBTC | 丰 | https://github.com/shocknet/bitcoin-lightning-logo |
|
||||
| monero | Monero | XMR | ɱ | https://www.getmonero.org/press-kit/ |
|
||||
| nano | Nano | XNO | Ӿ | https://nano.org/en/currency |
|
||||
| revolut | Revolut | Revolut | N/A | https://revolut.me |
|
||||
| venmo | Venmo | Venmo | $ | https://venmo.com/pay |
|
||||
Possible rendered URIs:
|
||||
- `bitcoin:bc1qxq66e0t8d7ugdecwnmv58e90tpry23nc84pg9k`
|
||||
- `payto://nano/nano_1dctqbmqxfppo9pswbm6kg9d4s4mbraqn8i4m7ob9gnzz91aurmuho48jx3c`
|
||||
- `payto://unknowntype/l7tbta5b9xze6ckkfc99uohzxd009b0r`
|
||||
|
||||
### Observation
|
||||
### Commonly Used Tags
|
||||
|
||||
For each `payto` tag in kind `10133` events, clients *should* assemble a `payto://<type>/<authority>` URI and render it as a button or link.
|
||||
- `bip352` (silent payments)
|
||||
- `bip353` (DNS addresses)
|
||||
- `bitcoin`
|
||||
- `cashme` (Cash App `$`-prefixed cashtag)
|
||||
- `ethereum`
|
||||
- `lightning` (lightning address)
|
||||
- `litecoin`
|
||||
- `monero`
|
||||
- `nano`
|
||||
- `paypal`
|
||||
- `revolut`
|
||||
- `solana`
|
||||
- `venmo`
|
||||
- `zcash`
|
||||
|
||||
**Client Implementation:**
|
||||
1. Parse each `payto` tag from the event
|
||||
2. Optionally validate `type` and `authority` fields and filter invalid tags
|
||||
3. Assemble full `payto://<type>/<authority>` URIs
|
||||
4. For **recognized** types, render with associated icons and stylization from the table above
|
||||
5. For **unrecognized** types, either ignore or use generic stylization
|
||||
6. If multiple targets exist, render the first one, all of them, or a dropdown selector
|
||||
|
||||
### Observation Example
|
||||
|
||||
```json
|
||||
{
|
||||
"pubkey": "afc93622eb4d79c0fb75e56e0c14553f7214b0a466abeba14cb38968c6755e6a",
|
||||
"kind": 10133,
|
||||
"content": "",
|
||||
"tags": [
|
||||
["payto", "bitcoin", "bc1qxq66e0t8d7ugdecwnmv58e90tpry23nc84pg9k"],
|
||||
["payto", "nano", "nano_1dctqbmqxfppo9pswbm6kg9d4s4mbraqn8i4m7ob9gnzz91aurmuho48jx3c"],
|
||||
["payto", "unknowntype", "l7tbta5b9xze6ckkfc99uohzxd009b0r"]
|
||||
],
|
||||
...
|
||||
}
|
||||
```
|
||||
|
||||
Assembled URIs:
|
||||
- `payto://bitcoin/bc1qxq66e0t8d7ugdecwnmv58e90tpry23nc84pg9k` (recognized)
|
||||
- `payto://nano/nano_1dctqbmqxfppo9pswbm6kg9d4s4mbraqn8i4m7ob9gnzz91aurmuho48jx3c` (recognized)
|
||||
- `payto://unknowntype/l7tbta5b9xze6ckkfc99uohzxd009b0r` (unrecognized)
|
||||
|
||||
## Implementation Notes
|
||||
|
||||
### Integration with NIP-57 Zaps
|
||||
|
||||
Clients may use `payto` lightning entries as an alternative or complement to `lud16` for zap functionality. The `authority` field should contain a Lightning address (e.g., `user@wallet.example.com`) or LNURL.
|
||||
|
||||
Example:
|
||||
|
||||
```json
|
||||
[
|
||||
{
|
||||
"kind": 0,
|
||||
"content": "{\"lud16\":\"user@wallet.example.com\"}",
|
||||
"pubkey": "..."
|
||||
},
|
||||
{
|
||||
"kind": 10133,
|
||||
"content": "",
|
||||
"tags": [
|
||||
["payto", "lightning", "user@wallet.example.com"],
|
||||
["payto", "bitcoin", "bc1q..."]
|
||||
],
|
||||
"pubkey": "..."
|
||||
}
|
||||
]
|
||||
```
|
||||
New widely deployed formats can be added to this list later.
|
||||
|
||||
@@ -113,7 +113,7 @@ NIPs listed here are not a protocol checklist. Nothing forces any software to im
|
||||
- ~~[NIP-BE: Nostr BLE Communications Protocol](BE.md) --- **unrecommended**: only implemented once and unclear whether it works, requires review~~
|
||||
- [NIP-C0: Code Snippets](C0.md)
|
||||
- [NIP-C7: Chats](C7.md)
|
||||
- [NIP-A3: payto: Payment Targets (RFC-8905)](A3.md)
|
||||
- [NIP-A3: payto: Payment Targets](A3.md)
|
||||
- [NIP-CC: Geocaching](CC.md)
|
||||
- ~~[NIP-EE: E2EE Messaging using MLS Protocol](EE.md) --- **unrecommended**: superseded by the [Marmot Protocol](https://github.com/marmot-protocol/marmot)~~
|
||||
- [NIP-F4: Podcasts](F4.md)
|
||||
|
||||
Reference in New Issue
Block a user