mirrors/lightning-blips
1
0
Fork 0
mirror of https://github.com/lightning/blips.git synced 2024-11-19 00:50:02 +01:00
Code Issues Projects Releases Wiki Activity
master
lightning-blips/blip-0010.md
satoshisstream 053ec60d07
Timestamp is in seconds 
#12
2022-01-31 16:10:28 +00:00

7.4 KiB
Raw Permalink Blame History 

bLIP: 10
Title: Podcasting 2.0 Streaming payments, Boosts and Boostagrams
Status: Active
Author:  Satoshis Stream <satoshisstream@pm.me>
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 boosts. 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) 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, among other fields described in the 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 ints 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.

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, in seconds (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 to the RSS 2.0 spec in order to deliver new functionality to apps and aggregators (see the 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