kopia lustrzana https://github.com/Podcastindex-org/podcast-namespace
value spec - add "auto" as a payment action
Dave Jones
rodzic
60b02f8335
commit
f526d1e3e7
|
|
@ -1,4 +1,4 @@
|
|||
# bLIP 10
|
||||
# bLIP 10 - A TLV record for lightning payments to carry podcast payment metadata
|
||||
|
||||
```text
|
||||
Original Author: Satoshis Stream <satoshisstream@pm.me>
|
||||
|
|
@ -8,8 +8,14 @@ License: CC0
|
|||
|
||||
## Abstract
|
||||
|
||||
Using Value 4 Value apps, listeners can send sats to the hosts of the podcasts they listen to. Per minute sending is called `stream` and manual payments are called `boost`s. If there is a message to the podcaster, with a boost, it is called a `boostagram`.
|
||||
These apps (see [Reference Implementations](#reference-implementations)) adopted bLIP 10 with the **7629169** TLV type for inputting key-value JSON metadata about the sent payment. The TLV holds data about the timestamp when the payment was sent within the episode, the name of the podcast and its [Guid](https://github.com/Podcastindex-org/podcast-namespace/blob/main/docs/1.0.md#guid), among other fields described in the [Specification](#specification) section.
|
||||
Using Value 4 Value apps, listeners can send sats to the hosts of the podcasts they listen to. Per minute sending is
|
||||
called `stream` and manual payments are called `boost`s. If there is a message to the podcaster, with a boost, it is
|
||||
called a `boostagram`.
|
||||
These apps (see [Reference Implementations](#reference-implementations)) adopted bLIP 10 with the **7629169** TLV type
|
||||
for inputting key-value JSON metadata about the sent payment. The TLV holds data about the timestamp when the payment
|
||||
was sent within the episode, the name of the podcast and
|
||||
its [Guid](https://github.com/Podcastindex-org/podcast-namespace/blob/main/docs/1.0.md#guid), among other fields
|
||||
described in the [Specification](#specification) section.
|
||||
|
||||
Example:
|
||||
|
||||
|
|
@ -29,22 +35,39 @@ This bLIP is licensed under the CC0 license.
|
|||
|
||||
## Specification
|
||||
|
||||
The sender of the payments (the podcast app) needs to input some metadata so the podcast host can identify whom the payment is for. Most fields are optional.
|
||||
The sender of the payments (the podcast app) needs to input some metadata so the podcast host can identify whom the
|
||||
payment is for. Most fields are optional.
|
||||
|
||||
### Formatting and encoding
|
||||
|
||||
A flat key-value json structure is used where the keys listed below can be set. The json string is then encoded into `utf8` and attached to the keysend payment. Receivers of messages must be aware that there is no guarantee for the order of the keys.
|
||||
A flat key-value json structure is used where the keys listed below can be set. The json string is then encoded
|
||||
into `utf8` and attached to the keysend payment. Receivers of messages must be aware that there is no guarantee for the
|
||||
order of the keys.
|
||||
|
||||
Sample JSON string, containing a selection of keys:
|
||||
|
||||
```json
|
||||
{"app_name": "Castamatic", "app_version": "8.0.6", "value_msat_total": 49960, "url": "https://feeds.buzzsprout.com/1844352.rss", "podcast": "Mere Mortals", "action": "stream", "episode": "The Art Of NFT's & Aimless Wandering", "episode_guid": "Buzzsprout-9931017", "value_msat": 97940, "ts": 574, "name": "Podcaster", "sender_name": "Peter"}
|
||||
{
|
||||
"app_name": "Castamatic",
|
||||
"app_version": "8.0.6",
|
||||
"value_msat_total": 49960,
|
||||
"url": "https://feeds.buzzsprout.com/1844352.rss",
|
||||
"podcast": "Mere Mortals",
|
||||
"action": "stream",
|
||||
"episode": "The Art Of NFT's & Aimless Wandering",
|
||||
"episode_guid": "Buzzsprout-9931017",
|
||||
"value_msat": 97940,
|
||||
"ts": 574,
|
||||
"name": "Podcaster",
|
||||
"sender_name": "Peter"
|
||||
}
|
||||
```
|
||||
|
||||
Treated as `utf8`, the hex value of this json record would be:
|
||||
`7b226170705f6e616d65223a202243617374616d61746963222c20226170705f76657273696f6e223a2022382e302e36222c202276616c75655f6d7361745f746f74616c223a2034393936302c202275726c223a202268747470733a2f2f66656564732e62757a7a7370726f75742e636f6d2f313834343335322e727373222c2022706f6463617374223a20224d657265204d6f7274616c73222c2022616374696f6e223a202273747265616d222c2022657069736f6465223a202254686520417274204f66204e4654277320262041696d6c6573732057616e646572696e67222c2022657069736f64655f67756964223a202242757a7a7370726f75742d39393331303137222c202276616c75655f6d736174223a2039373934302c20227473223a203537342c20226e616d65223a2022506f64636173746572222c202273656e6465725f6e616d65223a20225065746572227d0a`
|
||||
|
||||
If a field is indicated to be a `str` in the fields-list, that means it is a JSON string (within quotes) and `int`s are plain numbers.
|
||||
If a field is indicated to be a `str` in the fields-list, that means it is a JSON string (within quotes) and `int`s are
|
||||
plain numbers.
|
||||
|
||||
### Fields
|
||||
|
||||
|
|
@ -53,9 +76,11 @@ Identifying the podcast **required**: use any of `podcast`, `guid`, `feedID` and
|
|||
* `podcast` (str) Title of the podcast
|
||||
* `feedID` (int) ID of podcast in PodcastIndex.org
|
||||
* `url` (str) RSS feed URL of podcast
|
||||
* `guid` (str) [The `<podcast:guid>` tag](https://github.com/Podcastindex-org/podcast-namespace/blob/main/docs/1.0.md#guid).
|
||||
* `guid` (
|
||||
str) [The `<podcast:guid>` tag](https://github.com/Podcastindex-org/podcast-namespace/blob/main/docs/1.0.md#guid).
|
||||
|
||||
Identifying the episode **recommended**: use any of `episode`, `itemID` and/or `episode_guid`. **episode_guid preferred**
|
||||
Identifying the episode **recommended**: use any of `episode`, `itemID` and/or `episode_guid`. **episode_guid
|
||||
preferred**
|
||||
|
||||
* `episode` (str) Episode of the podcast
|
||||
* `itemID` (int) ID of episode in PodcastIndex.org
|
||||
|
|
@ -75,15 +100,25 @@ Rest of keys:
|
|||
* `message` (str) Text message to add to the boost message: a boostagram
|
||||
* `name` (str) Name for this split in value tag
|
||||
* `sender_name` **recommended** (str) Name of sender (free text, not checked by signatures)
|
||||
* `sender_id` (str) Static random identifier for users, not displayed by apps to prevent abuse. Apps can set this per-feed or app-wide. A GUID-like random identifier or a hash works well. Max 32 ascii characters.
|
||||
* `sender_id` (str) Static random identifier for users, not displayed by apps to prevent abuse. Apps can set this
|
||||
per-feed or app-wide. A GUID-like random identifier or a hash works well. Max 32 ascii characters.
|
||||
* `speed` (str) Speed in which the podcast was played, in decimal. So 0.5 is half speed and 2 is double speed.
|
||||
* `uuid` (str) Unique UUID of the payment
|
||||
* `value_msat_total`: **recommended** (int) TOTAL Number of millisats for the payment (all splits together, before fees. The actual number someone entered in their player, for numerology purposes.)
|
||||
* `value_msat_total`: **recommended** (int) TOTAL Number of millisats for the payment (all splits together, before fees.
|
||||
The actual number someone entered in their player, for numerology purposes.)
|
||||
|
||||
|
||||
## Actions
|
||||
|
||||
* `boost`
|
||||
|
||||
|
||||
## Reference Implementations
|
||||
|
||||
* Breez: <https://github.com/breez/breezmobile/blob/4cf057c066d03c155964f0c4db43476cd70a57ab/lib/bloc/podcast_payments/podcast_payments_bloc.dart>
|
||||
* Podverse: <https://github.com/podverse/podverse-shared/blob/fff84c0143dea4fa01241109b8666d4c0b9a6ffc/src/satoshiStream.ts>
|
||||
*
|
||||
Breez: <https://github.com/breez/breezmobile/blob/4cf057c066d03c155964f0c4db43476cd70a57ab/lib/bloc/podcast_payments/podcast_payments_bloc.dart>
|
||||
*
|
||||
Podverse: <https://github.com/podverse/podverse-shared/blob/fff84c0143dea4fa01241109b8666d4c0b9a6ffc/src/satoshiStream.ts>
|
||||
* PodStation: <https://github.com/podStation/podStation/pull/249>
|
||||
* Helipad: <https://github.com/Podcastindex-org/helipad/blob/203e72dafb65e4f9e89540fbe4fc07a456a9907a/src/main.rs>
|
||||
* Rust-V4V: <https://github.com/Conshax/Rust-V4V/blob/master/src/boostagram.rs>
|
||||
|
|
@ -228,7 +263,8 @@ Fountain sends the itemID as a string, not an int.
|
|||
### Breez
|
||||
|
||||
Breez sends the guid on the itemID field and the sender_name is an empty string on streams.
|
||||
Besides that Breez takes its fee from the total instead on top of the total as fountain does, this results in the received value of a split being less than it should calculated from the total.
|
||||
Besides that Breez takes its fee from the total instead on top of the total as fountain does, this results in the
|
||||
received value of a split being less than it should calculated from the total.
|
||||
|
||||
#### Boost
|
||||
|
||||
|
|
|
|||
146
value/value.md
146
value/value.md
|
|
@ -1,6 +1,7 @@
|
|||
# The "podcast:value" Specification
|
||||
|
||||
<small>Version 1.4 by [Dave Jones](https://github.com/daveajones) - with [Gigi](https://github.com/dergigi), [Evan Feenstra](https://github.com/evanfeenstra) & [Paul Itoi](https://github.com/pitoi)</small><br>
|
||||
<small>Version 1.4 by [Dave Jones](https://github.com/daveajones) - with [Gigi](https://github.com/dergigi)
|
||||
, [Evan Feenstra](https://github.com/evanfeenstra) & [Paul Itoi](https://github.com/pitoi)</small><br>
|
||||
<small>September 1st, 2021</small>
|
||||
|
||||
<br>
|
||||
|
|
@ -8,11 +9,13 @@
|
|||
## Purpose
|
||||
|
||||
Here we describe an additional "block" of XML that gives podcasters (and other media creators) a way to receive direct
|
||||
payments from their audience in response to the action of viewing or listening to a created work. Utilizing so called "Layer 2"
|
||||
payments from their audience in response to the action of viewing or listening to a created work. Utilizing so called "
|
||||
Layer 2"
|
||||
cryptocurrency networks like Lightning, and possibly other digital currency mechanisms, near real-time micropayments can
|
||||
be directly sent from listener or viewer to the creator without the need for a payment processor or other "middle men".
|
||||
|
||||
The value block designates single or multiple destinations for these micro-payments. The idea is that the creator of the media
|
||||
The value block designates single or multiple destinations for these micro-payments. The idea is that the creator of the
|
||||
media
|
||||
describes (within the feed) where and how they would like payments to be sent back to them during consumption
|
||||
of that media. The format is designed to be flexible enough to handle many scenarios of direct payment streaming. Even
|
||||
the use of fiat currency, if there is an API that is capable of interfacing as a receiver within this format.
|
||||
|
|
@ -42,7 +45,8 @@ in a single transaction. Likewise, some apps with limited connectivity may need
|
|||
hour. In that scenario, there would be 60 payments added up into a single, larger payment. Batching transactions
|
||||
like this also helps to minimize the impact of transaction fees on the underlying cryptocurrency network.
|
||||
|
||||
Note that playback speed is not a factor in this calculation. The "one minute payment interval" refers to the minutes that make up the total runtime of the content, thus all payment calculations are independent of playback speed.
|
||||
Note that playback speed is not a factor in this calculation. The "one minute payment interval" refers to the minutes
|
||||
that make up the total runtime of the content, thus all payment calculations are independent of playback speed.
|
||||
|
||||
<div class="page"/>
|
||||
|
||||
|
|
@ -58,7 +62,8 @@ parent.
|
|||
|
||||
### Value Element
|
||||
|
||||
The `<podcast:value>` tag designates the cryptocurrency or payment layer that will be used, the transport method for transacting
|
||||
The `<podcast:value>` tag designates the cryptocurrency or payment layer that will be used, the transport method for
|
||||
transacting
|
||||
the payments, and a suggested amount denominated in the given cryptocurrency.
|
||||
|
||||
This element can exist at either the `<channel>` or `<item>` level.
|
||||
|
|
@ -66,7 +71,9 @@ This element can exist at either the `<channel>` or `<item>` level.
|
|||
<br>
|
||||
|
||||
#### Structure:
|
||||
|
||||
```xml
|
||||
|
||||
<podcast:value
|
||||
type="[cryptocurrency or layer(string)]"
|
||||
method="[payment transport(string)]"
|
||||
|
|
@ -75,9 +82,11 @@ This element can exist at either the `<channel>` or `<item>` level.
|
|||
[one or more "podcast:valueRecipient" elements]
|
||||
</podcast:value>
|
||||
```
|
||||
|
||||
<br>
|
||||
|
||||
#### Attributes:
|
||||
|
||||
- `type` (required) This is the service slug of the cryptocurrency or protocol layer.
|
||||
- `method` (required) This is the transport mechanism that will be used.
|
||||
- `suggested` (optional) This is an optional suggestion on how much cryptocurrency to send with each payment.
|
||||
|
|
@ -97,7 +106,8 @@ to be streamed to what is, essentially, an open invoice. Other cryptocurrencies
|
|||
would be used here. If not, a value of "default" should be given.
|
||||
|
||||
The "suggested" amount is just that. It's a suggestion, and must be changeable by the user to another value, or
|
||||
to zero. The suggested amount depends on the payment protocol being used. For instance, with Lightning on the Bitcoin network, the amount can be as low as one millisatoshi, expressed as `0.00000000001` BTC.
|
||||
to zero. The suggested amount depends on the payment protocol being used. For instance, with Lightning on the Bitcoin
|
||||
network, the amount can be as low as one millisatoshi, expressed as `0.00000000001` BTC.
|
||||
|
||||
A single value tag can contain many `<podcast:valueRecipient>` tags as children. All of these given recipients are
|
||||
sent individual payments when the payment interval triggers.
|
||||
|
|
@ -113,6 +123,7 @@ one-hundred-millionth of a single bitcoin (0.00000001 BTC). The smallest unit on
|
|||
the Lightning Network is a millisat, which is a thousandth of a sat.
|
||||
|
||||
```xml
|
||||
|
||||
<podcast:value
|
||||
type="lightning"
|
||||
method="keysend"
|
||||
|
|
@ -139,6 +150,7 @@ There is no limit on how many `valueRecipient` elements can be present in a give
|
|||
#### Structure:
|
||||
|
||||
```xml
|
||||
|
||||
<podcast:valueRecipient
|
||||
name="[name of recipient(string)]"
|
||||
type="[address type(string)]"
|
||||
|
|
@ -156,7 +168,8 @@ There is no limit on how many `valueRecipient` elements can be present in a give
|
|||
|
||||
- `name` (recommended) A free-form string that designates who or what this recipient is.
|
||||
- `customKey` (optional) The name of a custom record key to send along with the payment.
|
||||
- `customValue` (optional) A custom value to pass along with the payment. This is considered the value that belongs to the `customKey`.
|
||||
- `customValue` (optional) A custom value to pass along with the payment. This is considered the value that belongs to
|
||||
the `customKey`.
|
||||
- `type` (required) A slug that represents the type of receiving address that will receive the payment.
|
||||
- `address` (required) This denotes the receiving address of the payee.
|
||||
- `split` (required) The number of shares of the payment this recipient will receive.
|
||||
|
|
@ -166,34 +179,51 @@ There is no limit on how many `valueRecipient` elements can be present in a give
|
|||
|
||||
#### Explanation:
|
||||
|
||||
The `name` is just a human readable description of who or what this payment destination is. This could be something simple like
|
||||
"Podcaster", "Co-host" or "Producer". It could also be more descriptive like "Ronald McDonald House Charity", if a podcaster
|
||||
The `name` is just a human readable description of who or what this payment destination is. This could be something
|
||||
simple like
|
||||
"Podcaster", "Co-host" or "Producer". It could also be more descriptive like "Ronald McDonald House Charity", if a
|
||||
podcaster
|
||||
chooses to donate a percentage of their incoming funds to a charity.
|
||||
|
||||
The `type` denotes what type of receiving entity this is. For instance, with lightning this would typically be "node". This would
|
||||
indicate that the `address` attribute for this recipient is a Lightning node that is capable of directly receiving incoming keysend payments. Valid values for
|
||||
the `type` attribute are kept in the accompanying file [here](valueslugs.txt). Another option is given in examples below.
|
||||
The `type` denotes what type of receiving entity this is. For instance, with lightning this would typically be "node".
|
||||
This would
|
||||
indicate that the `address` attribute for this recipient is a Lightning node that is capable of directly receiving
|
||||
incoming keysend payments. Valid values for
|
||||
the `type` attribute are kept in the accompanying file [here](valueslugs.txt). Another option is given in examples
|
||||
below.
|
||||
|
||||
Payments must be sent to a valid destination which is given in the `address` attribute. This address format will vary depending on
|
||||
Payments must be sent to a valid destination which is given in the `address` attribute. This address format will vary
|
||||
depending on
|
||||
the underlying currency being used.
|
||||
|
||||
The `split` attribute denotes an amount of "shares" of the total payment that the recipient will receive when each timed payment is made.
|
||||
When a single `<podcast:valueRecipient>` is present, it should be assumed that the `split` for that recipient is 100%, and the "split" should
|
||||
be ignored. When multiple recipients are present, a share calculation (see below) should be made to determine how much to send to each recipient's address.
|
||||
The `split` attribute denotes an amount of "shares" of the total payment that the recipient will receive when each timed
|
||||
payment is made.
|
||||
When a single `<podcast:valueRecipient>` is present, it should be assumed that the `split` for that recipient is 100%,
|
||||
and the "split" should
|
||||
be ignored. When multiple recipients are present, a share calculation (see below) should be made to determine how much
|
||||
to send to each recipient's address.
|
||||
|
||||
The `fee` attribute tells apps whether this split should be treated as a "fee", or a normal split. If this attribute is true, then this split should be calculated
|
||||
as a fee, meaning its percentage (as calculated from the shares) should be taken off the top of the entire transaction amount. This is the preferred way for service
|
||||
The `fee` attribute tells apps whether this split should be treated as a "fee", or a normal split. If this attribute is
|
||||
true, then this split should be calculated
|
||||
as a fee, meaning its percentage (as calculated from the shares) should be taken off the top of the entire transaction
|
||||
amount. This is the preferred way for service
|
||||
providers such as apps, hosting companies, API's and third-party value add providers to add their fee to a value block.
|
||||
|
||||
#### Custom Key/Value Pairs
|
||||
|
||||
The `customKey` and `customValue` pair can be used (especially for the Lighning Network) to help a receiving application route or process payments that have all arrived at one node.
|
||||
The `customKey` and `customValue` pair can be used (especially for the Lighning Network) to help a receiving application
|
||||
route or process payments that have all arrived at one node.
|
||||
|
||||
The idea is that Podcast Index will parse and store and all client apps will always send a `customKey:customValue` pair if these are found in the Value Block.
|
||||
The idea is that Podcast Index will parse and store and all client apps will always send a `customKey:customValue` pair
|
||||
if these are found in the Value Block.
|
||||
|
||||
For example, the `customKey`'s of `818818`, `112111100` are used to route payments to Hive accounts or specific wallets on LNPay respectively. These fields are documented [in the list maintained by Satoshis Stream](https://github.com/satoshisstream/satoshis.stream/blob/main/TLV_registry.md).
|
||||
For example, the `customKey`'s of `818818`, `112111100` are used to route payments to Hive accounts or specific wallets
|
||||
on LNPay respectively. These fields are
|
||||
documented [in the list maintained by Satoshis Stream](https://github.com/satoshisstream/satoshis.stream/blob/main/TLV_registry.md)
|
||||
.
|
||||
|
||||
If your specific application would benefit from your own `customKey:customValue` pair which will be passed along from the player to your app, and for which nothing already exists, add your own.
|
||||
If your specific application would benefit from your own `customKey:customValue` pair which will be passed along from
|
||||
the player to your app, and for which nothing already exists, add your own.
|
||||
|
||||
<br><br>
|
||||
|
||||
|
|
@ -208,6 +238,7 @@ The interval payment calculation is:
|
|||
To calculate payouts, let's take the following value block as an example:
|
||||
|
||||
```xml
|
||||
|
||||
<podcast:value type="lightning" method="keysend" suggested="0.00000015000">
|
||||
<podcast:valueRecipient
|
||||
name="Host"
|
||||
|
|
@ -230,13 +261,17 @@ To calculate payouts, let's take the following value block as an example:
|
|||
</podcast:value>
|
||||
```
|
||||
|
||||
This block designates three payment recipients. On each timed payment interval, the total payment will be split into 3 smaller
|
||||
payments according to the shares listed in the split for each recipient. So, in this case, if the listener decided to pay 100 sats per minute for listening
|
||||
This block designates three payment recipients. On each timed payment interval, the total payment will be split into 3
|
||||
smaller
|
||||
payments according to the shares listed in the split for each recipient. So, in this case, if the listener decided to
|
||||
pay 100 sats per minute for listening
|
||||
to this podcast, then once per minute the "Host" would be sent 50 sats, the "Co-Host" would be sent 40 sats and the
|
||||
"Producer" would be sent 10 sats - all to their respective lightning node addresses using the "keysend" protocol.
|
||||
|
||||
If, instead of a 50/40/10 (total of 100) split, the splits were given as 190/152/38 (total of 380), the respective payment amounts each minute would still
|
||||
be 50 sats, 40 sats and 10 sats because the listener chose to pay 100 sats per minute, and the respective shares (as a percentage of the total) would remain the same.
|
||||
If, instead of a 50/40/10 (total of 100) split, the splits were given as 190/152/38 (total of 380), the respective
|
||||
payment amounts each minute would still
|
||||
be 50 sats, 40 sats and 10 sats because the listener chose to pay 100 sats per minute, and the respective shares (as a
|
||||
percentage of the total) would remain the same.
|
||||
|
||||
On a 190/152/38 split, each minute the payment calculation would be:
|
||||
|
||||
|
|
@ -248,7 +283,8 @@ On a 190/152/38 split, each minute the payment calculation would be:
|
|||
- Recipient #2 gets a payment of: 40 sats (152 / 380 * 100)
|
||||
- Recipient #3 gets a payment of: 10 sats (38 / 380 * 100)
|
||||
|
||||
If an app chooses to only make a payout once every 30 minutes of listening/watching, the calculation would be the same after multiplying
|
||||
If an app chooses to only make a payout once every 30 minutes of listening/watching, the calculation would be the same
|
||||
after multiplying
|
||||
the per-minute payment by 30:
|
||||
|
||||
- Interval payout: 3000 sats (100 * 30)
|
||||
|
|
@ -259,8 +295,10 @@ the per-minute payment by 30:
|
|||
- Recipient #2 gets a payment of: 1200 sats (152 / 380 * 3000)
|
||||
- Recipient #3 gets a payment of: 300 sats (38 / 380 * 3000)
|
||||
|
||||
As shown above, the once per minute calculation does not have to actually be sent every minute. A longer payout period can be chosen. But,
|
||||
the once-per-minute nature of the payout still remains in order for listeners and creators to have an easy way to measure and calculate how much
|
||||
As shown above, the once per minute calculation does not have to actually be sent every minute. A longer payout period
|
||||
can be chosen. But,
|
||||
the once-per-minute nature of the payout still remains in order for listeners and creators to have an easy way to
|
||||
measure and calculate how much
|
||||
they will spend and charge.
|
||||
|
||||
<br><br>
|
||||
|
|
@ -269,10 +307,12 @@ they will spend and charge.
|
|||
|
||||
### Supported Currencies and Protocols
|
||||
|
||||
The value block is designed to be flexible enough to handle most any cryptocurrency, and even fiat currencies with a given
|
||||
The value block is designed to be flexible enough to handle most any cryptocurrency, and even fiat currencies with a
|
||||
given
|
||||
API that exposes a compatible process.
|
||||
|
||||
Currently, development is centered mostly on [Lightning](https://github.com/lightningnetwork) using the "keysend" method. Keysend allows for push
|
||||
Currently, development is centered mostly on [Lightning](https://github.com/lightningnetwork) using the "keysend"
|
||||
method. Keysend allows for push
|
||||
based payments without the recipient needing to generate an invoice to receive them.
|
||||
Another method to send spontaneous payments via Lightning is AMP, atomic
|
||||
[multipath payments][AMP]. AMP supersedes keysend in many ways and allows for
|
||||
|
|
@ -298,7 +338,9 @@ For the `<podcast:valueRecipient>` tag, the following attributes MUST be used:
|
|||
- `address`: \<the destination node's pubkey\>
|
||||
- `split`: \<the number of shares\>
|
||||
|
||||
If the receiving Lightning node, or service, requires application specific data to be sent with the payment in the lightning message `extension` (a _TLV stream_, see the Appendix section), the `customKey` and `customValue` can be utilized as follows:
|
||||
If the receiving Lightning node, or service, requires application specific data to be sent with the payment in the
|
||||
lightning message `extension` (a _TLV stream_, see the Appendix section), the `customKey` and `customValue` can be
|
||||
utilized as follows:
|
||||
|
||||
- `type`: "node"
|
||||
- `method`: "keysend" or "amp"
|
||||
|
|
@ -311,15 +353,20 @@ If the receiving Lightning node, or service, requires application specific data
|
|||
|
||||
**Remarks:**
|
||||
|
||||
- `customValue` is specified as a string due to the emergence of known users for this field (see Appendix). If we decide to support raw binary data in the future, a new attribute can be introduced to indicate the different behavior
|
||||
- There is at least one known shared node ([satoshis.stream](https://satoshis.stream/)) that requires, in addition to this specification, the inclusion of the TLV record with type `7629169`, as defined [here](https://github.com/satoshisstream/satoshis.stream/blob/main/TLV_registry.md#field-7629169), in order to correctly route the payment to the corresponding receiver
|
||||
- `customValue` is specified as a string due to the emergence of known users for this field (see Appendix). If we decide
|
||||
to support raw binary data in the future, a new attribute can be introduced to indicate the different behavior
|
||||
- There is at least one known shared node ([satoshis.stream](https://satoshis.stream/)) that requires, in addition to
|
||||
this specification, the inclusion of the TLV record with type `7629169`, as
|
||||
defined [here](blip-0010.md), in order to correctly route the payment to the corresponding receiver
|
||||
|
||||
<br>
|
||||
|
||||
##### Example
|
||||
|
||||
This is a live, working example of a Lightning keysend value block in production. It designates four recipients for payment - two
|
||||
podcast hosts at 49 and 46 shares respectively, a producer working on per episode chapter creation who gets a 5 share, and
|
||||
This is a live, working example of a Lightning keysend value block in production. It designates four recipients for
|
||||
payment - two
|
||||
podcast hosts at 49 and 46 shares respectively, a producer working on per episode chapter creation who gets a 5 share,
|
||||
and
|
||||
a single share (effectively 1%) fee to the Podcastindex.org API.
|
||||
Since the value block is defined at the `<channel>` level, it applies to every podcast episode.
|
||||
|
||||
|
|
@ -440,11 +487,30 @@ and guest.
|
|||
|
||||
<br>
|
||||
|
||||
##### Appendix
|
||||
##### Appendix A - TLV Records and Extensions
|
||||
|
||||
Lightning payments are performed using lightning messages as specified in [BOLT #1: Base Protocol](https://github.com/lightningnetwork/lightning-rfc/blob/master/01-messaging.md).
|
||||
Lightning payments are performed using lightning messages as specified
|
||||
in [BOLT #1: Base Protocol](https://github.com/lightningnetwork/lightning-rfc/blob/master/01-messaging.md).
|
||||
|
||||
One part of the message is the `extension`, a TLV (Type-Length-Value) stream. Podcast specific data can be added to transactions using the key **7629169** with the value described in [bLIP 10](blip-0010.md)
|
||||
One part of the message is the `extension`, a TLV (Type-Length-Value) stream. Podcast specific data can be added to
|
||||
transactions using the key **7629169** with the value described in [bLIP 10](blip-0010.md)
|
||||
|
||||
A community maintained registry of additional known custom record types and formats, governed by satoshis.stream, can be found at the document [TLV record registry](https://github.com/satoshisstream/satoshis.stream/blob/main/TLV_registry.md). In special, the section _Fields used in customKey / customValue Pairs_ documents the known use cases for the `customKey` and `customValue` attributes.
|
||||
A community maintained registry of additional known custom record types and formats, governed by satoshis.stream, can be
|
||||
found at the document [TLV record registry](https://github.com/satoshisstream/satoshis.stream/blob/main/TLV_registry.md)
|
||||
. In special, the section _Fields used in customKey / customValue Pairs_ documents the known use cases for
|
||||
the `customKey` and `customValue` attributes.
|
||||
|
||||
|
||||
##### Appendix B - Payment Actions
|
||||
|
||||
There are currently 3 payment "actions" that are defined in the BLIP-10 TLV extension that is embedded in the payment
|
||||
payload: "stream", "boost" and "auto".
|
||||
|
||||
* "stream" - This means the payment is a timed interval payment (i.e. - every minute) that is sent or queued while the
|
||||
user is engaged in active listening/viewing of the content.
|
||||
* "boost" - This means the payment is a user generated one-time payment that happens in response to a user initiated
|
||||
action like a "Boost" button push, or some other clearly labeled payment initiation function. These
|
||||
types of payments can contain textual messages (i.e. - a boostagram).
|
||||
* "auto" - This means the payment was an app initiated payment that recurs at a specific long-form interval such as
|
||||
weekly, monthly, yearly, etc. The user configures an interval and payment amount in the app and the app
|
||||
then sends that amount at the specified time when each interval passes.
|
||||
Ładowanie…
Reference in New Issue