Journey into Web Monetization - day 1

I was excited to learn about this new web monetization api and what impact it can have on the future of the web.

My basic understanding of it:

• Creators can set up payment pointers (basically a url to a wallet) and receive streaming payments for access to their content.
• This payment pointer is added to a meta tag in an html document.
• Payment pointers can also be set up in a more dynamic way on the servers.

Pretty quickly after skimming through the documentation, I came up with four potential ideas:

1. Monetize mixtapes

I'm a big fan of mixtapes from artists and labels and find it a great way of discovering new music.

The idea would be to build a stream server which switches the payout depending on timestamps mapped to a table of payment pointers to artists.

This would enable the artist to receive payment exactly for the time their music is being played.

2. Newsletters or articles

Many writers today rely on services such as Medium or Substack to reach their audience. I had this idea of building tools to enable writers to earn money in a more indenpendent way hosting their own content.

Coil describes three strategies of monetizing:

• free sample and pay for the rest
• some free and some paid
• everything free and pay for bonus content

3. SaaS for developers to monetize their apps

I got this idea of creating an sdk that developers could easily add as middleware for their api routes. Instead of the usual subscription-based model, the users would only pay when they use the apps. This could include a granular control of which api's are accessible for free. Another possibility would be to monetize external API's for other apps to use.

4. Photos on IPFS

An embeddable widget would enable photographers or other visual artists to embed their content in their own as well as publishers' websites. They would then receive payment when users view their content (or high-res versions)

As I kept thinking on these ideas I noticed obvious problems with all of them:
Payment streams turn off when webpage goes in the background making music content difficult. Besides, getting users to give up Spotify or other established music services might be challenging.

For newsletters and written content, what would the proof of concept be?
What would happen if readers go offline to read, turning off the payment stream.

I guess it depends on how you look at the monetizing. Is payment mandatory or optional?