Using Podcasting 2.0 apps, listeners can send sats to the hosts of the podcasts they listen. 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`.
This is part of what is known as "the Value for Value system". These apps (see [Reference Implementations](#reference-implementations)) adopted 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.
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.
A flat key-value json structure is used where below keys can be set. The string is then encoded into `utf8` and attached to the keysend payment. Receivers of messages must be aware there is no guarantee for the order of the keys.
*`action`**recommended**: (str) "boost" or "stream"
*`app_name`: **recommended** (str) Name of sending app
*`app_version`: (str) Version of sending app
*`boost_link`: (str) App specific URL containing route to podcast, episode, and timestamp at time of boost.
*`message` (str) Text message to add to the boost message: a boostagram
*`name`**recommended** (str) Name for this split in value tag
*`pubkey` (str) Sending node pubkey
*`seconds_back` (int) The amount of seconds someone has listened since last and until this payment. Usually 60 (sending every minute). Batching can be done for streaming payments by setting 600 for 10-minute streaming payments.
*`sender_key` (str) Node key of sending
*`sender_name` (str) Name of sender (free text, not checked by signatures)
*`sender_id` (str) Static random identifier for users, not displayed by apps, for abuse purposes. Apps can set this per-feed or app-wide. A GUID-like random identifier or a hash works well. Max 32 ascii characters.
*`sig_fields` (str) pipe separated list of fields that are used for signature (example: feedID|itemID|ts|action|sender_key|message)
*`signature` (str) DER-encoded ECDSA signature
*`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`: (int) Number of millisats for this split payment (this is in the meta/payment data too)
*`value_msat_total`: (int) TOTAL Number of millisats for the payment (all splits together, before fees. The actual number someone entered in their player, for numerology purposes.)
## Motivation
The Value for Value system is a way for podcasters to receive direct payments from listeners in the form of bitcoin through the Lightning Network. It provides not only a new way for podcast to earn and keep their independency, but also new forms of interaction between podcasters and its listeners.
Using the same TLV type allow for podcast creators to understand the messages regardless of which podcast app it was sent from and which solution they used to receive their payments.
_Future: The specification could be used for other media types, too._
## Rationale
The TLV type 7629169 was originally chosen by Breez and other applications adopted it to keep the same standard.
The required and recommended fields are constantly evolving by iterations from different Podcast 2.0 apps. Some of these fields are related to the extensions proposed by [PodcastIndex.org](https://podcastindex.org/) to the RSS 2.0 spec in order to deliver new functionality to apps and aggregators (see [the Podcast Namespace](https://github.com/Podcastindex-org/podcast-namespace))
## Universality
This usage of the 7629169 TLV type is only intended for Lightning applications in the Podcasting 2.0 space. Lightning applications that do not intersect with Podcasting 2.0 have no need to implement this standard. Additionally, no additional work is required from a Lightning implementation itself beyond BOLT-specified TLV support in order to enable this use case at the application layer.
## Backwards Compatibility
This is not using a feature bit and the TLV record is oddly typed, so there are no concerns regarding backwards compatibility.
