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?
Top comments (14)
Idea #1 strikes home for me. A way to cut out the middle man involved with the current music distribution process. It also provides a great way for a creator to interface with their audience. Would you think you would require WM for listening or just use an incentive model (like the 100+20 idea from Coil)?
I think you're onto something with allowing creators to interface more easily with their audience.
I would love to see something more decentralized in how we listen to music. Right now you have to pick an app and you're stuck with their library. I guess the library is dependent on the deals between record labels and the app.
Why not use a similar approach to RSS feeds and blockchains where any client can tap into the data. You can subscribe to feeds, not only from creators but also curators building tracklists and mixtapes to promote content. Creators and curators can of course collaborate together to create groups similar to how some record labels work today.
Developers and designers create clients for these feeds and datalayers and users connect their wallets to stream directly to the creators wallets.
That would as you say cut out the middle man and let content flow in a maybe more organic way.
Of course, this is not limited to music content.
Hey Carl, this is very interesting stuff. I think this could be huge with Podcasts, don't you think?
Podcast Hosting also is very expensive, (10-20$) right now, I can't see to figure out why, it's a bunch of mp3s, right?
That's a great idea Rohan!
Maybe it would be possible to build something to connect a stream from IPFS or AWS S3 to pipe streams together:
Hmm, if you are up for talking more about this hit me up on rohansawantct83@gmail.com, we could actually collaborate on this! I might even have a group of dev friends who can help us with it too!
Hmm.. so many interesting ideas here!
Does RapidAPI sound like Number 3?
Thank you!
I don't know much about RapidAPI but it seems to be a way to monetize APIs by a subscription model to get x number of calls each month.
I think Web Monetization will allow for more granular control and pull-based payments (instead of pushing money from your credit-card).
Imagine you connect your wallet to your browser (or use an extension like Coil or maybe Metamask?). Websites you visit can then pull payments from your wallet like a continous stream.
So this would be a way to monetize PWAs where instead of a flat-rate monthly fee subscription you only pay for the time you actually use the app (or certain "premium" APIs).
Hmm, so you mean, add this on top of AWS Lamda-like thing? That sounds interesting.
Rapid are great and do offer a very easy way to earn from your APIs
you can also check out byvalue.org , there's greater flexibility with pricing and half of the commission, plus you can upload raw code/project and the platform creates an API for you.
Ooh wow - I hadn't thought of that.
I think idea number 3 is probably the most viable.
One solution would be to stream the content back to the client in exchange for payment, similar to how you would stream video or audio.
That's an interesting idea!
L-U-V Idea 1!!! I think that is a fluid combinatio of content, tooling and concept of WM.
Thanks! I will keep it in mind during this journey. It definitely touches many aspects of WM.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.