The Interledger Community 🌱

Webmonitization for Podcasting β€” Grant Report #1

Project Overview

Web Monetization for Podcasting

This project will implement Web Monetization for podcasting in PRX's OSS publishing system and embeddable podcast player. We will work with podcasters across our portfolio to pilot WM functionality for podcasters.

We’ll also add WM support to the PRX embeddable podcast player by using the newly added RSS payment pointers, the monetization javascript API to align with audio playback, and counters with other UX elements to indicate WM support and use. The player is MIT Licensed, works with any RSS podcast feed, and has >50k monthly unique users across many podcaster sites.

Project Update

PRX's project to implement Web Monetization (WM) for podcasting in our open source publishing system and embeddable podcast player is going well. We have three main parts to complete, and have made progress on each of them. For the changes to our open source embeddable player and related episode landing pages, we are through the redesign to incorporate monetization and accessibility features, and have a team of developers in active development. For the publishing platform, we have determined the enhancements needed for supporting web monetization, and have changes coming to the front and backend to allow users to configure a Payment Pointer for each show. Finally, looking at standards and wider adoption, we have a proposal in the works for how to use the Podcasting 2.0 β€œpodcast:value/” tag and to incorporate WM as an option for this still experimental tag.

We did have a small struggle trying to decide on some early architectural decisions in our updates to the embeddable player and landing pages. As an open source project, it will serve as a model for using WM and audio, but our ambition is for others to use and contribute to it. PRX's engineering team worked through trade-offs on how best to modernize it to ease and encourage community contribution and adoption. In the end, it came down to balancing use of de facto standard third party libraries, reusable components, and minimal dependencies. We believe our choices will make this an attractive project for others to use, keep maintenance requirements to a minimum, yet still support the complexity of the roadmap of features we expect to implement.

One struggle with the project are some of the limitations of Web Monetization support for audio playback. The current specification and implementation do not allow streaming payments when the audio is playing in the background, which makes sense for visual media such as text or video, but is not how music and podcasts are most often experienced as companion media.

This limit has already been discussed and some tickets captured (i.e., and, and we are trying to resurface it in hope of a future solution that would allow optional background monetization for audio in some way. The issues explore a number of viable options, such as allowing background payments based on a setting, additional WM UI elements such as a checkbox or dynamic tab icon, or other kinds of prompts for a user to allow the payments to continue with playback, even in the background. Any of these would be a better solution for Web Monetization of audio than requiring browser focus, but concerns like fraud or abuse are real considerations. We appreciate that this may be an area of discussion, iteration, and experimentation for some time, and hope to participate in that process.

Progress on objectives

With technical, architectural, and design decisions in place, we are in the stage of rebuilding our open source embed player: β€œ”. We’ve moved through the RFC processes where we vet the plan for the rebuild with team members. As discussed in the Project Update, we spent a great deal of care upfront in selecting technologies and technical approaches, while working on UI designs. We are approaching the first milestone, which is feature parity with the current player, with WM next, then transcript and other features in later releases. With several developers working on it, we are making good progress.

Key activities

Our team uses an internal RFC process to discuss and capture key technical decisions, so that we can design and discuss them asynchronously, and then later revisit the RFCs and related discussions to remember the reasons for our decisions, and why those trade-offs were chosen.
For the play rebuild, the RFC process was key to starting it off on the right track:
After reaching consensus with how to move forward, the team has been working on the new player version, related components, and backend services, most of which can be found here:

Communications and marketing

Without having more of the project working, we have not made use of our channels as yet. We are preparing communications to partners who will feature the player, and will focus first on adoption via those producers and creators. Once participants are confirmed, communication and executing the marketing plan will follow.

What’s next?

The next milestones for the player are to complete the baseline implementation, then incorporate the WM design, and eventually the improved accessibility/transcript capabilities.

On the publishing side, as mentioned in the update above, we have queued up the work to add the necessary configuration for payment pointers, and to incorporate these values into the RSS feed publishing. That work was dependent on the release of multiple feed support, which is now completed, and this work is ready to be done.

As the new player becomes usable to replace the existing player, we will be working with partner publishers to enable WM for their shows, and make necessary changes to current embeds to allow WM for the iframes.

The WM for playback on episode landing pages will be more immediately enabled, and may actually be more easily adopted, as we generate and use those pages in all our feeds now as the default link for any episode.

What community support would benefit your project?

No support is needed at this time, though if there are other podcast or audio-related projects interested in background WM, we are interested in potentially working together to help find a solution for how to conditionally allow such unattended streamed payments, and raise the priority of Coil working on these changes. We believe such an enhancement would be beneficial to audio creators, and perhaps help encourage adoption.

Top comments (4)

chrislarry profile image
Chris Lawrence

@hessel @meghan I am tagging you here as you have similar projects but also because you all are looking at the "dormant/not streaming payments" issue.

hessel profile image
Hessel van Oorschot

@chrislarry Thank you! Yes, absolutely relevant for podcasters, curators and musicians who want to monetize their content based on "background play".

chrislarry profile image
Chris Lawrence

@iekmanis You should connect with the Free Music Archive team on this!

Thread Thread
hessel profile image
Hessel van Oorschot

@iekmanis Feel free to do so ;-)