nostr/nips
1
0
Fork 0
mirror of https://github.com/nostr-protocol/nips.git synced 2024-09-20 23:05:49 -04:00
Code Issues Actions Packages Projects Releases Wiki Activity

Update NIP-89

Browse Source 
Add examples of client steps for broadcasting and observing `"payto"` events
This commit is contained in:
ATXMJ 2023-02-17 16:18:14 -07:00 committed by GitHub
parent 6b702eaac4
commit 9ec2090b1b
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 20 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

24
89.md
View File

@ -29,6 +29,14 @@ The client then broadcasts an event such as
} }
``` ```
#### Example of steps taken by the client on input
- allow the user to specify a list of `payment_target_type` and `authority` value pairs (labeled as preferred by the client) of their choice
- for each pair of `payment_target_type` and `authority` values specified by the user
- *optionally* do some minimal validation on those fields in a generalized way that applies to any payment network
- *optionally* warn users if a specifid `payment_target_type` is not [*recognized*](#recommended-payment-target-types) by the client
- broadcast the event in the format specified above
### Recommended Payment Target Types ### Recommended Payment Target Types
This is a list of recommended payment target types for clients to recognize and store icons and stylization configurations for. This is a list of recommended payment target types for clients to recognize and store icons and stylization configurations for.
@ -44,11 +52,11 @@ This is a list of recommended payment target types for clients to recognize and
On observation of events of kind `0` (`set_metadata`), the event *may* specify the key `"payto"` with a value consisting of a list (one or many) of "payment target" values, each specified as a pair of values `payment_target_type` and `authority` as specified in the [RFC-8905 (payto:) URI scheme](https://www.rfc-editor.org/rfc/rfc8905.html) for payment targets. On observation of events of kind `0` (`set_metadata`), the event *may* specify the key `"payto"` with a value consisting of a list (one or many) of "payment target" values, each specified as a pair of values `payment_target_type` and `authority` as specified in the [RFC-8905 (payto:) URI scheme](https://www.rfc-editor.org/rfc/rfc8905.html) for payment targets.
For each pair of values in the list, the client *should* assemble a full `payto://` deep link URI and render it as a button or link in the user's profile, posts, chats, or elsewhere, in the format of `payto://<payment_target_type>/<authority>`. For each pair of values in the `payto` list, the client *should* assemble a full `payto://` deep link URI and render it as a button or link in the user's profile, posts, chats, or elsewhere, in the format of `payto://<payment_target_type>/<authority>`.
The client *should* store a map of [recognized payment target types](#recommended-payment-target-types) along with a corresponding icon and/or stylization configuration (to be defined by the client). The client *should* store a map of [recognized payment target types](#recommended-payment-target-types) along with a corresponding icon & stylization configuration (to be defined by the client).
For ***recognized*** `payment_target_type` values, the client *should* render a button or link using the associated icon and/or stylization. For ***recognized*** `payment_target_type` values, the client *should* render a button or link using the associated icon & stylization.
For ***unrecognized*** `payment_target_type` values, the client *may* chose to either ignore them or use a generic stylization, perhaps using the `payment_target_type` value directly for the button or link. For ***unrecognized*** `payment_target_type` values, the client *may* chose to either ignore them or use a generic stylization, perhaps using the `payment_target_type` value directly for the button or link.
@ -73,6 +81,14 @@ for each payment target it will assemble a deep link payment invocation URI, as
`payto://nano/nano_1dctqbmqxfppo9pswbm6kg9d4s4mbraqn8i4m7ob9gnzz91aurmuho48jx3c` (*recognized*) `payto://nano/nano_1dctqbmqxfppo9pswbm6kg9d4s4mbraqn8i4m7ob9gnzz91aurmuho48jx3c` (*recognized*)
`payto://unknowntype/l7tbta5b9xze6ckkfc99uohzxd009b0r` (*unrecognized*) `payto://unknowntype/l7tbta5b9xze6ckkfc99uohzxd009b0r` (*unrecognized*)
The client chooses to ignore the third *unrecognized* `payment_target_type`, and only embeds the first two payment target deep links in the user's profile, posts, chats, or elsewhere as buttons, links, or a dropdown selector using the corresponding icons or stylizations for the [*recognized* payment target types](#recommended-payment-target-types). The client chooses to ignore the third *unrecognized* `payment_target_type`, and only embeds the first two payment target deep links in the user's profile, posts, chats, or elsewhere as buttons, links, or a dropdown selector using the corresponding icons & stylizations for the [*recognized* payment target types](#recommended-payment-target-types).
*Optionally*, the client may have chosen to render the third payment target using the text `unknowntype` rather than ignoring it. *Optionally*, the client may have chosen to render the third payment target using the text `unknowntype` rather than ignoring it.
#### Example of steps taken by the client on observation
- for each pair of `payment_target_type` and `authority` values in the `payto` list
- *optionally* do some minimal validation on those fields in a generalized way that applies to any payment network, and filter out invalid pairs
- *optionally* filter out any pairs with an [*unrecognized*](#recommended-payment-target-types) `payment_target_type`
- assemble a full `payto://` deep link URI in the format `payto://<payment_target_type>/<authority>`
- render a button, link, or dropdown in user profiles, posts, chats, and elsewhere using the assembled deep links and the corresponding icons & stylization configurations for *recognized* `payment_target_type` values