Merge pull request #10 from satoshisstream/master

Podcasting 2.0 blip

README.md

@@ -22,3 +22,4 @@ For more detail on the process, please read [bLIP-0001](./blip-0001.md) and
 | [1](./blip-0001.md)      | bLIP Process              | Ryan Gentry                 | Active |
 | [2](./blip-0002.md)      | Reserved Values           | Bastien Teinturier          | Active |
 | [3](./blip-0003.md)      | Keysend                   | Valentine Wallace           | Active |
+| [10](./blip-0010.md)     | Podcasting 2.0            | Satoshis Stream             | Active |

blip-0002.md

@@ -79,6 +79,15 @@ The following table contains extension tlv fields for the `init` message:
 |-------|-----------------------------|--------------------------------|
 | 65536 | `tlv_field_name`            | Link to the corresponding bLIP |
 
+#### `payment_onion_payload`
+
+The following table contains extension tlv fields for the `payment_onion_payload` message:
+
+| Type        | Name                        | Link                           |
+|-------------|-----------------------------|--------------------------------|
+| 7629169     | `podcasting_2_0`            | [bLIP 10](./blip-0010.md)      |
+
+
 #### `ping`
 
 The following table contains extension tlv fields for the `ping` message:

blip-0010.md

@@ -0,0 +1,99 @@
+```
+bLIP: 10
+Title: Podcasting 2.0 Streaming payments, Boosts and Boostagrams
+Status: Active
+Author:  Satoshis Stream <[email protected]>
+Created: 2022-01-24
+License: CC0
+```
+
+## Abstract
+
+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. 
+
+Example: `{'podcast': 'PODCASTNAME', 'feedID': 1337, 'episode': 'EPISODENAME', 'action': 'boost', 'ts': 33 }`
+
+## Copyright
+
+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. 
+
+### Formatting and encoding
+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.
+
+Sample JSON string, containing a selection of keys:
+`{"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.
+
+### Fields
+
+Identifying the podcast **required**: use any of `podcast`, `feedID` or `url`. **guid preferred**
+* `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).
+
+Identifying the episode **recommended**: use any of `episode`, `itemID` or `episode_guid`. **itemID preferred**
+* `episode` (str) Episode of the podcast
+* `itemID` (int) ID of episode in PodcastIndex.org
+* `episode_guid` (str) The GUID of the episode
+
+Information about time within the episode **recommended**: use any of `time`, `ts`. **ts preferred**
+* `time` (str) HH:MM:SS timestamp when the boost/stream was sent WITHIN the episode (playback position)
+* `ts` (int) Timestamp when the boost/stream was sent WITHIN the episode (playback position)
+
+Rest of 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. 
+
+## 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
+* PodStation: https://github.com/podStation/podStation/pull/249
+* Helipad: https://github.com/Podcastindex-org/helipad/blob/203e72dafb65e4f9e89540fbe4fc07a456a9907a/src/main.rs